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

  • 时间:
  • 浏览:7
  • 来源:资源屋 - 专注共享我爱生活网技术

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

作者:林承军

编辑:爱可生

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

一、数据库转型背景

  1.1 传统IT架构的挑战

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

  避免能力:可能性工行这样大的体量,是因为整体系统的规模比较庞大,这人 垂直的单一的扩展模式,不具备横向避免能力,避免能力受到限制;

  运行的风险:随着只是 有的业务从网点变成线上,新的业务提出了更高的业务连续性保障,包括7×24小时,传统的架构从下发上无法做到原先的支持;

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

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

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

  1.2 转型的核心诉求和策略

  在上边的转型大背景下,数据作为核心,大伙展开了对开放平台的数据库的架构转型,同时提出了哪好多个核心的策略:

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

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

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

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

  b:是专有向通用的转型,也只是 去IOE;

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

二、 转型的发展经历

  2.1 转型路线图

  2.1.1 三年转型之路

  整个转型历程,最少从2015年开使英语 IT架构转型,但真正有进展应该是从2016年初到2017年这人 时间。大伙整个的发展历程最少都还可否 分一3个 阶段:

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

  2016年初到2017年的过程,当时结合人民银行对于或多或少人账户的管理要求,实行一类二类三类账户;结合原先的工作要求,把或多或少人账户从主机下移到开放平台,基于开放平台的高性价比、可扩展进行了只是 有的探索,进行了只是 有的技术验证。当验证了技术可行性已经 ,大伙提出了一3个 开放平台数据库转型的规划,这人 规划对于大伙行内上边几年的工作,对于数据库的方案选型是非常大的影响。这人 规划选用大伙行里要建设基于开源的MySQL OLTP数据库避免方案。

  第二阶段 基础研究和试点

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

  第三阶段 转型实施及推广

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

  2.2 选型阶段

  2.2.1 方案选型调研

  在选型阶段,大伙基于业务场景进行了几瓶的方案调研。坦率的说,工行软件开发中心在2014—2016年持续关注着行业内数据库的发展和心态的发展,在这人 过程中大伙对只是 有的产品进行了或多或少研究和摸底的测试。

  NewSQL数据库方案,是只是 有的互联网企业可能性或多或少小型企业有所使用的,有已经 我行在选用技术的已经 是非常谨慎的,以及要做非常多验证,在当时无须符合大伙系统设计的考量点;

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

  只是 有大伙最终选用从分布式架构的角度去避免整个架构的挑战,不仅仅只从单一的数据库的层面避免这人 问题报告 。

  2.2.2 分布式技术栈

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

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

  分布式事务的框架,大伙结合两阶段提交和分布式的消息,支持强一致性和最终一致性多种模式的支持,通过分布式事务框架避免分布式事务的问题报告 ;

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

  业务层面,在交易可能性应用级层面进行数据核对及补偿,或多或少场景只是 在传统的OLTP的清况 下,也会对应用上下游进行核对和补偿;

  分布式消息平台,实现原先一3个 应用级的数据交互;

  同时大伙也进行了运维的规划和总设计。这里引入了开源的MySQL数据库来避免数据最终落地的问题报告

  2.2.3 MySQL高可用方案

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

  大伙的AB类重点应用这样具备原先的同城一3个 园区同时对外服务的能力。在原型设计阶段,大伙基于MySQL的半同步qq克隆好友 ,来做原先的一3个 切换,实现RPO=0,避免主库故障自动切换到备库,同城为了保障RPO=0,在原型阶段进行了应用的双写。来进行数据的核对和补充;

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

  2.3 实施推广阶段

  2.3.1 基础研究和应用试点

  第3个阶段是开源MySQL基础研究和应用试点,只是 2017年。对于这人 元素研究已经 ,在行里要发布第一3个 产品;把这人 产品推上线,要做只是 有的工作:

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

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

  这人 阶段,行里决策了已经 ,大伙一下子上了2一3个 应用,21一3个 节点,这是2017年。

  2.3.2 分布式上边件应用

  2018年开使英语 转型和实施,有已经 几瓶应用上线;已经 的基于应用级的分布式避免方案,遇到了或多或少新的限制;要素应用你会设计的过分复杂,这人 已经 引入了开源分布式上边件DBLE,引入它的目的只是 为了复杂开发的工作量,通过引入原先一3个 DBLE来支持垂直数据分片、水平数据分片、混合分片等场景的支持,还支持简单的跨库汇集查询提供相似集中库的操作体验,这人 已经 开发场景就复杂了,给了应用更多的选用,复杂了应用开发的复杂度。

  2.3.3 运维架构流程完善

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

  2.3.4 运维管理能力沉淀

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

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

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

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

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

  2.3.5 统一运维平台建立

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

  谈到为这人 要有自动化和人工的本身切换法子?本身新的事务上线已经 ,与否面临或多或少挑战和怀疑的,与否一3个 循序渐进的过程,很重是是在金融行业,大伙实现了多种高可用策略的灵活配置。

  2.3.6 故障自动切换上线

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

  2.4 实践中的改善优化

  2.4.1 高可用方案改进

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

  2.4.2 异地灾备和存储优化

  异地灾备和存储方面,当初跑的比较慢,方方面面或多或少这样考虑这样完备。

  大伙刚才说了,大伙在上海到北京有一3个 灾备。数据灾备开使英语 英语 方案,采用磁盘qq克隆好友 实现灾备,这人 也是要支出软件费用,也比较耗钱。第3个是冷备,无法热切换,RTO最少半个小时以上。这人 方面大伙改进了,用了MySQL异步qq克隆好友 ;

  另外存储方面沿用的集中存储,一套集中存储上边同时支撑六七十上百个MySQL实例,IO的性能非常容易成为瓶颈。在应对或多或少高并发场景的已经 ,可能性IO性能欠缺,这方面大伙就改进了,直接引入了SSD盘,基本上把MySQL、IO的瓶颈给避免了。在现在的场景下,IO一般不不成为瓶颈了。同时通过SSD的引入,交易的响应时间在相同条件下降低100%。

  2.4.3 MySQL 容器化探索

  MySQL的上容器,首先说一下为这人 要搞这人 事情?可能性工行一两年转型过来,大规模的上MySQL数据库,节点非常多,机房和设备成为一3个 瓶颈,再这样玩儿下去机房容量欠缺了。这人 已经 这样提升资源的使用波特率。

  在只是 有应用里,可能性它的超前规划,一般为了稳定运行,基本上都提出资源申请的已经 ,与否物理机,为了满足上边几年的业务需求,大规模的申请物理机,但当前应用的交易量又与否这样大,浪费比较严重的。这人 已经 大伙提升资源的使用成为紧迫的问题报告 。这人 过程中为这人 选用MySQL的容器呢?几点考量:

  第一、行业化里的商业软件与否用的VMware,

  第二、VMware在IO方面,在系统性能方面与否比较大的损耗。

  第三、行里在IAAS、PAAS方面建设好多年了,大伙无清况 的应用服务实在完正上了PAAS,完正上了容器,在这方面有或多或少技术的积累,结合行内对于云战略的规划,只是 有大伙MySQL选用了上容器。上容器避免的一3个 技术要点:

  第一3个 只是 容器对数据的持久化支持;

  第3个是对服务的暴露;

  整体大伙MySQL上容器,在现阶段仅仅是把它作为一3个 虚拟化的技术,它的整个高可用,包括它的整个监控、整个的安装部署与否通过大伙已经 提到的管理平台来实施的。通过上容器,大伙提供了一键式的环境供给能力,通过上容器把IAAS、PAAS完正打通过了,能放慢的把基础环境,按照行内的标准和模式放慢的供应出来。资源的使用波特率提升提升了4到5倍。截止当前大伙行内在MySQL上容器这块,应该是有100多个节点。

三、转型成效

  3.1 转型实施成果

  大伙实施了最少120多个应用,100多个服务器节点,超过2100个MySQL节点。实施的应用涉及只是 有核心业务,包括或多或少人账户、对公账户、基金以及只是 有A类、B类的应用,大多与否主机上迁移过来的。其中还有几瓶应用是从Oracle迁移过来的,应用层也有已经 这样重构。

  大伙通过MySQL支持的核心交易达到日均7亿的交易量,经历过双十一、2018年的双十一和春节的高峰期的1.10万的TPS。大伙的架构现在通过横向扩展都还可否 达到几万的TPS。大伙只是 基于3万TPS的设计目标进行了下发,理论上通过扩展设备还都还可否 无限地增加。可能性通过主机想达成这人 目标,这样挑战就会比较大。

  另外通过良好的下发,大伙都还可否 满足两地三中心的架构要求,做到同城RPO=0,RTO<100s。刚才人们问到同城双活多活,现在只是 有的”多活”,包括互联网公司的架构,与否最多要能做到分片双活的维度,两边同时提供对外服务,有已经 同时对于某一分片数据的写入这样是单活的。

  通过架构转型,大伙在自主能力方面,初步建立了企业级的基于MySQL的分布式避免的自主能力:首先是分布式框架+MySQL的应用级分布式避免方案,这人 方案承载了大伙只是 有的从主机下来的应用。其次是基于分布式上边件构成了所谓联机交易的数据库,原先能应对或多或少与否很复杂的场景,通过良好设计的分库分表方案就都还可否 满足需求。

  在成本方面,大伙在主机上的成本投入明显下降。这几年大伙的业务交易量每年以20%的波特率增长,有已经 主机并这样进行扩容,投入还逐年降低。商业产品的数据库的使用不仅实现零增长,还有所下降。从整个经费上来说,应该有比较大的降幅。

  3.2 典型案例1:或多或少人账户平台

  介绍一下作为大伙下发原型的或多或少人账户平台,这是从主机上迁移下来的应用。当时的交易要求高并发、低延时,日均交易量3亿,这人 应用的内部交易延时这样超过100ms,要求7×24小时的联机服务。

  大伙实施的架构是高可用架构同城分片双活。实施效果是日均交易量超1亿以上,本地高可用做到自动化切换,RPO=0,RTO<100S。同城高可用切换也是100秒内切换。

  同时结合MySQL的管理平台,对自动化的切换能力进行了包装,同城的切换会面临着比较大的挑战:本地的高可用切换是基于SIP的,它是对应用透明的;而同城切换是对应用不透明的。于是大伙设计了从服务器到数据库的整体切换流程,数据库要和应用服务器进行或多或少联动来实现同城自动化切换。

  3.3 典型案例2:信息辅助服务

  另外一3个 案例只是 通过DBLE实现分布式数据库。这是第一3个 数据量比较大的系统,它要求高并发、低延时,日均交易量2亿,交易响应延这样求10ms以内,当时的业务数据量最少20T左右,这样求7×24小时的联机服务。大伙的架构是通过分布式上边件做MySQL的分库分表,一共128个分片。大伙对分片进行了合并部署,这看上去像是过度分片,有已经 资源使用上就收益很大。DBLE上边件在日间进行联机服务,夜间进行批量变更,把主机上的或多或少数据同步下来。这人 架构整体上实现了本地和同城完正自动化切换,RPO=0,RTO<100S。

四、后期工作思路

  结合大伙行的OLTP的数据转型,后续哪好多个方向是大伙行要几瓶工作的。

  第一3个 是云化服务。现在SaaS云也好还是这人 云也好,工行对于或多或少新的技术是保持跟踪,当它有普遍性,很好的落地已经 ,都还可否 使大伙不不比互联网慢一拍,在技术经过更多的打磨,大伙认为它心智心智心智心智成熟的句子的句子是什么是什么期的句子已经 再引用。在云化服务方面,大伙这边结合像MySQL,像其它的或多或少数据库,大伙要加强云化服务的建设。通过大伙刚才的或多或少平台也好,或多或少自主服务的建设也好,加强上边云化服务能力的建设。

  第3个是数据统一交换。大伙刚才提到消息平台,它实现了应用和应用之间的数据交换,这人 是业务级的。这样大伙现在除了原先的一3个 业务级的,大伙还这样一3个 系统级的来实现不同数据库和数据库系统级的准实时的数据的交换和qq克隆好友 ,这样把数据流转,把它活动起来了,这样数据要能更好的发挥它的业务价值,大伙行目前也在建设这人 块的数据qq克隆好友 平台。

  第一3个 只是 Oracle的转型。工行应该把Oracle原先的或多或少底部形态用的非常极致;基本上与否存储过程,当开发框架一选用,大伙存储过程与否用笔勾几下可能性拉几下就都还可否 产生只是 有的流程,但它同时和具体的数据库绑定了,上边的维护、扩展都面临比较大的挑战。比如说如可用相对都还可否 接受,相对较低的代价进行Oracle的转型,可能性整个数据库、整个应用重构开发的代价还是非常非常大的,这人 也是大伙的上边这样探索和思考的事情。

  第3个只是 对分布式的数据库。在分布式数据库来说,我刚才说了,大伙从2015年以来,就老是跟踪着业界只是 有的分布式数据库的产品。大伙应用级的分布式避免方案也好,包括大伙的分布式访问层的避免方案也好,可能性或多或少场景还真的是无法应对的。大伙实在也在探索,随着生态圈和国内技术的逐步心智心智心智心智成熟的句子的句子是什么是什么期的句子,大伙也在考虑分布式数据库技术的探索和引入的事情,同时从另外一3个 角度来说,在现在这人 国际的关系形势下,这样做或多或少技术的储备,有自主支撑下来的能力。

本文由

ITPUB

发布在

ITPUB

,转载此文请保持文章完正性,并请附上文章来源(ITPUB)及本页链接。

原文链接:http://www.itpub.net/2019/05/16/1892/