北京万里开源软件有限公司（简称：万里数据库）拥有多年的优质客户基础的大型股份制银行客户，具有综合独特的创新能力和强大的市场竞争力，随着新业务的不断开展，已建设国内最大的缴费平台系统，截止到当前，缴费服务项目总数已突破8000项大关。覆盖6大基础公共便民缴费服务，面向全国省、市、县3级区域进行覆盖。在这种大背景下促使IT架构创新转型，数据分布存储，并向动态负载均衡的分布式架构转型。

万里数据库通过GreatDB助力客户方缴费平台系统的分布式建设，其分布式数据库集群采用两地三中心的部署架构，同城双活部署，异地机房采用集群配套工具进行数据库同步。同时响应客户方监管需求，部署逃离库，通过集群数据同步工具进行异构同步。

转型后目前集群数据量约5TB数据，数据库层并发活跃会话数约为600，业务峰值TPS约为3000，业务交易平均响应时间为60ms。

方案背景

据《2021年中国便民缴费产业报告》数据显示，2020年个人缴费市场规模达13.32万亿，比2019年增长了7.6%，可见我国缴费便民指数显著提升。

在这样背景下，缴费系统各个关键环节的参与者（缴费供应商、用户、缴费渠道、缴费运营商）正逐渐形成广泛、动态的合作联盟，以开放的缴费运营商为平台的开放共享的缴费生态系统正在构建。

但客户方缴费业务原数据库系统架构运行在小机上的双中心RAC 2+2冷备部署集群，基于存储复制技术确保数据一致性，同时通过Rac自身特性及第三方软件提供服务高可用性。

该架构所面临的挑战：

1.运行风险：应用与数据库分离部署，负载均衡模式+Oracle RAC模式。当数据库异常出现，进行跨中心数据灾备切换时，会在较长时间无法提供服务。

2.容量风险：业务量每年激增，高速扩展对数据库容量和负载带来巨大挑战，原架构数据库容量不足。

3.扩展性风险：数据库服务器使用小型机，在现有架构下无法进行横向扩展。

4.成本控制：升级迭代硬件成本过高。

在这种情况下，促使该客户将缴费业务核心数据库从Oracle迁移到国产分布式数据库集群。

方案目标

1.分布式架构与微服务架构相融合

微服务架构也是目前金融行业技术趋势之一，分布式架构与微服务架构相结合，可提供高效的性能和持续的扩容能力。

2.高可靠与容灾

数据库系统要有极高的可靠性与容灾能力。具备同城跨机房容灾部署能力、机房级故障切换能力，确保节点/机房故障场景下RPO=0，RTO<60s。且需同时具备强一致的数据库集群备份恢复能力，确保金融数据的备份级灾备安全。

3.高性能、低延迟、按需在线横向扩展

随着用户规模的逐步扩大，促使缴费平台性能压力持续增加，就要求分布式数据库提供高吞吐性能与低于阀值的响应延迟，并按需横向扩容，以支撑业务高速发展。

4.平滑的切换方案

分布式数据库与业务整体相融合，具备平滑切换与按需回切业务流量的方案，确保新架构方案风险整体可控。

方案特点

1.数据强一致，高可靠

1）分布式数据库集群采用多副本冗余实现数据高可靠，基于Raft算法，确保数据强一致。

2）同城双活部署，提供机房级高可靠，确保集群任意故障场景下RPO=0。

3）分布式数据库自动failover，实现秒级故障切换，切换对业务影响可控。

2.部署灵活可扩展

1）分布式数据库集群支持按需在线扩展，可增加集群并发承载能力、集群存储容量和IOPS能力。

2）分布式数据库支持在线滚动升级，确保业务连续性。

3）分布式数据库支持灵活的节点在线部署调整，在线支撑机房搬迁等大范围数据库部署调整。

3.高性能

1）分布式数据库支持缴费峰值3000到5000+TPS缴费交易，集群整体资源负载可控，交易响应时间控制在60ms左右，性能稳定。

2）分布式数据库集群支持在线扩容提升性能处理能力。

4.易迁移

1）分布式数据库集群可全面兼容开源数据库协议。

2）缴费业务基于开源数据库重构，迁移业务无额外适配工作。

方案业务流程图

一、整体架构

1.缴费平台系统架构

基于客户方线上缴费业务需求，采用两地三中心部署架构，同城双机房部署单一双活主集群，并从灾备角度部署异地灾备集群与本地逃离库集群，数据同步通过集群数据库同步工具进行。数据库运维监控管理平台接管集群全组件的全生命周期运维管理。

2.系统功能及系统分层架构

客户端：用户可通过微信、支付宝、掌上银行、小米支付等多种线上缴费渠道。

业务层：线上缴费数据涉及各类基础缴费业务，包括水、电、燃、宽带、物业费、学费等，覆盖百姓生活的方方面面。

数据库：线上缴费业务数据存储在数据库层的GreatDB中。

基础设施：GreatDB数据库支持物理机、云平台、容灾等基础设施部署，用户可根据自身情况选择不同设施。

二、业务场景及流程

1.微信支付接入缴费平台，缴费同时与服务提供商电网对接，电网对接分部前置系统，总部前置对接分部前置。

2.用户的缴费请求，微信支付发送查询请求至缴费平台，确认用户缴费金额。

3.微信支付等商户通过财富通支付扣款，可以采用信用卡支付，并将支付结果返回缴费平台。

4.缴费平台获取支付成功信息后，向服务提供商（电网）发起缴费请求。

5.电网向缴费平台返回实时缴费结果，缴费返回给微信支付。

实现功能展示

一、高可靠与灾备方案

缴费分布式数据库集群的高可靠与灾备整体方案将涉及三方面：同城双活、灾备方案设计、数据库备份恢复设计。

1.同城双活集群高可靠

缴费同城双活大集群采用全组件冗余部署架构来实现机房级高可靠。

同城双活集群全组件冗余高可靠

运维管理平台Great-Control采用主备式部署方式，在同城双机房部署。

调度节点(SQL-node)每机房部署3个，共部署6个节点。调度节点为多活部署，应用登录任一调度节点的集群拓扑与数据信息完全一致，调度层通过前端业务负载均衡实现高可靠，自动屏蔽故障调度节点并自动识别恢复的调度节点进行负载均衡。

配置节点层同城A机房部署3节点，同城B机房部署2节点，当B机房故障时，A机房保留多数节点集群正常对外提供服务；当A机房故障时，集群机房故障切换流程将强制recoverB机房的zookeeper并将其补充到3节点以上规模，以完成集群机房级切换。

数据节点层共10个数据源，每个数据源包含1主3备共4份数据冗余副本，每个机房2份数据冗余副本，副本间基于分布式数据库的“类raft增强一致性同步协议”以确保数据强一致。即机房级故障场景中同时损失一个机房的2个副本的场景下，集群故障切换RPO=0，且依然可以正常对外提供服务。

数据存储采用本地存储，基于SSD做raid10。

集群其他组件，包括集群备份工具、数据同步工具GreatSync都采用同城双机房主备部署。

2.逃离库与异地灾备数据库集群

缴费业务使用国产数据库或开源数据库主备集群作为逃离库环境。逃离库将存储全量集群数据，并通过GreatSync将分布式数据库集群变更信息异步同步到逃离库集群。

当调度节点（SQL-node）出现不可恢复的故障或者其他原因，无法提供服务时，应用系统直接连接逃离数据库，通过降级运行以提供最基础数据服务。

缴费业务逃离库

同时缴费业务的异地灾备集群部署方案为：

1）部署独立的灾备集群，位于异地灾备机房。

2）本地主集群与异地灾备集群间采用异步方式通过GreatSync进行数据同步，避免灾备集群数据同步对本地主集群的影响。

3）当本地主集群完全不可用且无法启用逃离库时，将启动切换灾备数据库集群流程。

3.数据库集群备份恢复

缴费数据库集群在同城双机房各部署一套集群备份工具。集群备份工具在业务低峰时进行集群物理备份。如下图所示，为保证缴费集群各节点备份信息全局一致性，每次全量与增量备份后获取集群全局一致性信息，即全局无分布式事务正在提交的一致性点位信息，并备份该点位相关的日志文件。缴费业务的数据将还原到某一次全量备份或增量备份对应的一致性点位信息位置。

GreatDB数据库备份

在缴费业务维护中，集群备份主要用于如下场景：

1）集群灾备备份长期保存。

2）用于恢复集群逃离库。

3）用于恢复灾备集群或准生产测试集群。

4）用于恢复误删除数据。

二、库表分布方案

缴费业务集群共有10个数据源，其中1个为global数据源，用于部署全局表；1个为norm数据源，用于部署非分片表；8个为分片数据源，用于存储集群sharding拆分的分片表数据。

主要数据表分布规则如下：

1.分片表部署

针对订单类、流水类和监控类大数据量表进行sharding拆分，拆分字段分别为订单号和流水号。通过业务表水平拆分，减小单分片压力。

2.全局表部署

针对元数据性质表，例如商户信息、缴费项目等，采用全局表方式进行存储。

3.非分片表部署

对于非分片非全局业务表，将部署在norm数据源，简化部署复杂度与应用适配复杂度。

三、业务改造与迁移方案

缴费业务从Oracle迁移到分布式数据库过程中涉及的步骤如下：

1.改造与迁移方案概述

缴费业务从原oracle+小机的数据库架构迁移到分布式数据库+X86集群架构。业务程序通过基于MySQL进行调整，调整后的业务程序在分布式数据库集群上进行适配验证。分布式数据库对外暴露标准的MySQL协议，业务适配过程几乎零改动。

业务迁移过程分为三个阶段：

1）业务双写

通过缴费业务程序双写，实现oracle集群上的缴费负载1：1应用到分布式数据库集群，验证集群的稳定性、性能、与可靠性。

2）缴费项目逐步迁移

缴费项目共8400+，项目之间在业务上相对独立，将缴费项目逐步切换到分布式数据库集群中。

3）原oralce集群下线

所有缴费项目迁移完成后，下线原oracle数据库集群。

2.Oracle语法改造

缴费业务从Oracle迁移到分布式数据库集群涉及到业务改造。主体业务功能和处理逻辑改造保持基本不变，主要改造应用程序与数据库交互部分。

3.应用流水号迁移

缴费业务基于Oracle序列生成应用流水号，分布式数据库集群提供的Oracle序列兼容，可直接迁移Oracle序列到分布式数据库集群。

4.缴费日终批量迁移

按照总部日终批量规范，应用和数据库分离部署，日终批量在数据库服务器进行跑批。但对于分布式数据库集群，数据库服务对应用使用透明，日终批量需与数据库服务器进行分离，且考虑分布式数据库架构特性，对日终批量程序实现进行调整。

5.缴费数据库流量切换设计

缴费业务采用Oracle架构与分布式数据库架构双线运行；基于路由服务，逐步将缴费项目逐个从oracle架构切换到分布式数据库架构。

缴费数据库流量切换设计

四、集群扩容与部署调整方案

分布式数据库集群支持在线scale-up和scale-out，来应对缴费业务集群日常运维中所需的集群扩容与各类部署调整需求。

1.机器更换：基于运维管理平台在线灵活地实现集群机器的更替。

2.机房搬迁：缴费业务系统的同城双机房其中一机房需要搬迁，搬迁过程业务需要在线且平稳。

作为应对：

分布式数据库集群支持在线将所有数据主节点切换到单一机房，实现单一机房承载；通过运维管理平台在主机房在线新增集群数据节点；设置故障切换优先级，逐步下线被搬迁机房节点；搬迁完成后添加新机房节点，恢复集群副本；剔除主机房多余副本集群；最后回切数据主节点，将主库均匀分布在同城双机房中。

3.集群扩容

缴费业务增长较快，分布式数据库集群会提供两种集群扩容方案：

1）缴费集群数据库机器数据节点存在一定程度的节点复用。分布式数据库集群支持在线调整数据节点分布，集群冗余节点的扩容和与缩减实现部署调整，通过降低机器数据节点复用来提高集群整体性能并降低机器故障时对集群数据节点分片的影响。

2）横向扩容集群，扩容过程通过运维管理平台进行，数据自动在线单调重分布，对业务影响控制在20%以内。

方案案例及效果

缴费业务通过从小机+Oracle架构迁移到X86+分布式数据库实现如下收益：

1.数据强一致，提高数据库集群可靠性。

2.数据库集群部署更加灵活且高可扩展。

3.性能更优，满足未来发展需求。

4.易迁移。

5.成本可控，相比小型机，基于X86服务器的分布式数据库缴费集群未来进行硬件升级迭代的成本总体可控。

方案未来展望

在企业中，对于新技术新产品的选型不仅为了满足当前业务场景的需求，还要考虑到未来三至五年的发展道路和方向，及是否能够不断迭代以满足未来业务需求。因此，用户仅了解每一种技术的现状将是远远不够的，只有当认识到一种技术的发展策略及其架构的局限性后，才能够预见和洞察未来。架构局限性并不等于功能的缺失。很多新型技术在开始时都无法提供像Oracle一样完备的企业级功能，但并不意味着用户必须要等到全部功能完备后才开始考虑学习和使用。

对于分布式数据库来说，其业务场景和数据使用处理方面的需求已趋于成熟和明朗，分布式数据库在场景和功能上区分更为细化，分为分布式联机数据库和分布式计算数据库两种，而针对非结构化小文件需求也在考验分布式数据库是否在这个领域能够打出一片天地。