北京银行架构师管理于振华：全栈可扩展的金融系统架构实践

非常高兴来到大数据峰会跟大家一起分享一下北京银行系统建设的实践情况，先做一下自我介绍，我叫于振华，来自北京银行，一直做的是银行核心系统研发的工作，今天题目叫做“可扩展的系统架构实践”大家看到今天我们讨论的主题是分布式数据库，在应用里面现在比较热的是微服务架构，出现频率最高的词就是可扩展，当然还包括其他的因素，像高可用、敏捷等等因素，不只是只有扩展性一个因素，下面我们具体看一下。

我介绍的内容包括4个部分：1、做系统架构升级演进的过程；我们的需求是什么，要做什么样的架构，从哪里做起；2、我们的实践路线，先做哪个，今天介绍一下我们的思路，希望给大家一些参考；3、因为我们做架构升级不光是为了做架构升级而升级，而是确实对业务有发展、有帮助；第三方面会介绍一下北京银行在分布式数据库实现过程中都做了哪些业务对接、业务应用；4、最后还有一部分，因为我们的架构升级是整体全局性的工作，有些工作觉得我们已经做的差不多了，或者说已经到了中后段了，有些工作刚刚启动，跟大家分享一下北京银行的思路。

一、演进背景

现在对于软件演进的学说，有些都不应该说是学说是传说，说的很神，在我们看来软件产业它的发展无疑是向两个方向在发展，现在已经明确了，第一有些创新的功能我们要做出来，像今天讨论分布式数据库，要谈到中间件式的比如分库分表、多副本的协议，以及有了分库分表、多副本之后数据一致性的保障，之前没有现在有了，就是这个范畴里的；第二还有一个比较重要的是整个软件产业向轻量化发展，现在谈的都是敏捷、微服务化，为什么要这样做？就是让大家用起来更加简单；

如果说到北京银行做分布式数据库这方面的工作，是开展的比较早的，我们为什么要做？最主要的原因还是外部因素的影响，相信大家应该也有感受，在这四五年的时间里面，大家的生活发生了很大的变化，涉及到支付、贷款、消费的，业务逻辑都发生了变化，从线下到线上，导致业务量的激增，我们是非常需要有一款能够灵活扩展的产品，尤其是数据库产品，这是一方面；还有以前谈到的成本控制、自主可控要求等，这是我们演进升级的动力。

做转型升级之前我们当时花了很长一段时间梳理行内系统，北京银行系统是比较多的，大家看到片子上有一些系统架构应用形态，不避讳的谈，北京银行还有这种架构形态，包括单体应用、传统数据库，以oracle为代表的数据库形态，单体部署模式、瀑布开发、常规营卫等等，今天我们讨论新技术，是不是之前的架构就不好了？我觉得不是这样，不好的话不可能支撑这么多年的业务发展，但是站在今天这个背景下，也是有一定的问题，包括扩展、敏捷程度等等，所以要做架构升级，在做架构升级的过程中，有些朋友聊说做架构升级有没有什么原则、方向？希望用两分钟讲清楚，那么就要说这三点，看起来很虚，但是真的实践会有这三方面的感受：

1、要做到务实；新技术是好，但是不能为了做新技术而做新技术，一定要务实对业务有所帮助。

2、速赢；无论在什么样的企业做架构升级，都会或多或少的遇到一些阻力，速赢让你的组织对快速看到价值，比如我们做分布式数据库也会有阻力，让周围人快速看到它的价值，对未来工作开展就很有帮助。

3、全栈，做架构升级一定要放眼全局，首先我们选的是分布式数据库，选了一个金融技术框架，为什么选他们？是因为如果建设好它能够带来全栈的价值输出。

北京银行做架构升级的四大突破口，包括底层的NewSQL数据库，包括金融云平台，包括稍微往上一点的分布式技术、应用框架包括人工智能等相应的领域，包括现在做的分布式数据库、智能客服等等这些都是属于这个范围；

以上是我给大家介绍的背景，为什么做这些事情。

二、实践路径

得益于领导的眼光独到，北京银行在做分布式数据库这块比较早，2016年已经开始做了，已经开始进行了预研的工作，那个时候在各家银行都没有可以参考的案例，我们花了很大的成本、时间做分布式数据库的评测体系，确保产品一定能够适应金融场景的要求。左图是面向功能性的测试，包括比较重要的高可用、在线升级这种功能性测试，在评测过程中也逐一对它进行了评测；右图是做性能测试的工具，并没有采用TPCC、SYSBECH，因为我们觉得距离金融场景还有点远，测完之后还是不知道在金融场景下能够跑多少，我们因此建设了一个面向金融场景的评测工具。

在这个过程中要感谢很多机构，感谢中国信通院、intel，给了我们很多帮助。在评测过程中为了测试新的平台X86的架构，来到intel云计算中心评测新的架构与数据库的匹配情况，这也为我们未来生产部署提供了非常有效的参考。

这是数据库底层数据分布的一张图，采用的是两地三中心五副本建设模式，北京银行具备两地三中心的架构，北京有一个IDC，西安有一个IDC，北京到西安延时15-17毫秒左右，这个延时对银行金融交易来讲是完全不可接受的，我们也做了两地三中心的部署模式，当请求进来之后，不需要走到西安，北京有四个副本，成功三个就可以返回了，为什么做五副本之前问的比较多，做五副本的原因是因为这样做的话可以允许北京IDC出现部分实例失败，失败之后也不需要用到北京到西安的网络，经过我们这种建设方案，我们的SQL平均延时达到1.2毫秒，这个时间就比较理想的。

做高可用性的一个保障，多副本是高可用性保障的最大的法宝，这样就可以轻易得到一个结论，这个集群当中有多数派服务器存活就可以对外提供服务。

刚刚在5月初，因为机位的缺失，我们刚做了一次大规模缩容，不是服务器到不了，是因为机位已经用满了，又要迎接新的项目，所以把机柜缩出来，经过我们实际验证利用这种方式大概数据量，单副本数据量3-4T左右，我们进行在线动态缩容用了大概2小时时间，实现了交易的零影响。

刚才招商银行的同事已经讲过了，两阶段提交，我们采用的是谷歌的模型做这个事，刚才介绍了我们的评测方案，对于这种模型在图中画的每个点做评测的时候都进行了重点测试，确保能够满足金融级的事务ACID的保障。经过上线一年多时间，大概处理交易量7-8亿笔，没有出现一笔事务不一致的情况，也对它进行了充分的验证。

以上讲的是我们的实践路线包括用的技术。

三、业务赋能

（编辑：南平站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!