5320字深度解读 | 招商银行数据库架构思考与实践

开 篇

本文根据王龙老师在2018年4月14日【「3306π」北京站】现场演讲内容整理而成。

王龙

招商银行数据中心MySQL资深架构师

将MySQL引入招商银行，并从无到有建设MySQL生态，解决了MySQL在银行领域使用的诸多问题。

摘要：今天我要给大家分享招商银行这些年的系统建设，尤其是涉及到数据库方面的思考与实践。

分享大纲：

1、Fintech Bank的挑战

2、我们的应对策略

3、案例分享

Fintech Bank的挑战

我相信大家都听过一个词“Fintech”，是最近金融领域比较火的一个词，那么“Fintech”是什么意思？其实是两个词组成，一个是“Financial”一个是“Technology”，也就是金融科技。

互联网金融的理念这两年对传统银行的冲击还是比较大的。相信几年前，甚至五年、十年，大家都去过银行网点办业务，我相信大家对银行网点的工作人员会有非常强烈的吐槽感，甚至不排除有把工作人员拉出去打一顿的想法。

现在我们提出“Fintech”这个概念，包括很多银行都提出这个概念，意味着什么？以我们行长对这个概念的定义，其实很简单，就一句话——“让客户爽”。但怎样才能让客户爽？这对我们的系统提出了几个要求：

第一、业务连续性要求高

业务连续性要求高，可用性要求好，为什么这么说？以前大家去银行网点办业务，一般是上午8点到下午5点，5点后对不起，只能明天再来。如果你有一些资料没带齐，对不起，也只能明天再来。而现在互联网金融是7*24的服务，随叫随到，你有问题随时能找到我们，随时能够做业务。

第二、性能

性能即处理速度要快，比如双11，我们系统要求比以往更高，每年双11对银行都是一场考试。所以说，在新业务场景下，对我们以往的一些系统性能要求更高。

第三、更高的开发运维效率

以前所有银行，包括我们行，迭代速度都会比较慢，比如说，可能一个月一次迭代，这种速度在当前需求爆发时代是远远不够的。因此，我们现在基本上一周两个迭代，两周一个上线的速度。其实这个速度还是比较慢，实际上我们可能更快，基本上两天可能就有一个上线，这样的速度要求我们系统流程有一些新的突破。

第四、运营成本显著下降

随着业务越来越丰富，怎样才能够以更低的成本去服务更多的业务？这对我们的系统又提出新的考量。

在这种种压力下，我们的系统，我们的应对策略是怎样的？这其中就包含了我们在架构方面的一些思考和实践。

数据开放平台应对策略

对我们数据库来说，分为三个部分，第一个是高可用架构，包括了几种最基础的高可用；第二是我们如何应对这种敏捷、快速的趋势，包括了我们的云建设，DevOps建设；第三个是成本方面，我们会有一些分布式数据库的研发。

架构原则

在谈架构的实践之前，我想先跟大家分享下我们关于架构方面的一些思考，也就是架构的原则。我觉得这些原则才是最宝贵的精华，其中凝结了我们长久以来的一些思考和落地。

1.     建设多中心，有些公司可能比较小，不会考虑建多中心，但等你公司发展到一定规模，一定要考虑建多中心，多中心才能让我们更加安稳。建设多中心，能提升容灾能力和扩展能力，提升机房升级、搬迁时的业务保障能力。

2.     组件失效免疫能力，单一应用、单一硬件、甚至单一基础设施、单一站点灾难，都会对业务造成影响，考核数据中心的故障恢复能力。没有单一组件失效免疫的能力，数据中心的成熟度在哪里？ 一定要考虑组件失效的免疫能力，保证单一组件替换、失效了都没问题。

3.     高可用是运维核心要求，容灾是最后屏障，例如双活比单活好，Oracle RAC架构比单节点+DG好，MGR比复制架构好；重要系统要做好高可用、容灾建设。

4.     扩展性很重要，尽量做到水平扩展，避免过度依赖纵向扩展。同时具备纵向、横向扩展的能力，例如无状态应用多地多套负载均衡多活部署，数据库分库架构。

5.     坚持交易机、节点机分离原则，区分真正的核心业务、重要业务、渠道、内部业务。交易机是什么意思？就是最终落地，比如我给你转了10元钱，这10元钱最终交易、发生、记录的地方，我们称之为交易机，而中间所有的过道我们称为节点机。交易机承载客户、账户、账务交易、账务协议等数据一致性要求极高的业务系统。节点机不含上述重要信息，只有交易相关的配置类信息，交易上下文无关，甚至不保证提供交易痕迹追溯的系统。交易机采用的架构，最佳为分库、多活；和节点机分离后，应该也更有条件为交易机铺设专用高速公路。节点机采用的架构，因其接近无状态，最佳为互相之间无关系的多库，其次为读写分离、缓存，甚至无数据库。

6.     为关键组件减负，特别是数据库的访问，数据库成本最高，扩展性最难，可用性保障最难，恢复难度和时间最大。减负：能不用就不用；使用最简单、成本最低的语句，避免大事务，慎用两阶段事务。

7.     选择成熟的平台和技术，同时是你最熟的，玩深玩透玩到极致，用好不用坏，用熟不用生。

8.     应用解耦，通过应用访问数据库而不是直接访问；重要业务不能依赖低保障级别的系统；应用层重要业务要和普通业务解耦；关键业务要独立。

9.     建立灰度数据库，减少发布时变更数据库对全局的影响，只有应用程序灰度是不够的，还要有专门的灰度数据库。在分库/读写分离架构下，一套含数据库的完整应用架构，变得很自然。

10.  建立高仿真架构体系，一定要建高仿真架构体系，数据库、操作系统升级，应用是否适应？性能会变好还是变坏？应用上线发布、系统变更（例如换平台），提前判断业务影响和性能极限。应对突发交易量，例如双十一，性能极限在哪里，瓶颈在哪里？都要靠高仿真架构体系去测试。

11.  应用和数据库一起考虑可用性、效率，故障恢复应用和运行人员一起，解决例如应用解耦、数据库解耦、追帐补数、业务监控、应用路由、故障切换等。

12.  合理选用同步、异步方式。包括业务系统间、两个数据库间等。异步方式可以防止故障和效率问题的蔓延、扩大化，但应用会复杂一些。

13.  连接池的要求，连接池实际上很容易出错，是大家平常可能忽略的一个点，常见问题：

A:应用的数据库连接池设置偏小，一旦数据库响应慢（例如新上线应用，缺索引等），则应用排队严重，甚至雪崩。而遗憾的是，此时很可能数据库的能力还远没有用尽。

B:不具备失效及时发现和重新连接数据库的能力。

C:缺省隔离级别设置不对。

基础高可用架构

下面来看看我们的一些实践，MySQL的一个高可用的架构。

在我们内部有个概念叫RTI，指的是我们任何一个组件都是没有单点的，包括主机、存储等基础设施等都是双链路无单点。单点建设够强，就能成为一个小钢炮，再往上一步步搭建一些其他的架构，比如说复制，读写分离，分库分表等方式。所以说，高可用是我们最基础的一个保障。

架构的可用性与扩展性

其次，我们还引用了一些架构改造方式，总结为四种：

从右往左依次是，数据放通，无状态冗余、分库和读写分离。最后两个，我相信很多DBA老司机都玩过，读写分离、分库分表。那么，他们都是什么意思？我解释下。

数据放通

数据放通指的是关键路径上某些涉及数据库的非核心操作(例如记录日志)，不强依赖数据库，异步延迟写入数据库。通俗的说，就是在我的应用场景中，能不用数据库，我就不用数据库，我们认为，最好的架构就是没有数据库的架构。

无状态冗余

无状态冗余是指在应急的时候，通过预先创建数据库或表快速接管“无状态”的应用，达到快速恢复业务的目的；核心操作有不强依赖数据库的备选路径。也就是说，如果你非用不可，在数据库失效的情况下，还有另外一个库帮我去hold住流量。

读写分离

所谓的读写分离就是有一个写库，比如说我们刚才那个高可用架构，另外通过复制建了几个读库。那这个适合什么？适合以读多写少的这种场景，比如说80%的读，20%的写。另外，这个复制是有一定延迟的，所以业务一定要是对延迟是不敏感的，比如说客户转了一笔钱之后，想去看流水信息，可能过了五秒钟才看到，他觉得没关系，这种场景是OK的。但如果说他要马上能看到正确的反馈，比如期货等比较高频的交易，要求在一秒钟之内甚至更短得到一个正确的反馈，那就不行，这种情况下必须要落到同一个库，不能使用读写分离。

这里需要提到一个概念——“逻辑数据中心”，也是我们内部一直在讲的一个概念。大家可以看到，我们把图上的系统分成四个组，蓝色的是写库，黄色的是读库，我们把每一组这种垂直的，包括应用系统，包括数据库的元组叫做一个逻辑数据中心。这样每个一个逻辑数据中心都可以作为一个整体部署在不同AZ，或者同一个AZ不同机架中，提高可用性的同时，降低了运维、管理复杂度，好处显而易见。

分库

分库也是，我们也是采用逻辑数据中心这个概念，每个库可能承载四分之一个流量，承载四分之一的数据，正好把它绑定在一起。

分库我相信大家也总结过，好处很明显，一个是提高性能，第二个提高可用性，如果没有分库，坏了可能数据就全部没了。

其实对我们来说，最主要的还是要避免跨库，跨库有可能是数据发生跨库，同一个事务中涉及到的数据有可能一部分在A库，另一部分在B库，这样就不太好，一定挪到一个库里面。那第二个是业务上、流程上要避免不同的东西要处于不同的库。

分库常见几个基本问题：

1.在哪一层实现分库路由？

A 在web server/app client层实现分库

B 在App Server层实现分库

A方法明显优于B方法，使用A方法实现一组应用和一个DB绑定，部署在一个中心内，形成逻辑数据中心；多个逻辑数据中心部署在多个物理中心，此为最佳实践。

如果采用B方案，由于App Server和db之间交互次数较多，响应时间比较敏感，限制了跨中心部署，同时架构和访问关系复杂化，故障定位难度大。

2.分多少个库？

A.根据能够承受的交易量损失百分比来测算

B.同时结合多中心的基础设施能力

C.根据单库交易能力，总交易需求来测算

有一个原则是，不要分太多，当分库已经较多时，优先考虑应用优化、db优化、垂直扩展。以降低资源消耗和管理成本。

3.路由方法？

A. 直接路由，适用于交易总是以分区键来进行的情况。

B. 查对照表路由。适用于交易凭证有多种的情况。

云服务能力&DevOps建设

下面讲一下，我们如何满足业务快速、敏捷的要求。主要体现在两个方面：云服务能力和DevOps建设。

从流程上讲，我们有非常严格的投产发布流程，其中包括了数据架构设计环节。比如说我们刚才讲到了几种架构方式，我们在所有架构刚开始设立的时候，也就是项目立项的时候会进行评审。系统的准入条件是一定要引入至少一种数据库架构改进方式，数据放通，无状态冗余，读写分离和分库，这四种方式必须有一种引入。

然后，我们会对每个系统的每一个业务场景进行梳理。具体来说，它操作哪个表哪一行数据，都需要梳理出来，这样，我们就能根据梳理的这些特点判断这个系统适合什么样的架构，比如说，它访问这个表只有80%的读，20%的写，那我们就认为这个场景适合读写分离。

第二，在资源创建时，我们有云服务平台，根据自动化填写的表格需求，半个小时就可以把资源交付,包含了Oracle，MySQL，MongoDB，Redis这些资源交付都是非常迅速的。

我们现在整个流程是全部自动化的，从测试到生产是直接同步数据直接推送的。自动化的验证和发布。

在数据库上线之后，我们有一个统一运维平台，以业务系统/数据库等不同视角和维度，集中展示数据状态信息，包括IO服务能力，TPS，响应时间等等。进一步进行自动处理等。

然后，把数据库基础运维操作封装成原子化模块，也就是运维服务化，通过流程编排可以快速提供完整和复杂的服务流程

举个例子，大家如果做过Oracle，或者以前一些其他数据库，就会发现Oracle经常会发布一些特别小的补丁包，这样会导致升级比较频繁，因此，我们可以把这种场景通过我们的运维编排工具固定为一个流程。我们可以看到上面图里，我们在我们行内的运维平台中，通过对各个组件进行拖拽，搭建好前后关系，就自动会安排一次变更，从而达到一个比较规范快速的操作。

分布式建设

接下来我分享下我们分布式的建设，这个建设的目的是为了满足未来我们对低成本的需求。

在今年初，我们跟华为一起建立了一个联合实验室，研发分布式数据库，目前在国内真正从底层做分布式的可能还不是特别多，因此这个分布式数据库的联合研发还是很有技术含量的。

上图是我们分布式数据库大概的架构图，比较粗略，大家可能看到过OceanBase或TIDB的架构，跟我们这个差不多。我觉得这是未来的一个方向，希望大家一定去持续关注。

案例分享

最后，讲一个我们内部的案例，这是我们第三方支付环节中的一个系统。微信、支付宝的交易都会与这个系统有关。

这个系统包含两个最主要业务场景，消费和退货。消费交易从银联过来，然后输送到我们银行里面的一个交易记账系统。我们看到上图，最右边就是消费，消费过来之后，我们进行上海和深圳的两地部署，如果是平常可能我直接走到深圳这边来，那没有问题，假设深圳挂了会怎么办？这个交易直接发到上海去，从上海这个库直接去进行，这就是我们所谓的无状态冗余，是多活的，挂掉任何一个都没问题，不影响我的交易。

下面，我们看一下退货，目前只有退货使用了MySQL承载，未来整个系统都有可能使用MySQL来替代。退货MySQL库我们使用了分库+读写分离的改造，进一步提高了MySQL的可用性，让它能够更好的适应金融交易场景。

好，总结一下：

第一、总体原则：采用最合适的架构，即满足业务需求，又取得成本收益平衡。

第二、最好的架构是没有数据库！

第三、保障基础架构高可用能力

第四、综合使用数据放通、无状态冗余、读写分离、分库分表等方案

第五、核心交易，能分库的就分库核心交易，不适合分库的，竭尽所能把核心做小，然后靠垂直扩展来扩容，用尽各种高可用、容灾手段保证其可用性。如果能做到双活或多活接入，也很有价值

END

延伸阅读

公众号

laoyubiji

老鱼，10年企业级老编一枚，采访过上百位CEO/CTO，你若有故事，欢迎联系！

欢迎订阅老鱼笔记

✬如果你喜欢这篇文章，欢迎分享到朋友圈✬

评论功能现已开启，灰常接受一切形式的吐槽和赞美☺