[field:fulltitle/]

意境资讯网 > 科技 > 正文

工商银行MySQL数据库架构解密_宝应车祸
2019-05-14 12:49  www.yijingnet.com    我要评论

摘要:本文根据DTCC数据库大会分享内容整理而成,将介绍工商银行 IT 架构转型中传统 OLTP 数据库架构面临的挑战和诉求,构建基于 MySQL 分布式企业级解决方案实践历程,包括技术选择、高可用设计、两地三中心容灾、运维管理、资源使用效率等方面的思考和实践经验,同时也介绍了工行转型的成效以及对后续工作的一些思考。

关键词:拥抱开源;MySQL; 高可用; 分布式;数据拆分; DBLE; 管理平台;灾备;容器;

演讲者介绍:林承军,中国工商银行软件开发中心高级经理,多年来一直从事开放平台相关技术研究及实施工作,多次参与工行重点项目的原型技术研究、IT 架构转型及优化提升,在分布式、高可用架构、数据高效访问领域有丰富的实施经验。近年来,牵头 MySQL/分布式数据库团队工作,借鉴和引入业界成功经验,通过自主研发 技术引入,迅速形成基于开源 MySQL 的企业级应用研发能力,初步建立了企业级解决方案,推动工行开放平台 OLTP 数据库转型的实施。

一、数据库转型背景

1.1 传统IT架构的挑战

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

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

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

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

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

在这种情况下进行IT架构转型,整体的诉求是优化应用架构、数据架构、技术架构,建立灵活开放、高效协同、安全稳定的IT架构体系,强化对业务快速创新发展的科技支撑。

工商银行MySQL数据库架构解密_宝应车祸

1.2 转型的核心诉求和策略

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

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

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

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

一:集中式向分布式的转型;

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

三:限制商业产品,拥抱开源;

这是我们当时采取的策略。结合近期的国家提出安全可靠的工作要求,对国内的生态和服务商也是比较好的挑战和机会。

工商银行MySQL数据库架构解密_宝应车祸

二、 转型的发展经历

2.1 转型路线图

2.1.1 三年转型之路

整个转型历程,大概从2015年开始IT架构转型,但真正有进展应该是从2016年初到2017年这个时间。我们整个的发展历程大概可以分三个阶段:

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

l 2016年初到2017年的过程,当时结合人民银行对于个人账户的管理要求,实行一类二类三类账户;结合这样的工作要求,把个人账户从主机下移到开放平台,基于开放平台的高性价比、可扩展进行了很多的探索,进行了很多的技术验证。当验证了技术可行性之后,我们提出了一个开放平台数据库转型的规划,这个规划对于我们行内后面几年的工作,对于数据库的方案选型是非常大的影响。这个规划确定我们行里要建设基于开源的MySQL OLTP数据库解决方案。

第二阶段 基础研究和试点

l 2017年整年,我们基于开源的MySQL数据库进行产品的研究和能力的建设,以及初步能力的建设,包括基础研究和应用的试点。在此期间,前面提到的原型也是在2017年5月份上线的,在生产线上跑起来了,把整个技术体系都进行了验证。

第三阶段 转型实施及推广

l 2018年开始大规模的实施和推广,在这个过程中基于开源的MySQL数据库,我们逐步建立起了一个企业级的数据库服务能力,包括引入了分布式的中间件,在高可用、运维能力的提升,资源使用率的提升,MySQL的云化及自主服务的建设等等。在整个过程中,同步对OLTP的分布式数据库进行了研究,也对后面的工作指导提供了依据;

工商银行MySQL数据库架构解密_宝应车祸

2.2 选型阶段

2.2.1 方案选型调研

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

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

基于开源的分布式OLTP方案,

今曰头条

,业界有很多丰富的案例,而且在互联网企业里面得到了很好的实践,在业界资源案例都很丰富。是同时能应对我行的高并发、弹性扩展需求的;

所以我们最终确定从分布式架构的角度去解决整个架构的挑战,不仅仅只从单一的数据库的层面解决这个问题。

工商银行MySQL数据库架构解密_宝应车祸

2.2.2 分布式技术栈

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

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

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

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

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

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

同时我们也进行了运维的规划和总设计。这里引入了开源的MySQL数据库来解决数据最终落地的问题

工商银行MySQL数据库架构解密_宝应车祸

2.2.3 MySQL高可用方案

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

关键词: 数据库(20)架构(19)解密(28)工商银行(9)MySQL(1)

责任编辑:意境资讯网