作者简介：王龙，招商银行数据中心MySQL资深架构师，将MySQL引入招商银行，并从无到有建设MySQL生态，解决了MySQL在银行领域使用的诸多问题。
引言
Fintech Bank 的挑战
这里涉及到什么是“金融科技银行”，“以科技敏捷带动业务敏捷，一家金融科技银行要紧紧围绕客户需求，深度融合科技与业务，快速迭代、持续交付产品和服务，创造最佳客户体验，实现效率、成本、风险的最佳平衡”，招行银行行长田惠宇如是说。
在向金融科技银行发展的过程中，招行面对了如下挑战，并且不断的变革，以满足服务用户、让用户爽的核心理念：
-
业务连续性要求高：从原来5x8小时服务，演进到7*24小时服务；
-
处理速度更快：从原来的效率不高到现在极致响应，平滑支持双十一业务；
-
更高的开发运维效率： 从传统以月为周期的变更，到一周两个迭代，甚至两天一个上线；
-
运营成本显著下降：用更低的成本去运行更多的业务；
这就是招行这些年面对时代挑战不断做出的重要变革。
数据开放平台的应对策略
在数据库方面，我们的应对策略主要包括3点方案：构建金融高可用架构，加强云服务和DevOps建设，分布式数据库创新。
1架构原则
为建设稳定、高效的金融科技架构，招商银行总结了13条建设原则，这些原则源于实践，是最为宝贵的实践升华：
-
建设多中心
当一家公司由小变大，就一定要考虑多中心建设，多中心才能让我们的业务获得真正的安稳，在公有云上就是考虑多个AZ （Availability Zones）。
冗余是基础；建设多中心，提升容灾能力和扩展能力，提升机房升级、搬迁时的业务保障能力。
-
组件失效免疫能力
在单一AZ里，一个组件一定要具备单一组件免疫力，单一组件损坏无业务影响。
在建设时要思考单一应用、单一硬件、甚至单一基础设施、单一站点灾难，要能够明确回答组件失效的业务影响，故障恢复能力，要明确知道你的成熟度在哪里
-
高可用是运维核心要求，容灾是最后屏障
高可用是业务连续性的核心。通常我们知道，数据库架构双活比单活好，Oracle RAC 架构比单节点+DG好，MGR 比复制架构好；重要系统要做好高可用、容灾建设。
-
扩展性很重要，尽量做到水平扩展
要能够做到水平和垂直扩展，扩展性对于数据库来说非常重要。
避免过度依赖纵向扩展，同时具备纵向、横向扩展的能力，例如无状态应用多地多套负载均衡多活部署，数据库分库架构。
-
坚持交易机、节点机分离原则
在业务上要梳理清楚交易机和节点机，设计不同的可用性架构。区分真正的核心业务、重要业务、渠道、内部业务。
交易机和节点机的区别和技术实现：
交易机指承载客户、账户、账户交易、账户协议等数据一致性要求极高的业务的系统。
节点机指不含上述重要信息，只有交易相关的配置类信息，交易上下文无关，甚至不保证提供交易痕迹追溯的系统。
交易机采用的架构，最佳为分库、多活；和节点机分离后，应该也更有条件为交易机铺设专用高速公路。
节点机采用的架构，因其接近无状态，最佳为互相之间无关系的多库，其次为读写分离、缓存，甚至无数据库。
-
为关键组件（数据库）减负，特别是数据库的访问
数据库成本最高，扩展性最难，可用性保证最难，恢复难度和时间难度最大。
所以要时时考虑为数据库减负，像很多公司一样，招行的规则也是，复杂的功能能不用就不用，比如存储过程触发器；使用最简单、成本最低的语句，避免大事务，慎用两阶段事务。
-
选择成熟的平台和技术，同时是你最熟的，玩深玩透玩到极致
原则：用熟不用生，用好不用坏，用少不用多。
-
应用解耦
数据库之间不要有太多的耦合性，对数据库访问一定要有中间层包装，降低耦合度。指导思想如下：
通过应用访问数据库而不是直接访问；
重要业务不能依赖低保障级别的系统；
应用层重要业务和普通业务解耦；
关键业务要独立；
-
建立灰度数据库，减少发布时变更数据库对全局的影响
要建立灰度库，在系统上线前可以用灰度库试运行。
只有应用程序灰度是不够的，还要有专门的灰度数据库。
在分库/读写分离架构下，一套含数据库的完整应用架构，变得很自然。
-
建立高仿真架构体系
高仿系统是帮助我们在遇到特定的问题，如BUG，可以通过高仿库一帧一帧的去回放模拟，以验证和找出问题。以下这些问题都是高仿系统发挥价值所在：
数据库、操作系统升级，应用是否适应？性能会变好还是变坏？
应用上线发布，系统变更（例如换平台），提前判断业务影响和性能极限。
应对突发交易量，例如双十一，性能极限在哪里？瓶颈在哪里？
-
应用和数据库一起考虑可用性、效率，故障恢复
应用和运行人员一起，解决例如应用解耦、数据库解耦、追账补救，业务监控、应用路由，故障切换等。
-
合理选用同步、异步方式
在进行复制时，选择怎样的复制方式也非常重要，CAP理论中，C和A的选择要依据业务的需要，找到适合自己的复制方式。
业务系统间；两个数据库间。
异步方式可以防止故障和效率问题的蔓延、扩大化，但会更复杂。
-
连接池的要求
连接池往往是大家容易忽略的地方，当数据库建设好，数据向外流转，大家可能缺省的就认为其他环境问题不大，这是一个误区。连接池的异常很容易引起雪崩，导致系统不可用。
我们遇到的可借鉴问题如下：
长连接；
自动重连；
延时和异常记录；
弹性连接；
监测满；
异常告警等；
进阶要求是记录所有访问情况，可以扩展出很多能力。
还有很重要的是应用的数据库连接池设置，数据库允许的连接数设置等等。常见问题：
应用的数据库连接池设置偏小，一旦数据库响应慢（例如新上线应用，缺索引等），则应用排队严重，甚至雪崩。而遗憾的是，此时很可能数据库的能力还远没有用尽。
不具备失效及时发现和重新连接数据库的能力。
缺省隔离级别设置不对。
以下是招行MySQL数据库的高可用架构，我们在架构上消除了单点，从主机、存储、网络上都消除了单点，高可用是最基础的保障，有了高可用，才能在其上构建其他的架构，比如分库分表、读写分离。
1基础高可用架构（MySQL）
1架构的可用性与扩展性
在高可用架构设计上，遵循读写分离、分库分表、无状态冗余、数据放通四大原则。
-
数据放通：是指关键路径上某些涉及数据库的非核心操作（例如记录日志），不强依赖数据库，异步延迟写入数据库
-
无状态冗余：是指在应急的时候，通过预先创建数据库或表快速接管“无状态”的应用，达到快速恢复业务的目的；核心操作有不强依赖数据库的备选途径
-
读写分离/缓存
-
分库分表
1读写分离
读写分离适用于那些以读为主，读多写少的业务场景。并且业务对读的延时是不敏感的，允许和容忍主从复制的延时。在这样的架构中，我们可以将一组应用服务器和一个数据库服务器形成一个逻辑数据中心，可以分布在不同的AZ，形成读写分离的高可用架构。
1分库
分库的好处是显而易见的，通过拆分，可以分担负载，同时提高可用性，即使有某个数据库不可用，也只是损失了 1/n 的可用性。
分库常见几个基本问题：
-
在哪一层实现分库路由？
A. 在web server/app client层实现分库
B. 在APP Server层实现分库
A方法明显优于B方法，使用A方法实现一组应用和DB绑定，部署在一个中心内，形成逻辑数据中心；多个用心部署在多个物理中心，此为最佳实践。
如果采用B方案，由于APP Server和db之间交互次数较多，响应时间比较敏感，限制了跨中心部署，同时架构和访问关系复杂化，故障定位难度大。
2.分多少个库
A. 根据能够承受的交易量损失百分比来测算
B. 同时结合多中心的基础设施能力
C. 根据单库交易能力，总交易需求来测算
有一个原则是，不要分太多，当分库已经较多的时候，优先考虑应用优化、db优化、垂直扩展。以降低资源消耗和管理成本。
3.路由方法？
A. 直接路由，适用于交易总是以分区键来进行的情况。
B. 查对照表路由。适用于交易凭证有多种的情况。
1云服务能力&DevOps建设
以下是招行在开发和运维等方面的建设实践。
投产发布流程纳管数据架构设计
交付自动化
发布自动化
统一运维平台化
最后对招行的架构思考做一个总结：
-
总体原则：采用最合适的架构，既满足业务需求，又取得成本收益平衡。
-
最好的架构是没有数据库！
-
保障基础架构高可用能力
-
综合使用数据放通、无状态冗余、读写分离、分库分表等方案
-
核心交易，能分库的就分库
-
核心交易，不适合分库的，竭尽所能把核心做小，然后靠垂直扩展来扩容，用尽各种高可用、容灾手段保证其可用性。如果能做到双活或多活接入，也很有价值。
大会的演讲视频已经发布，大家可以通过视频了解作者演讲的实况风采：
http://www.itdks.com/dakalive/detail/10699
原文链接
https://mp.weixin.qq.com/s/fQRk9riF7ivyZqOGP2gzNQ