17 KiB
28 | 选型案例：银行是怎么选择分布式数据库的？
你好，我是王磊，你也可以叫我Ivan。
在前面的课程中，我们已经介绍了分布式数据库方方面面的知识。这些知识，我觉得大概会在三个方面帮到你，分别是数据库研发、架构思维提升和产品选型。今天，我会通过几家银行的案例带你了解如何做分布式数据库的选型。
为什么要讲银行的分布式数据库选型呢？
你肯定在想，这是因为王磊老师刚好是在银行工作，更熟悉这个行业。这么说也对，银行业确实是我最熟悉的行业。但是更重要的原因是，数据库作为一款基础软件，稳定性和可靠性就是它的立身之本。而对稳定性要求最严苛的行业，就是金融业，尤其是银行业。所以，只有经过金融场景的考验，一款数据库产品才能真正扬名立万，让其他行业的用户放心使用。
也是因为这个原因，不少厂商都打出了“金融级分布式数据库”的旗号。
分布式数据库的应用场景主要特征是海量并发，所以理论上说，业务规模越大，使用分布式数据库的需求也就越迫切。无论从用户数量还是资产规模，国内最大的银行肯定是工商银行。
工商银行（分布式中间件）
工行之前的数据库主要是Oracle和IBM的DB2，这很代表性，过去的20年银行业基本上就是在这两种产品中二选一。
Oracle和DB2都是单体数据库，只能采用垂直扩展方式，在碰到技术天花板后就会限制业务的发展。作为业务量最大的“宇宙行”，工行面对这个问题的选择是，从单体数据库向以MySQL为基础的分库分表方案转型。
为什么工行没有选择真正的分布式数据库呢？
我认为，其中主要原因是产品成熟度。工行的架构改造在2018年大规模落地，而调研和试点工作则在更早的2016-2017年。这个时点上，商用NewSQL数据库刚刚推出不久，而金融场景的种种严苛要求，注定了银行不会做第一个吃螃蟹的人，那么这种可能性就被排除了。同样，另一种PGXC风格的分布式数据库也正待破茧而出，反而是它的前身，“分布式中间件+开源单体数据库”的组合更加普及。
所以，对当时的工行来说，产品架构上是没有什么选择余地的，能做的就是选择产品。后来的结果是选择了DBLE + MySQL的组合，选择MySQL是因为它的普及程度足够高；而选择DBLE则因为它是在MyCat的基础上研发，号称是“增强版MyCat”，由于MyCat已经有较多的应用案例，所以这一点给DBLE带来不少加分。
现在看来，这个方案显得有点平淡无奇。但正是这种稳妥，或者说有点保守的选择，最大程度规避了风险，也坚定了工行从主机下移应用系统的决心。从后来MySQL上千节点的使用规模看，这个方案更大的意义在于，使工行逐步脱离了对IBM主机和Oracle数据库的依赖。分布式数据库的尝试只是这个大目标下的副产品。
相对于OLTP技术应用上的平淡，工行在OLAP方面的技术创新则令人瞩目。基本是在同期，工行联合华为成功研发了GaussDB 200，并在生产环境中投入使用。这款数据库对标了Teradata和Greenplum等国外OLAP数据库。在工行案例的加持下，目前不少银行计划或者正在使用这款产品替换Teradata数据库。
邮储银行（单元化）
邮政储蓄银行，简称邮储银行，由于特殊的历史沿革，它没有被归入通常所说“四大国有银行”，但这不意味着它的业务规模小。事实上，邮储银行的零售用户在2019年已经超过6亿。
这个庞大的用户基数使得邮储银行也早早地就开始探讨分布式数据库的使用。那他们采用了什么方案呢？
可能又让你失望了，他们也没有选择分布式数据库。邮储的核心业务系统改造方案更接近于单元化架构，所以连分布式中间件都没使用。它的设计思路就是将原来商业数据库拆分成若干个小的单体数据库，分别设置对应的应用实例。邮储在单体数据库上选择了PostgreSQL，这个在银行业中是相对较少使用的。
当然，单元化方案从应用整体看也是一种分布式架构，通过应用层面的重构弱化了对数据库的性能和稳定性等方面的要求。说到这，你可能会有个疑问，如果两种方式都能解决问题，那要怎么在单元化和分布式数据库之间选择呢？
从成本上看，系统的单元化改造要付出巨大的代价，是一个推倒重建的过程，远高于过渡到分布式数据库的代价。我认为，邮储之所以会选择这个方式，可能有两个原因：
- 对数据库的技术把控能力。毕竟分布式数据库带来的技术挑战不容忽视。
- 核心系统本身重构的必要性。如果应用系统的分布式改造势在必行，那么两个方案的目标都截然不同，成本的比较也就无从谈起了。
同样，民生银行也是在核心系统改造的背景下，完成了向分布式架构的升级。在民生银行的一份宣传材料中对分布式技术平台做了整体描述，其中有两段是和数据库相关，是这么写的“通过分库分表和读写分离实现分布式数据访问功能；基于可靠消息的最终一致性和基于冲正模型的反向处理实现分布式事务功能”。
可见民生银行也选择了与邮储银行大致相同的路线，弱化了分布式数据库的作用，更加强调整体架构改造，在应用系统层面做了更多的工作。
好了，刚才我们说到的三家银行都采用了迂回的方案，下面终于要用到分布式数据库了。
交通银行（研发NewSQL）
交通银行的分布式数据库之路走得比较特别，它采用联合高校研发的方式，与华东师范大学和西北工业大学共同研发了分布式数据库CBase。
CBase研发开始于2014年，在分布式数据库中算是非常早的了，但它的整体架构风格非常接近于NewSQL。不同于前几家银行，CBase并不是某个重要业务系统的附属品，已经有点技术驱动的味道。
它最先用于历史库系统的数据存储，而后逐步实现了复杂SQL语句处理和高并发事务处理能力，在供应链、贷记卡授权和网联支付等系统使用。
通过架构图，我们可以看到CBase的主要工作负载放在三类节点上，其中的数据存储节点与NewSQL风格完全一致，而剩下的SQL处理节点和事务处理节点，就是计算节点的细化。而且，CBase也基于Raft协议设计和实现了轻量级分布式选举协议，分布式事务同样是在2PC上进行改进的。
这款数据库主要在交通银行内部使用，目前并没有看到其他的商业化案例，所以能够找到的资料比较少。不过，CBase开发团队在2019年发表了一篇论文《分布式数据库在金融应用场景中的探索与实践》（刘雷 等(2019)），介绍了CBase的部分设计，如果你有兴趣可以仔细研读下。
交通银行研发分布式数据库在银行业是很有代表性的，因为之前还很少有在基础软件上进行大规模投入的先例。同样在2014年，中信银行也走上了联合研发的道路。
中信银行（研发PGXC）
终于要说到中信银行了，课程中我们已经多次讲过的GoldenDB就是中信银行与中兴通讯联合研发的产品，而目前GoldenDB主要用户也是中信银行。中信银行的核心业务系统在2020年5月正式上线切换到GoldenDB。这之前，基于GoldenDB的信用卡新核心系统已经在2019年10月投产运行。这两个重要系统的运行，使中信银行无可争议地成为分布式数据库应用最为深入的一家银行。核心业务系统是银行业务的心脏，它的稳定运行无疑为其他银行树立了标杆，客观上也加快分布式数据库的普及速度。
GoldenDB和CBase有大致相同的发展路径，从产品研发到试点应用，只不过中信银行的步子更快些。当然，这并不是说交行研发人员的能力不行，因为这个速度上的差别确实有架构上的因素。GoldenDB是PGXC风格的分布式数据库，遇到的技术挑战更小；当然NewSQL架构上的优势，也让我们对CBase的未来充满期待。
你有没有注意到，还有一个很有意思的地方，同样是核心系统改造，为什么中信银行就使用了分布式数据库呢？
答案还是在于项目目标不同。中信的目标就是完成AS400小机下移，将应用程序翻写到开放平台，但是对应用架构本身并没有改造诉求。所以，数据库层面的平滑过渡就有很大的优势，编码逻辑改动小，测试成本低，最重要的是不会因为技术原因变动业务流程，这样就大大降低了项目的实施难度。
北京银行（NewSQL）
北京银行是城市商业银行中的佼佼者，但相对于前几家银行，在资产规模和用户数量上有较大的差距。北京银行从2018年开始，先后在网联支付系统和网贷系统中应用了TiDB。
事实上，很多比北京银行规模更小的城市商业银行，比如南京银行（OceanBase）、张家港银行（TDSQL）都已经上线了分布式数据库。表面上，我们似乎很难捕捉到他们替换数据库的动因。从业务压力的角度，业务量通常没有达到海量并发级别；同时城商行通常也不涉及“主机下移”带来可用性下降问题。
那么，他们为什么要做出这个选择呢？我觉得主要有三点原因。
- 国产化的诉求
由于各种原因，继续依赖Oracle这样的国外商业产品，很可能让银行将面临更大的风险。而对于小型银行来说，使用开源数据库还是分布式数据库，在成本上可能差异并不大。
随着国内厂商加大技术投入，隐约有一种趋势，就是分布式数据库正在逐步成为国产数据库的代名词。那些原本深耕单体数据库技术的厂商，比如达梦、人大金仓，也在朝着分布式架构转型。
所以，选择分布式数据库也就满足了国产化的诉求。
- 实际收益
由于小型银行的数据量并不大，上线分布式数据库后集群的节点规模没有大幅增长，对运维的冲击也相对小些。此外，利用分布式数据库的多租户特性，转变成类似Aurora使用方式，还能降低数据库实例管理的复杂度。所以，使用分布式数据库也是有一些实际收益的。
- 技术潮流
这也是我在开篇词中说的，一旦技术的趋势形成，就会在无形中影响人们的选择。就像时尚潮流那样，在同等价位下，大家当然更愿意选那些流行款式。今天，分布式架构转型就是这样的潮流，微服务架构、分布式数据库甚至容器云都是这个大潮下的浪花。
在风险可控的前提下，受到技术潮流的影响，我觉得可能还会有更多的小型银行会选择分布式数据库。
光大银行（NewSQL & 分库分表）
下面，我来聊聊光大银行的分布式数据库实践。简单来说，光大使用了双路线策略，也就是同时使用NewSQL和分库分表方案。
在云缴费系统中，光大使用了自研的分库分表方案。首先，这个系统的业务量，也就是缴费的业务量是非常大的。可能你不知道，今天支付宝、微信甚至很多银行的缴费服务，在后台都是要调用光大的云缴费系统的。截至2019年，云缴费系统的累计用户达到了5.49亿。
其实，缴费业务是非常互联网化的业务，就是银行提供服务对接用户和缴费企业，所以它的业务模型比较简单和统一。这也意味着，它对分布式事务这样的复杂操作没有那么强烈的诉求。最后，用分库方案就很好地解决了海量业务的问题。
光大在另一个系统，新一代财富管理平台使用了NewSQL数据库，也就是TiDB。这个系统是理财业务的全流程管理平台，业务量相对缴费要小很多，但业务要更复杂，而且在联机和批量方面都有计算需求。
这个架构选择更多是面向未来，因为理财业务是光大银行重点发力的业务，对未来业务量的增长还是有很大预期的。同时，我想，伴随着NewSQL技术的发展，保持团队对新技术的感知和掌握，应该也是一个重要的原因。
选型建议
好了，到这里已经介绍了六七家银行的选型情况，让我们稍稍总结一下。
- 产品选型要服从于项目整体目标
局部最优的选择拼装在一起未必是全局最优的方案。如果你的目标是要对整个应用系统做彻底重构，例如把单体架构改为微服务架构，那么要解决原来某些局部的问题，可能会有更多选择。这时候要从整体上评估技术复杂度、工程实施等因素，而不是仅选择局部最合理的方案。
- 先进的产品可能会延长项目交付时间
最先进的产品不一定是完美的选择。尤其是有进度要求时，往往会选择更稳妥、快速的办法。但是，这本质上是在短期利益和长期利益之间做权衡，没有绝对的对错，搞清楚你想要的是什么就行。
- 当产品选型可能导致业务流程变更时，请慎重对待
对任何项目来说，协作范围的扩大一定会增加实施难度。当技术部门对业务流程变更没有决定权时，我认为这是多数情况，通过技术手段避免这种变更往往是更好的选择。
- 产品选型中的非技术因素
正视非技术因素，评估它的合理性不是技术团队的职责。
- 评估技术潮流对选型影响
跟随潮流并不是人云亦云，你必须能够独立对技术发展趋势做出研判。太过小众的技术往往不能与工程化要求兼容。但同时，保持对新技术的敏感度和掌控力，也是非常必要的。
小结
那么，今天的课程就到这里了，让我们梳理一下这一讲的要点。
- 工商银行在主机应用下移的过程中，采用分布式中间件加MySQL的方式替换了原有的单体数据库。这个选择，一方面受制于当时分布式数据库的成熟度，另外这个方案的主要意义是大量使用了MySQL数据库，降低对主机和Oracle数据库的依赖，而分布式方案是一个副产品。
- 邮储银行和民生银行是在新一代核心系统建设的背景下进行分布式架构改造，所以他们有更多的项目目标，也能够承受更大的改造成本，这样分布式数据库能够平滑过渡、减少应用改造的优势也就不那么重要了。最终，两家银行都采用了类似单元化的架构，在应用层处理分布式事务等工作。
- 交通银行和中信银行都选择了自研方式。中信银行目前已经在核心业务系统上线GoldeDB，能够更快上线的一个原因就是PGXC的架构复用了单体数据库，遇到的技术挑战更少。
- 北京银行和很多规模更小的城商行也在陆续上线分布式数据库。我认为他们的选择因素有三个，国产化诉求、实际收益和技术潮流。我预测，未来还有更多的小型银行将上线分布式数据库。
- 光大银行采用了双路线策略，同时采用分库分表方案和NewSQL。这一方面因为不同系统的业务特点不同，另一方面也是要跟进NewSQL技术发展，保持对新技术的感知和应用能力。
今天的课程中，我简单总结几家银行的分布式数据库选型策略。相对于互联网行业，金融场景的苛刻要求，让银行更倾向于保守的策略，但是不难发现，总会有一些企业更具开创精神。我相信，随着分布式数据库的日益成熟，技术红利会驱使更多企业做出积极的尝试。事实上，就在我们课程更新的过程中，2020年9月，工商银行宣布将在对公（法人）理财系统的主机下移方案中采用OceanBase数据库。你看，大象也要开始跳舞了。
思考题
课程的最后，我们来看下思考题。今天的课程中，我们简单介绍了几家有代表性的银行进行分布式数据库选型的情况，也给出了一些选型建议。其实，产品选型是系统建设中非常重要的工作，也是从程序员到架构师这个成长过程中的必修课。我的问题是，你觉得针对一个新建系统做产品选型时还要考虑哪些因素呢？这个产品，并不限于数据库。
欢迎你在评论区留言和我一起讨论，我会在答疑篇和你继续讨论这个问题。如果你身边的朋友也对产品选型这个话题感兴趣，你也可以把今天这一讲分享给他，我们一起讨论。
学习资料
刘雷 等: 分布式数据库在金融应用场景中的探索与实践.