本文作者将与大家分享工行基于MySQL搭建分布式架构的改造！将重点关注以下几个方面：传统OLTP数据库架构在工行IT架构转型中面临的挑战和需求。基于MySQL构建分布式企业级解决方案的实践历程，包括在技术选型、高可用设计、两地三中心容灾、运维管理、资源利用效率等方面的思考和实践经验。工行转型成效及对后续工作的几点思考。数据库改造背景传统IT架构挑战大型国有银行，整体核心系统为大型机+DB2等传统架构；为应对互联网金融业务的快速扩张，传统架构面临着比较大的挑战。主要集中在以下四个方面：处理能力：由于工行体量大，整个系统的规模也比较大。这种垂直单机扩展模式没有水平处理能力，处理能力有限。经营风险：随着很多业务从网点转向线上，新业务对业务连续性保障要求更高，包括7×24小时。传统架构在架构设计上无法提供这样的支持。快速交付：传统开发模式采用内部模块，应用之间的耦合度很高，使得软件开发和产品交付周期相对较长。成本控制：大型机的运营成本非常昂贵。为您购买一台机器可能需要花费数千万或数亿。此外，商业产品的牌照相对较高，银行的议价能力相对较低。在这种情况下，IT架构转型的总体要求是优化应用架构、数据架构和技术架构，建立灵活开放、高效协同、安全稳定的IT架构体系，强化业务快速发展的技术支撑。创新发展。转型的核心诉求和策略在上述转型背景下，数据是核心，我们启动了开放平台数据库架构的转型，并提出了几个核心策略：一是在业务支撑方面，实现高并发，可扩展，支持海量数据存储和访问，两地三中心高可用容灾。在大型国有银行中，工行在实现两地三中心容灾体系方面应该是比较领先的。其次，降低使用成本，基于通用廉价的硬件基础设施，希望提升自己的管控能力，进行线内适配和定制。减少对商业产品的依赖，增加议价能力。还有运维能力，提高数据库运维的自动化和智能化，更开放的技术体系，便于自主管控。主要采取三种策略：集中向分布式的转变。从专有到通用的转变，就是去IOE。限制商业产品并拥抱开源。转型发展经历了三年的转型历程。IT架构的转型大概是从2015年开始的，但是真正有进展的应该是2016年初到2017年。我们整个的发展过程大致可以分为三个阶段：Stage1:Prototyperesearchanddevelopmentandexploration从2016年初至2017年，当时结合人民银行对个人账户的管理要求，实行一类、二类、三类账户。结合这样的工作需求，将个人账户从大型机迁移到开放平台。基于开放平台的高性价比和可扩展性，进行了大量的探索和技术验证。在验证了技术可行性后，我们提出了开放平台数据库的改造方案。这个规划对我们未来几年在业界的工作，对数据库方案的选择都会产生很大的影响。这个计划决定了我们行业将构建一个开源的MySQLOLTP数据库解决方案。第二阶段：基础研究与试点2017年全年，我们开展了基于开源MySQL数据库的产品研究与能力建设，以及初期能力建设，包括基础研究与应用试点。在此期间，上述样机也于2017年5月下线，上线运行，验证了整个技术体系。第三阶段：转型实施推广2018年开始大规模实施推广，在这个过程中，我们基于开源的MySQL数据库，逐步建立了企业级的数据库服务能力，包括分布式中间件的引入。高可用、运维能力提升、资源利用率提升、MySQL云化和自治服务构建等，整个过程同步学习了OLTP分布式数据库，也为后续工作指导提供了依据。选型阶段①方案选型研究在选型阶段，我们根据业务场景进行了大量的方案研究。坦白说，2014年到2016年，工行软件开发中心一直在关注行业内数据库和生态的发展，在这个过程中，我们对很多产品进行了一定的研究和深入的测试。NewSQL数据库方案很多互联网公司或者一些小企业都在使用，但是我们银行在选择技术的时候非常谨慎，做了大量的验证，不符合我们当时系统设计的考虑。基于开源的分布式OLTP解决方案，业界有很多丰富的案例，在互联网公司也有很好的实践。业内资源案例众多，可同时满足我行高并发和弹性扩展需求。所以我们最终决定从分布式架构的角度来解决整个架构的挑战，而不仅仅是从单一数据库的层面。②分布式技术栈基于这样的原型探索，我们构建了一系列的分布式架构技术栈，包括分布式服务、分布式事务框架、分布式批处理框架、分布式缓存、交易数据验证与补偿、分布式信息、配置中心、开发与运维管理。这里简单介绍一下：分布式服务改造，针对我们传统架构的紧耦合，通过面向服务的改造来降低耦合度。在降低耦合度的同时，也可以尽可能避免分布式事务的产生。对于分布式事务的框架，我们结合了两阶段提交和分布式消息，支持强一致性和最终一致性的多种模式，通过分布式事务框架来解决分布式事务的问题。分布式批处理框架，大规模数据节点批量操作的整体解决方案。在业务层面，在交易或应用层面进行数据校验和补偿。在某些场景下，以传统的OLTP为例，也会对上下游应用进行校验和补偿。分布式消息平台实现了这样一个应用层的数据交互。同时，我们也进行了运维的规划和总体设计。这里引入开源的MySQL数据库，解决数据落地问题。③MySQL高可用方案处于原型阶段。当时，MySQL5.6和5.7是主流。对于高可用的需求，行业内的应用必须在同城内切换。上海两个园区的RPO一定是0，RTO很小。北京有个灾备中心，就是两地三中心。我们的AB类密钥应用程序必须具有在同一个城市的两个公园同时为外界服务的能力。在原型设计阶段，我们基于MySQL的半同步复制做了这样一个切换，实现RPO=0，自动切换到备库，解决主库故障。写信检查补充资料。顺便说一下，MySQL5.7相比5.6有了很大的改进。这是一款真正适合金融行业的数据库产品。它在数据播放和性能方面都有比较大的改进和改进。实施推广阶段①基础研究与应用试点第二阶段是开源MySQL基础研究与应用试点，时间是2017年。研究完这些要素后，需要在业界发布一个产品；把这个产品推上线需要做很多工作：产品的基础研究，我需要验证功能，新特性和配置基线，数据备份和恢复，并结合它们的特性来设计应用程序的高可用性并提供开发技术规范。我们的角色不仅要兼顾运维，还要兼顾上游应用，做好上面的连接、对接和支撑。包括应用的开发规范，性能能力评估，需要多少台设备上线，需要多少容量，对Oracle等老架构的指导帮助，代码写得不好的检查工具，等运维方面，需要提供各种安装部署便利，然后对接行业内的监控系统，制定很多指标和参数，如何对接行业，分析新问题等等一系列的问题。现阶段我们实现了同城RPO=0，RTO=分钟级目标，RPO为0切换，问题可监控，实现了手动或自动一键切换。现阶段经过行业决策，我们在2017年上线了21个应用，211个节点。②2018年分布式中间件应用开始转型落地，大量应用上线；以前的应用程序级分布式解决方案遇到了一些新的限制。有些应用程序不希望在设计上过于复杂。这时候就引入了开源的分布式中间件DBLE。引入它的目的是为了简化开发的工作量。通过引入这样的DBLE来支持数据垂直分片、水平数据分片、混合分片等场景，同时支持简单的跨库集合查询，提供类似于中心化库的操作体验。这时候开发场景就被简化了，给应用提供了更多的选择，简化了应用开发的复杂度。③运维架构流程完美解决了应用开发的复杂性。运维呢？自动补码等一系列解决方案。④运维管理能力沉淀此时提升运维能力迫在眉睫；因为分布式运维节点随着实施增加，运维是一个很大的挑战，所以节点多，安装、监控、告警、故障、人工处理等都很麻烦。我们的做法：首先提供一个自动化安装部署，实现批量安装部署。批量串行是不够的。许多场景需要打磨。监控告警包括事件级别，分为不同级别。这些需要灵活定制，建立基线警报，并建立应急程序。故障分析，完善日志记录、收集和分析，建立故障分析规范。自动巡检，自动巡检打分报告，实例状态健康打分。⑤建立统一运维平台。通过这样一个统一的运维管理平台，囊括所有节点，实现一键安装、版本升级、参数配置。并实现了多种高可用策略配置，包括自动和手动一键切换。说到为什么有两种方式可以在自动化和手动之间切换？一项新的交易在上线之前，都会面临一些挑战和质疑。这是一个循序渐进的过程，尤其是在金融行业。我们已经实现了多种可用策略的高层灵活配置。⑥自动故障转移上线我们建立了自动化、高可用的决策系统。大家都知道，人工决策到自动切换只是向前迈进了一步，但面临着很大的挑战：包括决策因素和决策模型，最难的是应对不同应用场景的需求，有时据说RPO优先，有的RTO优先。有的要求三分钟完成，有的说10秒、5秒我就难受了。你得有这样的模型去适应这样的场景，这是一个非常大的挑战。整体基于MySQL的复制技术，我们有半同步复制和多数共识机制来实现冗余备份。基于MySQLbinlog日志自动补全数据，保证数据一致性。实践中的改进和优化①我们在同步实施高可用解决方案改进的过程中速度更快，每年有数百个节点和数十个应用程序。在这个过程中，我们不断优化高可用的方案，同时借鉴了网上的一些方案，包括分布式数据库。我们将1主2备，1本地1备，同城1备扩展为1主3备。通过半同步机制，我们可以真正保证系统层面的RPO=0。②异地容灾和存储优化在异地容灾和存储方面，一开始跑的太快，有些方面没有考虑的那么完善。正如我刚才所说，我们有一个从上海到北京的灾难恢复。数据容灾刚刚起步，计划采用磁盘复制来实现容灾。这也需要软件成本并且相对昂贵。还有冷备，不能热切换，RTO至少半小时。我们在这方面进行了改进，使用了MySQL异步复制。另外存储上使用的集中式存储，一套集中式存储同时支持六七百个MySQL实例，IO的性能很容易成为瓶颈。在处理一些高并发场景时，由于IO性能不足，我们在这方面进行了改进，直接引入了SSD盘，基本解决了MySQL和IO的瓶颈。目前场景下，IO一般不会成为瓶颈。同时，通过SSD的引入，在同等条件下，交易响应时间降低了50%。③MySQL容器化探索MySQL的容器化，我先说说我们为什么要做这个东西？因为工行一两年转型，大型MySQL数据库节点很多，机房和设备都成了瓶颈。如果我们在机房继续这样玩下去，容量就不够了。这时候就需要提高资源的使用效率。在很多应用中，由于其超前的规划，一般都是为了稳定运行，在资源申请的时候基本都是物理机。为了满足未来几年的业务需求，需要对物理机进行大规模的应用，但是目前应用的交易量还没有那么大，浪费比较严重。这时候，提高资源的利用率就成了我们迫在眉睫的问题。为什么在这个过程中选择MySQL容器？几点考虑：业界所有商业软件都使用VMware。VMware在IO和系统性能上有比较大的损失。该行业多年来一直在构建IaaS和PaaS。事实上，我们所有的无状态应用服务都已经在PaaS和容器上实现了。在这方面，我们积累了一些技术，并结合业界的云战略规划，所以我们选择了MySQL放在容器上。容器解决了以上两个技术点：容器对数据持久化的支持。接触服务。整体来说，我们的MySQL容器现阶段只是作为一种虚拟化技术来使用。它整个的高可用，包括它整个的监控，整个的安装部署都是通过我们前面提到的管理平台来实现的。通过容器，我们提供一键式的环境供应能力。通过容器，Iaas和PaaS都打通了，可以按照业界的标准和模型快速提供基础环境。资源的使用效率提高了4到5倍。截至目前，我们行业MySQL上的容器节点应该有400多个。改造成果①改造实施成果我们至少实施了120多个应用，2000多个服务器节点，2500多个MySQL节点。实现的应用涉及很多核心业务，包括个人账户、公众账户、基金，以及很多A类和B类应用，大部分都是从宿主迁移过来的。其中，有少量应用是从Oracle迁移过来的，需要重构应用层。我们MySQL支持的核心交易已经达到了日均7亿的交易量，我们在双十一、2018年的双十一和春节的高峰期经历了15000的TPS。我们的架构现在通过水平扩展可以达到数万TPS。我们基于30,000TPS的设计目标来设计架构，理论上可以通过扩展设备来提高。如果想通过主机来实现这个目标，那么挑战会比较大。另外，通过良好的架构设计，我们可以满足两地三中心的架构需求，实现同城RPO=0和RTO<60s。现在很多“多活”，包括互联网公司的架构，最多只能做到sharding双活的维度，双方同时对外提供服务，但是同时，写某个分片数据只能是单活的。通过架构改造，我们在自主性方面初步建立了基于MySQL的企业级分布式解决方案自主能力：第一，分布式框架+MySQL应用级分布式解决方案，承载了我们很多从属主机下的应用。二是基于分布式中间件形成所谓的在线交易数据库，可以应对一些不是很复杂的场景，设计良好的分库分表方案就可以满足需要。在成本方面，我们在主机上的成本投入明显下降。过去几年，我们的业务交易量每年以20%的速度增长，但主机并没有扩容，投资逐年减少。商业产品对数据库的使用不仅实现了零增长，而且还出现了下降。从整体资金来看，应该会有比较大的降幅。②典型案例一：个人账户平台先介绍个人账户平台作为我们架构设计的原型，它是一个从主机迁移过来的应用。当时交易要求高并发、低延迟，日均交易量3亿笔。本应用内部事务延迟不能超过100ms，需要7×24小时在线服务。我们实现的架构是同城双活分片的高可用架构。实现效果是日均交易量1亿以上，本地高可用实现自动切换，RPO=0，RTO<30S。同城高可用切换也是60秒内切换。同时结合MySQL管理平台，封装自动切换能力，同城切换将面临比较大的挑战：本地高可用切换基于SIP，对应用透明。同城交换对应用程序是不透明的。所以我们设计了从服务器到数据库的整体切换流程。数据库需要与应用服务器联动，实现同城内自动切换。③典型案例2：信息辅助服务的另一个案例是通过DBLE实现分布式数据库。这是一个数据量比较大的系统。它需要高并发和低延迟。日均交易量2亿。交易响应延迟要求在10ms以内。当时的业务数据量在20T左右，还需要7×24小时在线服务。我们的架构是用分布式中间件做MySQL分库分表，一共128个分片。我们整合了shards的部署，看似过度sharding，但是资源使用受益良多。DBLE中间件白天做在线服务，晚上做批量变更，同步主机上的一些数据。该架构整体实现本地与同城全自动切换，RPO=0，RTO<30S。后工作的思路结合我们OLTP的数据改造，我行接下来的几个方向要做的工作还是很多的。基于云的服务现在是SaaS云或任何其他云。工商银行对一些新技术进行跟踪。当它普及并得到很好的实施时，它将使我们不会比互联网慢。更多的打磨，我们认为它成熟了，可以供以后参考。在云服务方面，要结合MySQL等数据库，加强云服务的建设。通过我们刚才的一些平台，或者一些独立服务的建设，未来可以加强云服务能力的建设。统一数据交换刚才我们提到了消息平台，它实现了应用之间的数据交换，这是业务层面的。那么除了这样一个业务级的，我们还需要一个系统级的，实现不同数据库和数据库系统级别的准实时数据交换和复制。数据只有被传递、被激活，才能更好地发挥数据的商业价值。我行目前正在为这方面搭建数据复制平台。甲骨文改造工行，应该把甲骨文的一些特性用的很透彻；基本上都是存储过程。一旦确定了开发框架，大家的存储过程用笔勾选或拉动几下就可以生成很多流程。但同时绑定到特定的数据库，后续的维护和扩展面临比较大的挑战。比如如何以一个比较可以接受的、比较低的成本去改造Oracle，因为重构和开发整个数据库和整个应用的成本还是非常非常高的，这是我们后面需要去探索和思考的。对于分布式数据库，从2015年开始，我们一直在跟踪业界的很多分布式数据库产品，不管我们应用层的分布式方案，包括我们的分布式访问层方案，都可能有一些场景是真的无法应对的。我们也在探索。随着生态系统和国内技术的逐渐成熟，我们也在考虑对分布式数据库技术的探索和引入。同时，从另一个角度来看，在当前的国际关系形势下，我们需要做一些技术储备，有能力独立支撑。作者：林成军简介：中国工商银行软件开发中心高级经理，多年开放平台相关技术研究和实施经验，曾参与原型技术研究、IT架构改造和优化多次成为工商银行重点项目，数据高效接入领域具有丰富的实施经验。近年来，领导MySQL/分布式数据库团队工作，学习和引进业界成功经验，通过自主研发和引进，快速形成了基于开源MySQL的企业级应用研发能力。开发技术，初步建立企业级解决方案，推动工商银行开放平台OLTP数据库改造的实施。
