作者简介:王龙,招商银行数据中心MySQL资深架构师,将MySQL引入招商银行,并从无到有建设MySQL生态,解决了MySQL在银行领域使用的诸多问题。
本文根据招商银行资深架构师王龙在『3306π』北京活动上分享的“招行数据库架构探秘”主题整理而成,涉及到数据库架构方面的系统建设原则、MySQL实践等,招商银行在数据库应用上做出了很多探索和创新,非常值得业界学习和借鉴(在公众号对话栏回复:CMBDB 获得本文的PPT下载)。
引言
Fintech Bank 的挑战
这里涉及到什么是“金融科技银行”,“以科技敏捷带动业务敏捷,一家金融科技银行要紧紧围绕客户需求,深度融合科技与业务,快速迭代、持续交付产品和服务,创造最佳客户体验,实现效率、成本、风险的最佳平衡”,招行银行行长田惠宇如是说。
在向金融科技银行发展的过程中,招行面对了如下挑战,并且不断的变革,以满足服务用户、让用户爽的核心理念:
这就是招行这些年面对时代挑战不断做出的重要变革。
数据开放平台的应对策略
在数据库方面,我们的应对策略主要包括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方法明显优于B方法,使用A方法实现一组应用和DB绑定,部署在一个中心内,形成逻辑数据中心;多个用心部署在多个物理中心,此为最佳实践。
如果采用B方案,由于APP Server和db之间交互次数较多,响应时间比较敏感,限制了跨中心部署,同时架构和访问关系复杂化,故障定位难度大。
2.分多少个库
A. 根据能够承受的交易量损失百分比来测算
B. 同时结合多中心的基础设施能力
C. 根据单库交易能力,总交易需求来测算
有一个原则是,不要分太多,当分库已经较多的时候,优先考虑应用优化、db优化、垂直扩展。以降低资源消耗和管理成本。
3.路由方法?
A. 直接路由,适用于交易总是以分区键来进行的情况。
B. 查对照表路由。适用于交易凭证有多种的情况。
1
云服务能力&DevOps建设
以下是招行在开发和运维等方面的建设实践。
投产发布流程纳管数据架构设计
交付自动化
发布自动化
统一运维平台化
最后对招行的架构思考做一个总结:
大会的演讲视频已经发布,大家可以通过视频了解作者演讲的实况风采:
http://www.itdks.com/dakalive/detail/10699