工商银行MySQL数据库架构的实施改进
极客时间编辑部
讲述：丁婵大小：2.10M时长：04:35
上一篇文章中，我们介绍了工商银行传统 OLTP 数据库架构转型的前两个阶段，包括转型规划及数据库的方案选型，由于转型过快，在后续的实践过程中出现了诸多问题，以下内容将介绍工行在转型后的实施推广及实践中的改善优化思路。
经过对开源 MySQL 基础研究和应用试点后，工行在 2018 年进入转型实施和推广阶段，开始将大量应用上线。之前基于应用级的分布式解决方案，遇到了一些新的限制，部分应用不想设计的过于复杂。于是，他们引入开源分布式中间件 DBLE 简化了开发的复杂度和工作量。同时，结合 DBLE 和运维管理平台，实现整平台联动，支持从高可用、监控告警、安装部署、自动化补数等等一系列的解决方案。
因为分布式随着实施的运维节点的增加，运维能力的挑战也在升级，那么多的节点，安装、监控、报警、故障、人工处理等非常麻烦。所以，工行构建了一个统一运维管理平台。
第一，提供一个自动化的安装部署，实现批量安装部署，缩短业务上线时间。
第二，监控告警，建立基线告警及应急流程。
第三，故障分析，完善日志记录、采集和分析，建立故障分析规范。
第四，自动巡检，自动化的巡检和评分报告，对实例状态进行健康评分。
通过这样的统一运维管理平台，工行把所有的节点都纳入进来，实现一键式的安装、版本的升级、参数的配置。并且实现了多种高可用策略配置，包括自动、人工一键式切换。
以上就是工行在架构转型过程的三个阶段，由于在实施过程中，走的比较快，后续很多方面都需要优化，比如高可用方案、异地灾备和存储优化等，那么工行是如何改进的呢？
首先对高可用方案进行了持续改进，同时学习和借鉴互联网包括分布式数据库的一些方案，工行把一主两备，也就是上海和北京各有一个灾备，扩展成 1 主 3 备，通过半同步的机制，做到真正系统级保证 RPO=0。
其次，在异地灾备和存储方面，数据灾备最初的方案是采用磁盘复制实现灾备，非常耗钱，另外冷备无法热切换也是急需改进的问题，RTO 至少半个小时以上。在这方面工行使用 MySQL 异步复制完成了改进。
此外，存储方面沿用的集中存储，同时支撑上百个 MySQL 实例，IO 的性能非常容易成为瓶颈。针对这个问题，工行直接引入了 SSD 盘，还间接带来另一个好处，交易的响应时间在相同条件下降低了 50%。
除了上述问题，提升资源的使用效率也迫在眉睫。工行在两年内完成转型，大规模的上 MySQL 数据库，节点非常多，机房容量迟早会不足。此时他们选择了 MySQL 的容器。主要有几点考量：
第一，行业化里的商业软件都是用的 VMware，
第二，VMware 在 IO 方面，在系统性能方面都有比较大的损耗。
第三，工行在 IaaS、PaaS 方面建设多年，有一定的技术积累，结合工行对于云战略的规划，所以他们的 MySQL 选择了上容器。
同时也解决了两个技术要点，一是容器对数据的持久化支持，二是对服务的暴露。
通过上容器，他们提供了一键式的环境供给能力，将 IaaS、PaaS 全部打通，资源的使用效率提升提升了 4-5 倍。
总体来看， 通过此次架构转型，工行业务支撑方面，做到了高并发、可扩展、支持海量数据存储及访问。以及两地三中心高可用容灾。同时，很大程度上降低了使用成本，提升了运维能力。此外，还初步建立了企业级的基于 MySQL 的分布式解决的自主能力。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论