中国IDC服务网

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
中国IDC服务网 首页 技术流 查看内容

工商银行MySQL数据库架构解密

2019-5-14 14:39| 发布者: 156| 查看: 6198| 评论: 0

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

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

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

一、数据库转型背景

1.1 传统IT架构的挑战

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

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

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

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

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

 

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


1.2 转型的核心诉求和策略

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

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

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

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

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

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

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

 

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



二、 转型的发展经历

2.1 转型路线图

2.1.1 三年转型之路

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

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

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

第二阶段 基础研究和试点

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

第三阶段 转型实施及推广

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


2.2 选型阶段

2.2.1 方案选型调研

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

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

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

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



2.2.2 分布式技术栈

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

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

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

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

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

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

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


2.2.3 MySQL高可用方案

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

我们的AB类重点应用必须具备这样的同城两个园区同时对外服务的能力。在原型设计阶段,我们基于MySQL的半同步复制,来做这样的一个切换,实现RPO=0,解决主库故障自动切换到备库,同城为了保障RPO=0,在原型阶段进行了应用的双写。来进行数据的核对和补充;

这里顺便提一下,MySQL5.7相对5.6的改进非常大的,这是一款真正可以适合金融行业的数据库产品,它在数据回放方面,在性能方面都有比较大的改进和提升;


2.3 实施推广阶段

2.3.1 基础研究和应用试点

第二个阶段是开源MySQL基础研究和应用试点,就是2017年。对于这些元素研究以后,在行里要发布第一个产品;把这个产品推上线,要做很多的工作:

产品的基础研究,我需要验证功能、新特性和配置基线,数据备份恢复,还要结合它的特性来设计应用的高可用,提供开发的技术规范;

我们的角色既要考虑到运维,也要考虑到上游应用,做好上面的衔接、对接和支持。包括应用的开发规范,它的性能能力评估,上线需要多少设备,容量是多大,还要对Oracle等老架构给予指引和帮助,代码写不好还要弄个检查工具等等。运维方面就是要提供各种安装部署的便利化,然后行内和行内的监控系统进行对接,制定很多的指标和参数,如何和行里进行对接,然后新问题的分析等等一系列的问题。在这个阶段我们实现了同城RPO=0,RTO=分钟级目标,RPO为0的切换,问题可监控,实现了人工或自动的一键式切换。

这个阶段,行里决策了之后,我们一下子上了21个应用,211个节点,这是2017年。


2.3.2 分布式中间件应用

2018年开始转型和实施,并且大量应用上线;之前的基于应用级的分布式解决方案,遇到了一些新的限制;部分应用不想设计的过分复杂,这个时候引入了开源分布式中间件DBLE,引入它的目的就是为了简化开发的工作量,通过引入这样一个DBLE来支持垂直数据分片、水平数据分片、混合分片等场景的支持,还支持简单的跨库汇集查询提供类似集中库的操作体验,这个时候开发场景就简化了,给了应用更多的选择,简化了应用开发的复杂度。


2.3.3 运维架构流程完善

解决了应用开发的复杂度,运维怎么办?高可用怎么办,我们结合DBLE和运维管理平台,实现整平台联动,支持从高可用、监控告警、安装部署、自动化补数等等一系列的解决方案;


2.3.4 运维管理能力沉淀

这时进行运维能力的提升,也迫在眉睫;因为分布式随着实施的运维节点的增加,运维是一个很大的挑战,那么多的节点,安装、监控、报警、故障、人工处理等非常麻烦;

我们首先提供一个自动化的安装部署,实现批量安装部署,批量串行还不行,时间太长了,要并行,并行太高了,网络的流量会受到比较大的影响,所以这个方面有很多的场景都需要打磨。

第二是监控告警,监控告警里有事件等级,分各种等级,这些需要灵活的定制,建立基线告警,建立应急流程。

第三是故障的分析,完善日志记录、采集和分析,建立故障分析规范。

第四是自动巡检,自动化的巡检和评分报告,对实例状态进行健康评分。


2.3.5 统一运维平台建立

我们通过这样一个统一的运维管理平台,把所有的节点都纳入进来了,实现一键式的安装、版本的升级、参数的配置。并且实现了多种高可用策略配置,包括自动、人工一键式切换。

谈到为什么要有自动化和人工的两种切换方式?一种新的事务上线之前,都会面临一些挑战和怀疑的,都是一个循序渐进的过程,特别是是在金融行业,我们实现了多种高可用策略的灵活配置。


2.3.6 故障自动切换上线

我们建立了一个自动化、高可用的决策系统,大家知道人工决策到自动切换,虽然只是迈出一步,但是面临着很大的挑战,包括决策的因素和决策的模型,最难的是还要应对不同应用场景的需求,有的时候说RPO优先,有的RTO优先,有的要求三分钟搞定,有的说10秒钟5秒钟我都难受,你要有这样的模型适配这样的场景,这是非常大的挑战。在整体上面基于MySQL的复制技术,我们有半同步复职和多数派共识机制实现冗余备份。基于MySQL binlog日志自动数据补全,保障数据的一致性。


2.4 实践中的改善优化

2.4.1 高可用方案改进

同时实施过程中我们走的比较快了,一年几百个节点,几十个应用。在这个过程中,我们又对高可用方案进行了持续的优化,同时学习和借鉴互联网包括分布式数据库的一些方案,我们把一主两备,本地1备和同城1备,扩展成1主3备,通过半同步的机制,做到真正的在系统级去保证RPO=0;


12下一页

鲜花

握手

雷人

路过

鸡蛋

最新评论

小黑屋|中国IDC服务网 ( 京ICP备13032931-1号 京公网安备11010802009381 QQ:1390064848,电话:4006678502,邮箱:idc@idcser.com )

GMT+8, 2019-11-19 20:29 , Processed in 0.049170 second(s), 14 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

返回顶部