一、数据库转型背景

1、传统IT架构的挑战

大型国有银行,整体核心的系统都是大机+DB2这样的传统架构;针对现在的互联网金融业务快速扩张的需求,传统的架构面临着比较大的挑战,主要集中在四个方面:

处理能力;因为工商银行这么大的体量,导致整体系统的规模比较庞大,这种垂直的单一的扩展模式,不具备横向处理能力,处理能力受到限制;

运行的风险;随着很多的业务从网点变成线上,新的业务提出了更高的业务连续性保障,包括7×24小时,传统的架构从架构设计上无法做到这样的支持;

快速交付;传统的开发模式应用内部模块、应用与应用之间的耦合度非常高,使得软件的开发和产品交付周期比较长;

成本控制;大型主机运营成本非常贵,买个机器帮你搞两下就几千万上亿的支出,再加上商业产品的License比较高,银行议价能力又比较低。

在这种情况下进行IT架构转型,整体的诉求是优化应用架构、数据架构、技术架构,建立灵活开放、高效协同、安全稳定的IT架构体系,强化对业务快速创新发展的科技支撑。
工商银行基于 MySQL 分布式企业级解决方案实践

2、转型的核心诉求和策略

在上面的转型大背景下,数据作为核心,展开了对开放平台的数据库的架构转型,同时提出了几个核心的策略:

首先,在业务支撑方面,做到高并发、可扩展、支持海量数据存储及访问。以及两地三中心高可用容灾。工行在国有大型银行里应该是比较领先的实现两地三中心容灾体系。

其次,降低使用成本,基于通用的廉价的硬件基础设施,希望提升管理控制能力,进行行内适配和定制。降低对商业产品依赖,提升议价能力。

还有就是运维能力,提升数据库的运维自动化智能化,更加开放的技术体系以利于自主掌控。主要采取三方面策略:

集中式向分布式的转型;

是专有向通用的转型,也就是去IOE;

限制商业产品,拥抱开源;
工商银行基于 MySQL 分布式企业级解决方案实践
二、转型的发展经历

1、转型之路

整个的发展历程大概可以分三个阶段:

第一阶段:原型的研发和探索

结合人民银行对于个人账户的管理要求,实行一类二类三类账户。

结合这样的工作要求,把个人账户从主机下移到开放平台,基于开放平台的高性价比、可扩展进行了很多的探索,进行了很多的技术验证。

当验证了技术可行性之后,我们提出了一个开放平台数据库转型的规划,这个规划对于后面的工作,对于数据库的方案选型是非常大的影响。

这个规划确定要建设基于开源的MySQL OLTP数据库解决方案。

第二阶段:基础研究和试点

我们基于开源的MySQL数据库进行产品的研究和能力的建设,以及初步能力的建设,包括基础研究和应用的试点。

在生产线上跑起来了,把整个技术体系都进行了验证。

第三阶段:转型实施及推广

2018年开始大规模的实施和推广,在这个过程中基于开源的MySQL数据库,我们逐步建立起了一个企业级的数据库服务能力,包括引入了分布式的中间件,在高可用、运维能力的提升,资源使用率的提升,MySQL的云化及自主服务的建设等等。

在整个过程中,同步对OLTP的分布式数据库进行了研究,也对后面的工作指导提供了依据;
工商银行基于 MySQL 分布式企业级解决方案实践
2、选型阶段

1)方案选型调研

在选型阶段,我们基于业务场景进行了大量的方案调研。坦率的说,持续关注着行业内数据库的发展和生态的发展,在这个过程中我们对很多的产品进行了一些研究和摸底的测试。

NewSQL数据库方案,是很多的互联网企业或者一些小型企业有所使用的,但是我们在选择技术的时候是非常谨慎的,以及要做非常多验证,在当时并不符合系统设计的考量点。

基于开源的分布式OLTP方案,业界有很多丰富的案例,而且在互联网企业里面得到了很好的实践,在业界资源案例都很丰富,是同时能应对工商银行的高并发、弹性扩展需求的。

所以我们最终确定从分布式架构的角度去解决整个架构的挑战,不仅仅只从单一的数据库的层面解决这个问题。
工商银行基于 MySQL 分布式企业级解决方案实践
2)分布式技术栈

基于这样的一个原型探索,我们构建了一系列的分布式架构技术栈,包括分布式服务、分布式事务框架、分布式批量框架、分布式缓存、交易数据核对及补偿、分布式消息、配置中心、开发及运维管理。

这里简单说一下:

分布式服务改造,针对传统架构耦合比较紧密的特点,通过服务化的改造,降低耦合度。降低耦合度的同时,还可以尽最大可能的避免分布式事务的产生;

分布式事务的框架,我们结合两阶段提交和分布式的消息,支持强一致性和最终一致性多种模式的支持,通过分布式事务框架解决分布式事务的问题;

分布式批量框架,在大规模的数据结点上进行批量操作的一个整体的解决方案;

业务层面,在交易或者应用级层面进行数据核对及补偿,有些场景就是在传统的OLTP的情况下,也会对应用上下游进行核对和补偿;

分布式消息平台,实现这样一个应用级的数据交互;

同时我们也进行了运维的规划和总设计。这里引入了开源的MySQL数据库来解决数据最终落地的问题。
工商银行基于 MySQL 分布式企业级解决方案实践
3)MySQL高可用方案

在原型阶段,当时主流是MySQL5.6、5.7才刚出来;对于高可用要求,工商银行的应用是要做到同城切换,上海两个园区要做到RPO是0,RTO非常小,同时异地北京有一个灾备中心,就是两地三中心。

AB类重点应用必须具备这样的同城两个园区同时对外服务的能力。

在原型设计阶段,我们基于MySQL的半同步复制,来做这样的一个切换,实现RPO=0,解决主库故障自动切换到备库,同城为了保障RPO=0,在原型阶段进行了应用的双写,来进行数据的核对和补充。

这里顺便提一下,MySQL5.7相对5.6的改进非常大的,这是一款真正可以适合金融行业的数据库产品,它在数据回放方面,在性能方面都有比较大的改进和提升。
工商银行基于 MySQL 分布式企业级解决方案实践
3、实施推广阶段

1)基础研究和应用试点

第二个阶段是开源MySQL基础研究和应用试点,对于这些元素研究以后,要发布第一个产品;把这个产品推上线,要做很多的工作:

产品的基础研究,需要验证功能、新特性和配置基线,数据备份恢复,还要结合它的特性来设计应用的高可用,提供开发的技术规范;

我们的角色既要考虑到运维,也要考虑到上游应用,做好上面的衔接、对接和支持。

包括应用的开发规范,它的性能能力评估,上线需要多少设备,容量是多大,还要对Oracle等老架构给予指引和帮助,代码写不好还要弄个检查工具等等。

运维方面就是要提供各种安装部署的便利化,然后行内和行内的监控系统进行对接,制定很多的指标和参数,如何和行里进行对接,然后新问题的分析等等一系列的问题。

在这个阶段我们实现了同城RPO=0,RTO=分钟级目标,RPO为0的切换,问题可监控,实现了人工或自动的一键式切换。

这个阶段,工商银行决策了之后,我们一下子上了21个应用,211个节点。
工商银行基于 MySQL 分布式企业级解决方案实践
2)分布式中间件应用

2018年开始转型和实施,并且大量应用上线;之前的基于应用级的分布式解决方案,遇到了一些新的限制。

部分应用不想设计的过分复杂,这个时候引入了开源分布式中间件DBLE,引入它的目的就是为了简化开发的工作量。

通过引入这样一个DBLE来支持垂直数据分片、水平数据分片、混合分片等场景的支持,还支持简单的跨库汇集查询提供类似集中库的操作体验,这个时候开发场景就简化了,给了应用更多的选择,简化了应用开发的复杂度。
工商银行基于 MySQL 分布式企业级解决方案实践
3)运维架构流程完善

解决了应用开发的复杂度,运维怎么办?高可用怎么办?

我们结合DBLE和运维管理平台,实现整平台联动,支持从高可用、监控告警、安装部署、自动化补数等等一系列的解决方案。
工商银行基于 MySQL 分布式企业级解决方案实践
4)运维管理能力沉淀

这时进行运维能力的提升,也迫在眉睫;因为分布式随着实施的运维节点的增加,运维是一个很大的挑战,那么多的节点,安装、监控、报警、故障、人工处理等非常麻烦。

我们的做法:

第一是先提供一个自动化的安装部署,实现批量安装部署,批量串行还不行,时间太长了,要并行,并行太高了,网络的流量会受到比较大的影响,所以这个方面有很多的场景都需要打磨。

第二是监控告警,监控告警里有事件等级,分各种等级,这些需要灵活的定制,建立基线告警,建立应急流程。

第三是故障的分析,完善日志记录、采集和分析,建立故障分析规范。

第四是自动巡检,自动化的巡检和评分报告,对实例状态进行健康评分。
工商银行基于 MySQL 分布式企业级解决方案实践
5)统一运维平台建立

我们通过这样一个统一的运维管理平台,把所有的节点都纳入进来了,实现一键式的安装、版本的升级、参数的配置。并且实现了多种高可用策略配置,包括自动、人工一键式切换。

谈到为什么要有自动化和人工的两种切换方式?

一种新的事务上线之前,都会面临一些挑战和怀疑的,都是一个循序渐进的过程,特别是是在金融行业,我们实现了多种高可用策略的灵活配置。
工商银行基于 MySQL 分布式企业级解决方案实践
6)故障自动切换上线

我们建立了一个自动化、高可用的决策系统。大家知道人工决策到自动切换,虽然只是迈出一步,但是面临着很大的挑战:

包括决策的因素和决策的模型,最难的是还要应对不同应用场景的需求,有的时候说RPO优先,有的RTO优先;有的要求三分钟搞定,有的说10秒钟5秒钟我都难受。你要有这样的模型适配这样的场景,这是非常大的挑战。

在整体上面基于MySQL的复制技术,我们有半同步复制和多数派共识机制实现冗余备份。基于MySQL binlog日志自动数据补全,保障数据的一致性。
工商银行基于 MySQL 分布式企业级解决方案实践
4、实践中的改善优化

1)高可用方案改进

同时实施过程中我们走的比较快了,一年几百个节点,几十个应用。

在这个过程中,我们又对高可用方案进行了持续的优化,同时学习和借鉴互联网包括分布式数据库的一些方案,我们把一主两备,本地1备和同城1备,扩展成1主3备,通过半同步的机制,做到真正的在系统级去保证RPO=0;
工商银行基于 MySQL 分布式企业级解决方案实践
2)异地灾备和存储优化

异地灾备和存储方面,当初跑的太快,方方面面有些没有考虑那么完备。

在上海到北京有一个灾备。数据灾备刚开始方案,采用磁盘复制实现灾备,这个也是要支出软件费用,也比较耗钱。

还有就是冷备,无法热切换,RTO至少半个小时以上。这个方面我们改进了,用了MySQL异步复制。

另外存储方面沿用的集中存储,一套集中存储上面同时支撑六七十上百个MySQL实例,IO的性能非常容易成为瓶颈。

在应对一些高并发场景的时候,因为IO性能不足,这方面我们就改进了,直接引入了SSD盘,基本上把MySQL、IO的瓶颈给解决了。

在现在的场景下,IO一般不会成为瓶颈了。同时通过SSD的引入,交易的响应时间在相同条件下降低50%。
工商银行基于 MySQL 分布式企业级解决方案实践
3)MySQL 容器化探索

MySQL的上容器,首先说一下为什么要搞这个事情?

因为工商银行一两年转型过来,大规模的上MySQL数据库,节点非常多,机房和设备成为一个瓶颈,再这么玩儿下去机房容量不足了。这个时候需要提升资源的使用效率。

在很多应用里,因为它的超前规划,一般为了稳定运行,基本上都提出资源申请的时候,都是物理机,为了满足后面几年的业务需求,大规模的申请物理机,但当前应用的交易量又不是那么大,浪费比较严重的。

这个时候我们提升资源的使用成为紧迫的问题。这个过程中为什么选择MySQL的容器呢?

几点考量:

行业里的商业软件都是用的VMware;

VMware在IO方面,在系统性能方面都有比较大的损耗;

工商银行在IAAS、PAAS方面建设好多年了,无状态的应用服务其实全部上了PAAS,全部上了容器,在这方面有一些技术的积累,结合云战略的规划,所以MySQL选择了上容器。

上容器解决的两个技术要点:

容器对数据的持久化支持;

对服务的暴露。

整体MySQL上容器,在现阶段仅仅是把它作为一个虚拟化的技术,它的整个高可用,包括它的整个监控、整个的安装部署都是通过管理平台来实施的。

通过上容器,我们提供了一键式的环境供给能力,通过上容器把IAAS、PAAS全部打通过了,能很快的把基础环境,按照工商银行的标准和模式很快的供应出来。

资源的使用效率提升提升了4到5倍。截止当前MySQL上容器这块,应该是有400多个节点。
工商银行基于 MySQL 分布式企业级解决方案实践
三、转型成效

1、转型实施成果

实施了至少120多个应用,2000多个服务器节点,超过2500个MySQL节点。

实施的应用涉及很多核心业务,包括个人账户、对公账户、基金以及很多A类、B类的应用,大多都是主机上迁移过来的。其中还有少量应用是从Oracle迁移过来的,应用层也因此需要重构。

通过MySQL支持的核心交易达到日均7亿的交易量,经历过双十一、2018年的双十一和春节的高峰期的1.5万的TPS。

我们的架构现在通过横向扩展可以达到几万的TPS。我们就是基于3万TPS的设计目标进行了架构设计,理论上通过扩展设备还可以无限地增加。如果通过主机想达成这个目标,那么挑战就会比较大。

另外通过良好的架构设计,我们可以满足两地三中心的架构要求,做到同城RPO=0,RTO<60s。现在很多的“多活”,包括互联网公司的架构,都是最多能够做到分片双活的维度,两边同时提供对外服务,但是同时对于某一分片数据的写入只能是单活的。

通过架构转型,初步建立了企业级的基于MySQL的分布式解决能力:

首先是分布式框架+MySQL的应用级分布式解决方案,这个方案承载了很多的从主机下来的应用;

其次是基于分布式中间件构成了所谓联机交易的数据库,这样能应对一些不是很复杂的场景,通过良好设计的分库分表方案就可以满足需求。

在成本方面,在主机上的成本投入明显下降。

这几年工商银行的业务交易量每年以20%的速度增长,但是主机并没有进行扩容,投入还逐年降低。商业产品的数据库的使用不仅实现零增长,还有所下降。从整个经费上来说,应该有比较大的降幅。
工商银行基于 MySQL 分布式企业级解决方案实践
2、典型案例

1:个人账户平台

介绍一下作为我们架构设计原型的个人账户平台,这是从主机上迁移下来的应用。

当时的交易要求高并发、低延时,日均交易量3亿,这个应用的内部交易延时不能超过100ms,要求7×24小时的联机服务。

我们实施的架构是高可用架构同城分片双活。实施效果是日均交易量超1亿以上,本地高可用做到自动化切换,RPO=0,RTO<30S。同城高可用切换也是60秒内切换。

同时结合MySQL的管理平台,对自动化的切换能力进行了包装,同城的切换会面临着比较大的挑战:

本地的高可用切换是基于SIP的,它是对应用透明的;

同城切换是对应用不透明的。

于是我们设计了从服务器到数据库的整体切换流程,数据库要和应用服务器进行一些联动来实现同城自动化切换。

2:信息辅助服务
工商银行基于 MySQL 分布式企业级解决方案实践
另外一个案例就是通过DBLE实现分布式数据库。

这是第一个数据量比较大的系统,它要求高并发、低延时,日均交易量2亿,交易响应延时要求10ms以内,当时的业务数据量大概20T左右,还要求7×24小时的联机服务。

我们的架构是通过分布式中间件做MySQL的分库分表,一共128个分片。我们对分片进行了合并部署,这看上去像是过度分片,但是资源使用上就收益很大。

DBLE中间件在日间进行联机服务,夜间进行批量变更,把主机上的一些数据同步下来。

这个架构整体上实现了本地和同城完全自动化切换,RPO=0,RTO<30S。