高达200个应用，近8000个实例的工行MySQL转型实践

本文根据魏亚东老师在〖2020 Gdevops全球敏捷运维峰会〗现场演讲内容整理而成。

（点击文末“阅读原文”可获取完整PPT）

大家好，感谢dbaplus社群给我这个和大家交流的机会。今天我只是抛砖引玉，因为不知道大家感兴趣哪块，所以我就把工行转型所有的历程，包括我们在研发层面的管控跟大家做个分享，期望可以对大家有所启发和帮助。

一、ICBC数据库转型背景

首先介绍下工行进行MySQL转型的背景，大概有以下四方面的考量：

1、利润提升

大家知道工行的利润在四大行当中是最高的，怎么持续做到利润提升？简单来说就是开源节流。

众所周知，国有银行以前存量核心体系核心都是DB2，OLTP系统是Oracle，这种架构类型很成熟，但是运营费用昂贵，机器和服务随便就要几千万几亿资金的支出。

随着大数据时代步入成熟期，我们从数据存储从TB发展到PB，科技业务量呈指数增长，大家可以看到线上化处理已经成为主流，特别是在疫情开始后，这对银行的处理能力和峰值吞吐量施加了双重压力，传统集中式这种方式已经不能满足我们的需求，我们也付不起这个成本，而基于通用的廉价的X86硬件基础设施在业界互联网头部公司已经广泛使用，可行性毋庸置疑，所以我们就开始借鉴他们这种方式来做。

2、同业领先

大家都说我行是宇宙第一大行，所以我们行的科技队伍人数最多的，我们要做到同业领先，大致有两点诉求：

• 同业竞争，之前互联网金融所谓的金融科技或者科技金融，其业务实际上是允许打擦边球的，这就对银行的业务量提出了一个挑战，要求我们的业务可以做到快速上新，而业界基于DevOps的快速交付和灰度发布常态化，也是应运而生的产物而已；

• 大家对商业银行有很高的期望，特别是国有银行，代表着国家声誉，这就要求我们必须支持24小时处理业务，即客户想用你的时候不能出问题，这就对高并发、高可用性、海量数据的处理提出更高的要求，不能宕机。

3、技术自研

全球化的趋势要求技术无国界，但是从去年开始的贸易战，以及美国的实体管制清单，我们可以看到技术是有国界的，比如之前HashiCorp发布公告，其企业版产品禁止中国使用已经成为一种征兆。所以拥抱开源、提升技术自研能力，解决对商业产品的过度依赖其实是一种趋势，但是也要注意到，不是所有的开源产品有没有问题，大家一定要注意审阅开源许可证，比如GPL这种传染性许可证其实风险很高。同时从银行业务的特性来看，实现分布式可扩展架构，做到在线扩缩容，满足银行对事务强一致性的处理要求，对我们的技术积累都是一种不小的挑战。

4、长远规划

我行数据库产品的长远规划简单来说就是2步走原则：

二、ICBC数据库建设历程

大家可以看下我行数据库的建设历程，我们最早是从2014年开始基于MySQL 5.5建立 MySQL 运维平台。因为是小打小闹，并未成体系化，所以2016年才是我行第一阶段建设的开始，逐步完善周边配套。从2018年中旬开始，是我行第二阶段的建设。

第一阶段是探索MySQL的可能性，试点成功后就开始全面推广，并持续完善研发和运维自动化体系。

第二阶段遵循两步走的原则，一方面随着数据库越来越增多，运维成本大幅增长，资源利用率不高，所以我们将MySQL上云，后面我会介绍成效，大概90%都是基于云数据库。

另一方面，我们还要扩展技术路线，试点新产品GaussDB和OceanBase，落地5个产品场景，一是在物联网里做了一个创新，二是在基于其他的业务场景化。单纯从应用场景来看，其可以满足银行业务要求，但是它们的生态环境不太好，就是配套周边有待完善（这里指除原厂以外的生态圈），相对MySQL来说还是有所欠缺。

三、ICBC MySQL实施成效

来看看我们的成效，有以下四点：

1、高度自主自控能力

我们基于开源技术构建了企业级的分布式解决方案，MySQL数据库解决方案，满足不同业务场景的需求。还自研运维管理平台，实现规模节点集群化、自动化、标准化管理。

2、广泛运用于各业务场景

MySQL应用高达217个，MySQL数据库实例接近8000个，为主机应用下移提供数据服务支撑，经受了支撑双十一、春节业务高峰万级TPS的真实考验。

3、同业领先数据库云化服务

我行在同业率先达成了MySQL的大规模云化部署，占比达到90%以上。同时我们提供了一键式的快速供给，一键式的运维管理，简化了运维操作流程。

4、秒级恢复、分钟级切换

多站点数据存储，保证数据强一致性，实现同城双活RPO=0。本地故障秒级恢复，无需人工干预，业务系统无感知，园区级故障分钟级同城切换。

四、ICBC技术路线

我行技术路线其实应该跟大家玩法一致，我们最早是和腾讯做的交流，所以我们的技术路线有点接近于腾讯，使用应用架构的服务网关加上处理分组，配合运维管理平台实现的。处理分组，也就是所谓的set实际上包含了联机处理功能的服务器集合，既有中间件这类应用服务器，也包含了MySQL的数据库服务器。

当交易请求过来时，首先通过SLB（或F5）进行负载均衡后，到达服务网关，服务网关会根据业务预设的一些字段，比如用户ID、银行卡号、帐号进行一致性Hash以后，分发到对应的处理分组上，由对应分组处理完成以后返回结果，从而完成交易链路的处理。

同时我们会结合应用场景对数据进行分片，大概会做128个分片，并对分片进行合并部署。

最后我们在每个MySQL服务器部署一个Agent，定时采集快照信息、监听可用状态等，统一上送给管理平台，管理平台可以生成AWR报告，也可以进行数据库探活。如果某个数据库被监测到有问题的时候，数据库运维平台就可以做到自动化的切换，实现了数据库层面的高可用能力。

1、ICBC技术路线-分布式访问层

对于分布式访问层，这个其实褒贬不一，因为业界争议很大，比如业界有阿里的TDDL，还有网易的DDB这种成熟的产品。但是我们为了完整性，最后也是做了一个分布式访问层，我们的分布式访问层有两种模式，但是相对较薄，与TDDL和DDB相比存在一定差距，但是压力相对较轻，不像他们压力会集中在访问层的维护人员手中。

• 我们主推的是基于DBLE重构分布式访问层实现。我们扩展建立了配置中心，应用发版时把配置带出来，访问层自动下载配置并完成热加载，实现自动化部署，规避开发人员在某个地方维护Server.xml等配置文件。当出现园区故障时，通过智能DNS自动路由到F5，然后再到DBLE集群，实现了应用服务器到DBLE集群的本园区就近访问、负载均衡和故障自动转移能力；DBLE做到无状态设计，通过F5实现故障自动转移，MySQL故障自动切换，联动管理平台，支持数据一致性校验和自动补齐；

• 另一种模式我们称之为轻模式，类似于TDDL的sharding模式，随应用进行部署，根据算法和配置路由到具体的数据库节点，降低了运维难度。

2、ICBC技术路线-高可用

对于高可用来说，我们的高可用历程是学习和借鉴互联网零头公司的经验发展而来，提供两种模式，这个应该是5.7的固定模式。

• 灾备五级采用一主四从架构。1主库、1本地半同步库、2同城半同步库和1异地异步库；

• 灾备四级采用一主三从架构，1主库、1本地半同步库、2同城半同步库，从经验来看，大概性能会下降一倍，但是对于银行来说这是必须要承担的一个代价。

五、ICBC研发管控挑战

1、问题

说了这么多，大家只看到MySQL的好处，但是免费的午餐并不好吃，其对应用到的研发管控层面造成严峻挑战，这一点大家务必注意，技术可行性不等于研发落地的有效执行，同时也不等于落地执行复杂度的降低。我们在进行研发管控的时候发现了3个层面的问题：

• 研发习惯层面。首先设计人员思维还是基于Oracle的思路，习惯用VARCHAR2这种万能字段，但是MySQL要求表结构设计选择用合适的字段；同时开发人员喜欢存过和夺标链接，动不动就5张表以上连接的复杂语句，而且不看执行计划，在Oracle数据库中没什么问题，但是MySQL不行，会挂掉；我们可以看到即便阿里有规约，慢SQL也是他们不可承受之痛；此外，开发人员习惯于大事务，这会导致主从同步延迟，对主备切换其实造成很大压力；

• MySQL有很多缺点和bug，耳熟能详的解释器弱，in、exsits语句对性能会造成很大影响，同时bug不断，truncate阻塞同库交易、Replace into自增列主键冲突、死锁、Page Cleaner脏刷会阻塞IO等等；

• 运维复杂度成指数级增长，设备量级提升10倍，扩大机房等物理设施实质会造成困扰，资源利用率低（CPU、存储），所以上云时一种必然趋势；同时网络流量并发大也是一个潜在隐患。

2、ICBC研发管控层面

为了应对这些问题，我行在研发管控层面建立了一个完整的生态圈，这里我建议大家也可以自己做一下。因为最主要的一个问题是慢SQL的数量会随着应用的增加呈现爆发性增长，这一点阿里也公开说过，当时他们也是因为慢SQL的爆发式增长导致他们必须要建立SRE这个体系，所以我们是在设计、编码、测试、交付后四个阶段都做了一些处理，并建立了相关门禁，一环扣一环，确保问题及早发现和解决。

• 设计

在设计阶段我们编写并发布了设计指引，建立元数据的管理标准和能力提升课程。 同时通过自动化的方式形成表结构设计工具和元数据管理系统的联动体系，首先通过元数据管理系统，明确业务线和应用的字段、类型的标准，形成元数据字典， 架构师设计表时，借助设计工具联动管理系系统选取所需要的元数据自动生成即可，最后还可以生成DDL语句，方便大家在开发环境下进行开发测试；

• 编码

编码层面我们也做了自动化的门禁控制，基于Sonar体系使用Druid开发了一个数据库检查插件，对SQL 语句以及 MyBatis 文件进行解析并分析其是否符合我们的编码规范，大概可以控制住60%左右的问题语句。一方面我们落实了安全检查，比如SQL注入检查，实现安全层面的保障。另一方面对它的写法规则进行审视，提早发现不合理的写法，毕竟MySQL跟Oracle不太一样。通过质量门禁的方式可 以确保开发人员在这个层面做到强遵守，严落实，以最小代价规避生产隐患；

• 测试

在测试层面我们建立安全测试和性能测试的处理机制，基于OWASP的ZAP落实黑盒测试，同时做好重要交易的性能测试，确保重点交易满足业务高并发要求，提升用户满意指数和幸福指数；

• 交付后

交付后我行建立了SRE管理体系，对慢SQL进行监控治理，对大事务自动查杀，提前规避生产隐患，同时会把相关案例分析和生产问题总结成经典案例，让大家学习，提升大家的意识，逐步建立对生产安全的一种敬畏感。最后我行积极践行AIOps，基于全链路跟踪的处理数据，实现根因分析，逐步向1-5-10的业界故障诊断目标看齐。

六、ICBC系统运维

1、ICBC系统运维层面-自动化环境供给

从系统运维层面，自动化环境供给，在2019年DAMS峰会已进行过分享，提升资源使用效率约4-5倍，加快资源部署速度，提升内部管理效率。这里有两个问题。

• IP漂移问题，我行有别于K8sOperator，底层扩展K8s实现容器的固定IP，SDN实现容器网络资源自动化申请；

• 二是IO征用问题，SSD替换盘机，并做了RAID1，从性能来看，效果完全满足需求。

2、ICBC系统运维层面-自动化运维

从运维层面，自动化运维实际上是对数据库的一个可用性、可靠性、性能等进行监控，涵盖100多项监控项指标，同时基于AIOps实现1-5-10故障定位目标，及时告警。我们每个月都会对慢SQL进行常规性治理，可以看到下面这张模型图，我们建立了一个三维雷达图，按总数，慢SQL耗时以及建议优化方案和整改计划，同时我们做了一个慢SQL自动查杀方案，确保慢SQL不会对生产造成巨大影响。因为我们之前有个案例，一张表忘记建主键，备库24小时都没有追上主库。

自动化安装部署，我们对分布式MySQL数据库组件的安装配置、高可用、数据灾备、升级维护都进行了覆盖，DBA现在应该是业界最少的了。

智能化高可用，集成了高可用切换功能，支持数据优先、同城优先的处理，融合智能告警和高可用切换动态管理，提供切换异常智能化告警和高可用保障建议能力。

3、ICBC实际场景-客户信息系统

工行的客户信息系统承载了我行客户信息管理职能，涉及6亿个人客户和1千多万对公客户，总记录数超过160亿，每日2亿次客户信息维护与查询，最高并发数7600TPS，平均交易耗时小于30毫秒，支持应用范围同业最广、日均访问数量同业最多的处理。

七、ICBC分布式数据库的规划

后续一些规划实际上是这样的：

1、MySQL其他缺陷

MySQL其实还有些其他的缺陷：

• GPL，它是GNU通用许可证，具有传染性，存在风险。如果要是商用的话必须要第一时间购买它的商用许可，或者将自己软件也同步开源，但这个实际上是很难做到；

• 它无法支持分布式事务，分布式事务原则上是在应用层解决，增加了设计复杂度，我行建立了一个分布式事务应用，支持三种模型，TCC、SAGA、还有XA模型，根据不同业务场景去规范应用使用。对于要求强一致性的话，比如账务处理，我们原则上都要求使用TCC模型去进行处理；

• 复杂SQL支持能力弱。我们做了一个基于Hive的通用查询方案，可以减轻系统的负担，业界同时还有ES的解决方案，都是比较好的处理方式。

2、探索新技术路线的挑战

探索通用分布式事务数据库方案，可能数据库自身没有问题，但是从它的生态圈来说是有问题的，不够成熟，比如PG、OB和TiDB等产品还是缺乏成熟丰富的生态体系。我们使用起来的话会很痛苦，同时国产数据库蓬勃发展，技术路线差异很大，方向也没有明确，所以后面我们还会继续跟进分布式的各个产品，去保证我们会有更多的积累。

A1：因为很多数据库我们都看过，但是从生态圈来看，我们现在主流还是选了MySQL，PG就是高斯。但是从这个生态来说，PG的生态真是不好。从运维层面，这些工具链其实都偏MySQL支撑，所以我们现在PG还只是属于推广使用阶段。对于高斯，我们大概是5个应用，但是MySQL的应用有217个，所以说后面我们肯定还是会去做国产化的这些改造，但是具体大规模的使用，这个可能还是要看生态圈的完善，因为银行毕竟要对大家负责。

Q2： 关于分布式数据库，刚才更多的是储存结构的数据库，其实分布式可能也有好多 技术路线，您认为中间件还有基于计算存储这样一些云原生的架构，您觉得哪一种可能会更符合工行对这个数据的需求和规划？

A2：你说的后两种其实都可以。第一个是云原生，工行云是同业间最好的一个云，所以我们云原生数据库肯定是第一个必然的规划路线；第二个是分布式数据库，也是我们的一个考量。

Q3： 基于中间件做分库分表这种架构呢？

A3：其实我们数据库分布式访问层比较弱，也不建议做强。因为之前跟网易、阿里聊过，他们最后的问题都是集中在数据库保密层，他们相当于保姆，而开发人员就不管，所以我们还是从设计开发人员层面入手，把数据库先直接在应用层做到分布式的拆分处理。

Q4： 问一下MySQL有什么强一致性是怎么做到的？

A4：我们实际上是通过自己的一个分布式的事务管理系统去做的事情。对于同一应用来说，它自身的强一致性其实可以保证，但是实际上银行的一个系统是一个链路性的系统，所以每个节点其实最终都要保持强一致性，这种我们是通过TCC的模型去做，就要求每个节点都要求TCC的方式处理事务，最终达到强一致性。

Q5： 因为我们目前也是金融公司，但是我确实没有办法重复是10 0%能过去 。

A5：半同步这个其实MySQL机制已经保证了，你只要监测到它做信息扩展，到底有没有重演，跟主步做比对，对比一下，做数据的一个检查就可以了。其实我们在做切换的时候会去检查从步跟主步ID是不是一样的，重演到什么地步，会逼迫它做强制性的重演。

另一方面，我们要求应用层面，就是有些要求比较高的应用，我们基于Redis去做，当应用发现这一层数据没有的时候，可以切换以后，可以再做一个事务的补偿。