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

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

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

一、演进背景

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

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

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

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

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

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

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

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

二、实践路径

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

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

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

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

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

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

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

三、业务赋能

介绍一下我们做了哪些业务验证的对接。整体的架构图，采用两地三中心模式，现在在上面跑的系统比较多，也把以往在核心系统建的业务迁移到上面来，有网银清算平台、银联卡支付、以往建设在核心的会计引擎。主机群之外，在异地建设了一个从机群，是为了要对分析型场景做对接，避免对主机群景有压力，这是整体的架构方案。

通过我们和数据库的对比，在数据分布比较均衡的情况下有5倍的性能提升。

如果单纯讲分布式数据库、业务应用的话到这里就结束了，北京银行起步比较早、应用规模现在比较大，经过一段时间的应用发现有些问题，怎么样高效的管理，因为如果没有一些手段的话比传统单体的数据库管理起来成本要高很多，这是第一个问题；第二个问题是怎么样提升系统资源利用率，如果分布式数据库采用传统的集群部署模式，有个困难，我们明知道它的资源利用率不可能到这么高，用不满，但是也不敢把另外的系统接进去，不敢做混用，就怕两个系统之间有系统资源争抢的情况，所以我们在今年5月初做了容器云数据库的部署方案，采用这种NewSQL型的容器云数据库在金融领域也是第一家。

我们选用了PaaS领域的事实标准K8S来进行云数据库的底层支撑，想用的就是它资源隔离的能力，在传统部署模式里，明明我们知道物理资源用不满我们却不敢轻易的混合多套系统到一套数据库上，原因也是传统集群部署模式无法实现资源的隔离，担心会出现物理资源互相影响的情况。同时，我们也希望借助它来进行调度、伸缩以及高可用性的管理。

我们是选择直接部署在裸机上的，K8集群直接建在裸机上，由控制器来实现tidb 的扩缩容/滚动升级/故障转移的逻辑，由调度器实现tidb 节点的高可用部署策略，实现资源最优分配，前面介绍了我们七八个系统已经建设在集群部署模式的架构上，目前我们也是要一点点的迁移到容器云上，达到资源的集约化管理。

那这张图展示的是我们分布式数据库整体的应用情况。从2016年到9月到今天，我们已经完成了全栈的建设工作。目前看，效果还不错，大家看右下角这个图是我们双十一那天12点的情况，交易激增10倍以上，系统表现平稳。我们也已经把核心的部分功能，会计引擎建设到了分布式数据库上，随着应用的深入，我们会把越来越多的核心系统业务引流到分布式数据库上。

四、总结与展望

北京银行系统架构转型工作，因为今天讨论的是分布式数据库，只讲这一点，有些内容还是在过程中，有些差不多了，有些刚起步。下面介绍一下未来我们的整体规划；

没有一种技术是万能的，有了新技术之后要在实战中不断完善、不断优化它。我们在整个实践过程中也遇到了一些问题，包括隔离级别的问题，大家以前用db2 oracle已经习惯了RC的隔离级别，我们用的分布式数据库是SI的隔离级别，出现了一些适配的问题，还包括执行计划没有命中索引，需要强制HINT，热点数据的处理等等。那在这么多问题中，最值得我们思考的是乐观模型和现在比较流行的微服务架构之间的冲突，微服务化的应用架构无论是应用逻辑或是事务大小都变小了，需要多次提交，而乐观模型在多次提交场景下性能明显会有衰减，我想这也是未来我们研究的一个重要课题。

我们认为架构转型是一项全局性工作，是一个非常基础性的工程，一定要注重到这一点，同时也要让你的团队认识到这一点。不要停留在paper或者ppt上，要注重原型的检验。北京银行为此套架构建设了标准化性能测试工具，建设了原型，目的就是要将架构理论落到实处，我们也会将这些内容积极与大家分享，让大家进行架构转型能够更加容易。

其次，要做好事前资源评估，这种架构适不适合，物理资源是不是已经达到了新架构要求，从价值、成本两个角度衡量架构转型的必要性，还是那句话新的不一定是好的，也不一定是适合你的。当然，还包括能够搞定新架构的技术团队、适用于新架构的应用标准等要求，我就不一一赘述了。

随着工作的深入，我们意识到我们已经进入了分布式数据库建设的后半程。后半程要做什么，第一我想就是精细化运营，稳定的运营是生产系统的生命力，现在应用多了，规模大了，需要匹配上精细化、智能化的管理，还有一点就是建立金融级的应用规范，进行规范的推广，来帮助未来迁入分布式数据库的系统安全过渡。

第二是我们一直想做的，就是HTAP的建设，现在业务应用的呼声也很高，大家都希望数据库既可以支持实时交易处理又能具备准实时分析的能力，而不希望再走抽数流程T+1的分析方式，这部分也会是我们的建设重点。

北京银行的存量系统大概有200多个，进行架构升级，有的可以一刀切的升级，有的只能采用新、旧系统并行的方式，所以我们还有一个任务，就是要建设新旧系统的并行机制，包括数据同步，系统交互，系统间一致性保障等整套的方案。

我分享的内容就是这么多，谢谢大家！

 

 

时间:2019-06-09 18:11  来源:    转发量:次