案例 | 金融信息系统多活架构设计探索_

文 / 成方金融科技有限公司冯欢

近年来，随着数字化转型的深入，各大金融机构纷纷探索基于分布式、云原生的新一代信息系统架构，以应对日益加速的数字化业务发展，实现科技自主可控，获得更好的系统可用性和伸缩性。这对架构设计模式提出了更为严苛的要求，有别于传统架构的多活模式逐步成为架构转型的重要方向之一。

系统架构面临的新挑战

在架构转型与技术自主可控改造的过程中，基于X86和ARM服务器逐步替换传统的大型机、小型机，成为新一代基础设施，但是其在算力和稳定性方面与传统技术相比都存在着一定的差距，系统大量的内存级集中式运算不得不转化为依赖网络IO的分布式运算，这为系统架构的设计带来两方面挑战。

一是可用性的挑战。自2007年至2019年的十余年间，《GB/T 20988-2007信息系统灾难恢复规范》《JR/T 0044-2008银行业信息系统灾难恢复管理规范》等多项国家级和行业级标准规范颁布，对灾难、灾难备份、灾难恢复等概念进行了说明，定义了具体的容灾能力等级，量化了每项等级的能力标准，为系统建设提出了更详细和严格的要求。而新基础设施使得系统对于网络层面、系统层面的故障反应更敏感，需要通过多实例集群的整体可用性代替原来的单点可用性，以期追平甚至超越传统集中式架构的系统健壮性，满足行业标准要求。

二是处理能力的挑战。受限于单一节点算力的约束，云上或分布式系统不得不通过构建一个跨数据中心、跨机房、跨城市的大系统来突破瓶颈，保证整体的处理能力，以适应数字化业务量的激增，同时还需要充分利用云原生等技术优势，获得更优越的系统伸缩能力。为此，多活架构成为新的行业发展方向，人民银行也于2021年发布《金融信息系统多活技术规范》，本文在该规范所提出的参考架构基础上，分析细化了具体的架构设计实践，总结出设计要点和几类设计模式。

多活架构设计要点分析

为尽可能规避各个级别的故障与灾难，获得良好的高可用性，需要充分利用冗余部署来规避系统计算热点的出现和数据的丢失，传统的方式是构建主备模式（AS，Active-Standby）的系统架构。

主备架构本质上是单活架构，只在主中心完成数据读写，备中心通过应用和数据的备份来解决因数据中心故障造成的对外服务中断，在一定程度上保证了高可用性，但是每个运行时访问流量均集中在单一数据中心，系统可承载的业务访问量、跨中心的伸缩性都受到很大限制，备中心数据及服务均处于空闲状态无法承接请求，系统整体处理能力不足。为缓解上述问题，可考虑将查询访问流量分散到备中心，在主备模式基础上形成备中心可读架构（AQ，Active-Queriable）。

备中心可读使系统应对无状态的查询流量具备了更强的处理能力，可将其视为初步的多活架构，对于读多写少的系统而言，该模式可以有效地解决问题，既满足了基本的数据不丢失，也充分分散了业务流量，具备了伸缩性，减少了资源空闲浪费。然而其瓶颈也很明显，写入流量仍然要集中在单一数据中心完成，当系统要处理大量写入请求时将难以应对。按照《金融信息系统多活技术规范》的说明，只有满足多点读写才纳入真正的多活范畴，可见写入分流存在一定的设计难度（见图1）。

之所以不能简单地写入分流，是因为当数据采用多副本存储时，如何保证副本间数据一致性将成为核心问题。一种策略是通过分布式事务保证多副本写入的强一致性，该方式对应了《金融信息系统多活技术规范》中提到的“全集业务方式”，它虽然可保证每个数据副本具备全量数据，但代价较高，实现复杂，规范也提示“全集业务方式实现难度较大，业内较少使用”。另一种策略是优先写入主本，再同步至副本，此方式必须保持主副本数据写入的顺序关系，以确保数据最终一致性。

大部分系统都适宜采用上述第二种策略实现多数据副本存储。但维持主副本写入顺序和实现多点并发写入之间存在矛盾。为解决该矛盾，建立真正的多活模式（AA，Active Active），需要对数据进行水平分片，按照一定规则拆分为多个小的数据集群（或称为单元），每个集群承载一部分业务请求，每个集群内部仍为AS主备模式，保持自身数据的主副本关系，而集群之间可并发写入，该方式对应《金融信息系统多活技术规范》中提到的“限部分业务方式”，使系统整体表现为多活处理能力，数据集群拆分越均匀分散则多活能力越强，拆分规则可根据业务特点确定，如按照客户属性、省份机构、参与者特点等。由此可以简要总结多活架构的两项设计要点：一是通过数据水平分片，形成多数据集群（多单元）的多活处理能力。二是某个数据集群（单元）出现问题可通过切换流量，由其他集群托管。

多活架构设计模式比较

为满足上述设计要点，数据集群间的流量托管会有多种实现方式，从而产生不同的多活架构设计模式，各类模式有其自身的特点与适用场景。为聚焦在数据中心级的多活模式分析，后续均以单一数据中心内包含一个数据集群的情况举例说明。

1.交叉托管模式。交叉托管模式最初伴随双中心双活架构产生，顾名思义，建立两个数据中心交叉互备，当某中心故障时，可切换流量至对中心。该模式有很多变种，如可在双中心互相热备基础上，再建立第三个数据灾备中心，以保证极端情况下数据可恢复。由于交叉热备的双中心需要随时托管对方流量，数据要求强同步写入，两中心相距通常不超过40公里，集中在同一城市内，另外的数据灾备中心可跨城市建设，于是形成经典的两地三中心架构。

该架构实现了同城双活，且由于数据强同步可保证同城切换时RPO约为零，RTO在秒级甚至毫秒级。但如果发生城市级灾难，则必须利用异地灾备中心人为恢复业务，时间较长。如果想完成异地也可实时切换，不希望过多人为操作，则可进一步扩展为两地四中心架构或四地八中心架构。即城市间也形成对等的交叉互备关系，数据同步采用异步传输方式，允许一定量的数据丢失和切换时延，一旦某城市双中心均不可用，可实切至对城市、资源和架构基本对等，RPO、RTO均保持在分钟级，从而达到同城双活、异地可实切的多活能力。

总体来看，交叉托管模式在同城内保持了数据强一致性，适用于较高业务连续性要求的场景，可承载的业务总量也随着城市、数据中心个数的增多而表现优异。但是其也存在一些弊端：一是同城双中心的数据强同步会影响写入时效性；二是成对交叉部署使数据中心、城市通常以偶数个存在，建设成本高，中心级的伸缩性受到制约；三是资源的大量冗余会导致利用率不足。

2.串接托管模式。相比于数据强一致性和连续性，部分金融系统对于交易处理的时效性要求更高，跨中心的强同步写入通常不能容忍，且数据中心需要随着业务发展灵活调整，在此情况下交叉托管显得偏笨重，串接托管模式产生。该模式以单纯的数据中心为单位审视数据分布，各中心可能在同城市或跨城市分布，不再强调地域的约束，主备数据集群间采用异步复制，主本写入不受复制过程影响，形成“首尾相接”的回环托管关系，构建真正意义上的多地多中心架构（见图2）。

串接托管模式强调系统的快速处理能力和灵活伸缩，建设难度和成本适中，避免了不必要的冗余部署，资源可以得到更充分的利用。但是如果发生中心级灾难，其RPO受制于异步复制的时间差，同城内的整体业务连续性弱于交叉托管模式。

3.对等托管模式。为了既保留串接托管模式的灵活性和高效性，又弥补其在连续性上的不足，可将其进一步完善为对等托管模式。当出现中心级灾难时，允许将业务流量切换至任一可用中心的任一数据集群处理，甚至可切换至空白数据集群（空白单元）完成，从而快速恢复对外服务，各中心间实现对等托管。该模式对业务的处理方式有着较高要求，需保证新业务处理不依赖于历史数据即可完成，某些金融系统天然具备该特点，但是绝大部分系统难以满足，此时需调整数据存储方式，例如，采用“流水式存储”和“事后数据核对”的处理策略。

所谓“流水式存储”（见图3），是以类似日志流水的模式存储并修改数据，只插入数据，不更新数据，数据状态的变化体现在新的数据记录上，该方式保证了业务流量可以随时写入新库，对历史数据敏感度降低。同时，通过单独的应用服务对各中心、各集群数据进行定期的异步综合查询比对，完成事后的最终一致性纠正和数据聚合处理，例如，在日终核对修正，此时各备份数据仅提供只读服务即可。

对等托管模式实现了最为理想的多活架构，兼顾了系统处理时效性、连续性、伸缩性，资源利用率更高，但是须通过“流水式存储”和“事后数据核对”等方式降低处理过程对历史数据的依赖，对数据最终一致性及聚合过程的设计提出了高的要求。

综上，各多活架构设计模式特点比较如下（见表）：在实践过程中，很难通过单一模式满足全部需求，系统的不同数据和服务通常特点各异，因而可采取多种模式组合的方法来使系统架构更加完善合理。例如，针对数据能够按照业务规则均匀拆分，且业务处理时效要求高，处理过程较少依赖原数据的情况，采用对等托管模式，而对于一体化强且读多写少的数据和服务（如业务参数查询等），采用备中心可读的AQ模式，通过组合两种模式构建起整体多活架构。未来，伴随技术的发展和实践的深入，更多的模式与组合策略将被提出，相信通过持续地探索，金融行业信息系统的架构能力将会迎来更大的提升。

表各多活架构设计模式特点比较