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

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

讲师介绍：

魏亚东，中国工商银行软件开发中心三级经理，资深架构师，杭州研发部数据库专家团队牵头人和开发中心安全团队成员，负责技术管理、数据库、安全相关工作。2009 年加入中国工商银行软件开发中心，致力于推动管理创新、效能提升，提供全面技术管控，推动自动化实施，实现业务价值的高质量快速交付；同时作为技术专家，为生产安全提供技术支持。

一、ICBC 数据库转型背景

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

1、利润提升

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

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

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

2、同业领先

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

• 同业竞争，之前互联网金融所谓的金融科技或者科技金融，其业务实际上是允许打擦边球的，这就对银行的业务量提出了一个挑战，要求我们的业务可以做到快速上新，而业界基于 DevOps 的快速交付和灰度发布常态化，也是应运而生的产物而已；
• 大家对商业银行有很高的期望，特别是国有银行，代表着国家声誉，这就要求我们必须支持 24 小时处理业务，即客户想用你的时候不能出问题，这就对高并发、高可用性、海量数据的处理提出更高的要求，不能宕机。

3、技术自研

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

4、长远规划

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

• 扩展技术路线，探索新的技术产品，比如我行已经在部分应用落地 GaussDB 和 OceanBase，后面还会试验更多的产品；
• 丰富技术积累，对业界主流产品技术发展路线会做一个持续的跟踪，逐步转化成我们自身的资产，以前有幸参加过中村修二先生座谈会，其强调十年累积，所以技术积累是一个寂寞但是必须要做的东西。

二、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 等产品还是缺乏成熟丰富的生态体系。我们使用起来的话会很痛苦，同时国产数据库蓬勃发展，技术路线差异很大，方向也没有明确，所以后面我们还会继续跟进分布式的各个产品，去保证我们会有更多的积累。

Q&A

Q1：魏老师您好，我是百度数据库团队的，有两个问题我想跟您探讨一下。第一个关于开源数据库的路线问题，之前我们做了大量 MySQL 方面的工作，对于 PG 这种类型的数据库，我们目前是怎么来考虑的？因为它可能对 Oracle 的一些检测更好一些，您觉得对于工行来说，后续对于开源的数据库，MySQL 和 PG 哪一种更好？

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

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

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

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

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

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

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

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

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

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

本文转载自 dbaplus 社群（ID：dbaplus）

原文链接：高达200个应用，近8000个实例的工行MySQL转型实践