工商银行转型MySQL数据库的实践
极客时间编辑部
讲述：杜力大小：1.96M时长：04:17
近日，中国工商银行软件开发中心高级经理林承军在 DTCC 数据库大会上介绍了工商银行 IT 架构转型中传统 OLTP 数据库架构面临的挑战和诉求，以及构建基于 MySQL 分布式企业级解决方案的实践历程，以下为关键内容。
随着互联网金融业务快速扩张的需求，传统架构在处理能力、运行风险、交付速度与成本控制等方面的问题愈加显著，不得不面临 IT 架构转型。2015 年，工行在梳理转型诉求后，随即以数据为核心，开展了对开放平台的数据库的架构转型。
整个转型历程，可以分为三个阶段。
第一，2016 年 -2017 年为原型的研发和探索阶段。
第二，2017 年整年为基础研究和试点阶段。
第三，2017 年后，转型实施及推广阶段。
在原型探索阶段，工行在多次探索和技术可行性验证之后，确定了建设基于开源的 MySQL OLTP 数据库解决方案，并最终确定从分布式架构的角度去解决整个架构的挑战，而不是只从单一的数据库的层面解决问题。基于此，他们在 2017 年整年进行产品的研究和能力的建设，以及初步能力的建设，包括基础研究和应用的试点，初步构建起整个技术体系并进行了验证。
2018 年，工行逐步建立企业级的数据库服务能力，包括引入分布式的中间件，提升了高可用、运维能力、资源使用率等，同时进行 MySQL 的云化及自主服务的建设。在整个过程中，同步对 OLTP 的分布式数据库进行了研究。
在整个架构转型过程中，工行构建了一系列的分布式架构技术栈，主要包括以下几点：
分布式服务改造，通过服务化的改造，降低传统架构耦合度，同时，尽最大可能的避免分布式事务的产生；
分布式事务的框架，结合两阶段提交和分布式的消息，支持强一致性和最终一致性多种模式的支持，通过分布式事务框架解决分布式事务的问题；
分布式批量框架，在大规模的数据结点上进行批量操作的一个整体解决方案；
业务层面，在交易或者应用级层面进行数据核对及补偿，有些场景就是在传统的 OLTP 的情况下，也会对应用上下游进行核对和补偿；
分布式消息平台，实现这样一个应用级的数据交互；
同时他们也进行了运维的规划和总设计，另外还引入了开源的 MySQL 数据库来解决数据最终落地的问题。
那么为什么确定了 MySQL 的高可用方案呢，因为在 2016 年，主流还是 MySQL 5.6，当时 MySQL 5.7 刚出来，工行的高可用要求是应用要做到同城切换，上海两个园区要做到 RPO 是 0。
因此他们的 AB 类重点应用必须具备同城两个园区同时对外服务的能力。在原型设计阶段，基于 MySQL 的半同步复制，来实现 RPO=0，解决主库故障自动切换到备库，同城为了保障 RPO=0，在原型阶段进行了应用的双写，来进行数据的核对和补充。
这里顺便提一下，MySQL 5.7 相对 5.6 的改进非常大的，这是一款真正可以适合金融行业的数据库产品，它在数据回放方面，在性能方面都有比较大的改进和提升。
至此，工商银行的架构转型之路已经走过了三分之二，从提出转型规划到确定数据库的方案选型，并完成了开源 MySQL 基础研究和应用试点，2017 年，部分应用上线并进行验证。在转型的前两个阶段，一切看起来都比较顺畅。但由于转型过快，后续出现的问题也是接二连三。
关于工行架构转型的第三个阶段，也就是实施推广阶段，以及后续的优化和完善，我们将在下一篇文章进行阐述。
以上就是今天的内容，希望能给你带来参考价值。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论