作者hanfeng_twt·2022-03-02 15:24

数据库架构师·SphereEx

金融行业多活架构设计及容灾发展趋势

字数 8745阅读 5399评论 1赞 8

在2021年2月7日，中国人民银行发布了《金融信息系统多活技术规范》，将其作为指导金融行业标准。可以说金融业关系国计民生，维护金融信息系统安全是国家信息安全的重点，因发生灾难导致金融服务中断，可能对企业内部管理、公民、法人和其他组织的金融权益甚至国家金融稳定和秩序产生影响。为规范和引导在金融信息系统合理运用多活技术实现业务承载和灾难恢复，有效防范金融信息系统风险，保护金融机构客户的合法权益，特编制这一标准。本文针对这一标准并结合外部实践经验进行探讨。

# 1. 容灾技术背景说明

## 1).容灾架构演进

![](/home/attachment/202203/02/1228765_164620517983777.png)

- 最原始的系统架构非常简单，客户端请求进来，业务应用读写数据库，返回结果即可。此时的架构是没有考虑备份的，原系统出现问题后，无备份环境可用，不具备最基本的容灾能力。

- 为了解决上述架构的问题，比较简单的方式是提供备份系统。可在另一套环境中部署系统，但此时系统不启动，仅做备份使用，故称为“冷备份”。但出现问题时，启动系统即可。这种方案解决了没有备份系统问题，但恢复时间较长，需等待系统启动后方可使用。

- 为解决恢复系统时间较长问题，可引入“热备份”方式。顾名思义，这种情况是在另一套环境中部署系统且启动，但这一系统不承担任何业务访问。只有当出现问题时，才进行切换，立即投入使用。这一方案解决了时效问题，但对于备用系统有效性无法验证，且存在一定资源浪费。

- 为解决有效性及资源浪费问题，可升级为“只读业务”方式。这种方式下，备份环境部署的启动是工作的，但仅仅承担只读业务的访问需求。其与热备份方式的本质区别在于灾难备份系统是否持续在线；对于热备份方式，灾难备份系统持续在线，其与只读方式的本质区别在于是否承载业务。这一方案问题在于，无法验证完整业务有效性及资源利用不足。

- 解决只读业务方案问题，可利用灾备备份系统提供允许数据写入的业务。这里分为两种情况：一是部分业务，二是全量业务。对于限部分业务方式，是指在正常情况下，灾难备份系统具备全部的业务功能，但限定只针对全部业务流量的一个子集提供服务，其与全量业务方式的本质区别在于是否针对全部业务流量提供服务。对于全量业务方式，灾难备份系统在正常情况下，即可针对全部的业务功能和全部业务流量提供服务。对于这两种情况，灾难备份系统是“去中心化”的实现方式，其与生产系统之间并没有明显的主次之分，实现真正意义的“多活”。由于全量业务方式实现难度较大，性价比不佳，业内较少使用。对于限部分业务方式，在正常情况下，生产系统和灾难备份系统均具备全部的业务功能，可通过设定一定的并行策略，约定和控制生产系统和灾难备份系统分别承载部分流量；在灾难发生时，部分系统发生瘫痪，只会影响其承载的部分业务流量，其系统只要具备快速接管业务的能力，仍可做到较小的业务中断，保障业务连续性。

## 2).容灾技术发展

❖ 冷备

为了解决应用及数据单点问题，最初引入了冷备技术。这里谈到的冷备包含多层含义。原始的需求，就是将数据放在异地进行备份。当主环境出现问题时，可利用异地备份还原数据即可。整个业务恢复时间取决于数据恢复时间及重新部署应用的时间。为了解决应用部署问题，后续将应用在异地进行部署，但不启动，这样解决了应用部署问题。为解决恢复数据时间问题，可通过数据库的主从复制技术，提升数据完整度及故障恢复能力。无论上述如何改进，本质上来说都是冷备技术，备的部分不提供访问能力，存在一定的资源浪费。

❖ 主备

为解决上面资源浪费问题，出现了主备技术。其基本结构上与冷备差异不大，更多是在备角色的使用上面。通过将部分应用部署到备，充分利用备的资源。但受到数据同步限制，无法做到完美一致性，同时是考虑将备充当读取业务的承载，来分担主业务压力的同时，利用备的资源。为了充分利用备的应用能力，可以启用备的写应用，但是数据访问上仍然是访问主的数据。这种方式可以加快故障后的切换速度，同时也能启动一定的验证作用；但这种架构也有一个问题，就在于应对较大范围故障问题存在不足，当发生如机房级故障时无法做到切换。

❖ 多活（双活）

主备架构容灾能力有限，也促生了多活架构。所谓多活架构，简单来说是应用系统与基础架构配合，通过将业务处理单元化实现更大范围的容灾能力。根据实现方式可分为同城双活和异地多活两种方式。这部分是本文的重点，后面会详细说明。下图来自阿里分享案例。

![](/home/attachment/202203/02/1228765_164620522152903.png)

## 3).多活架构驱动因素

在传统容灾系统设计中，多采用主备方式。但从长期发展来看，其正向多活技术演进，其主要驱动因素有：

- 更高的灾难恢复要求

对于主备方式，当灾难事件发生后，灾难备份系统接管业务往往需要经过较长的时间，而当前业务的特点对业务连续性提出了更高的要求。特别像金融行业，对可用性要求非常高。

- 接管能力难以把控

对于主备方式，灾难备份系统在正常情况下并不承载真实业务，其真实接管能力难以有效评估，因对其接管能力的评估主要依赖于灾难恢复预案的制定、管理及演练效果，故一旦灾难发生，灾难备份系统是否可接管真实业务难以保证。

- 单数据中心扩展受限

由于各方面的限制，单数据中心的扩展能力往往存在瓶颈，或者持续扩展能力的经济效益降低。

- 资源利用率低

灾难备份系统在正常情况下不承载业务，资源浪费严重。

- 技术提升需要

主备方式是在传统技术架构的背景下提出的，而云计算、分布式等先进技术的成熟和应用推广，为信息系统灾难恢复能力的升级提供了技术支撑。

- 业务覆盖需要

对于覆盖地理范围较广的业务系统，部分用户业务接入的距离过长，可能由于处理延迟带来用户体验的下降。

# 2. 多活架构方案设计

## 1).系统架构分层设计

- 对于按照多活架构设计的系统，通常可拆分为业务接入层、业务处理层、数据存储层三层。其架构图如下，各层的职能如下：

- 业务接入层主要负责业务多点接入和灵活路由，将业务流量按照一定的路由策略发送至业务处理层；

- 业务处理层负责业务逻辑处理，并调用数据存储层功能实现数据读、写；

- 数据存储层负责接收业务处理层的调用进行数据持久化操作，实现数据的多点读、写功能。

![](/home/attachment/202203/02/1228765_164620526825330.png)

**解读：何为“多活”**

- 多地理节点部署

应用系统部署在多个地理节点，各地理节点的位置选择宜综合考虑电力、网络、供水等基础设施的容灾因素，包括独立的空调、电力设施、计算、网络、存储等物理资源。如上图中部署单元，应部署在不同地理节点中。

- 多种布局模式

根据地理节点的相对位置不同，多活系统的布局模式可分为同城多活和异地多活。

- 业务并行多点接入

各部署单元同时支持业务接入，并支持灵活调整业务接入，部分地理节点灾难故障不影响其他地理节点上部署单元的业务接入。

- 业务并行多点处理

各部署单元同时支持处理业务逻辑，并支持灵活调整，部分地理节点灾难故障不影响其他地理节点上部署单元的业务处理。

- 数据并行多点存储

各部署单元同时提供数据存储，且保证其他部署单元存在与业务处理结果一致、可用的数据副本。部分地理节点灾难故障不影响其他地理节点上部署单元的数据存储。

- 部分业务影响和及时接管业务

当某个部署单元发生灾难故障时，只有部分业务受到影响并需要分配到其他部署单元进行处理。当发生非区域性灾难时，同城多活部署单元可及时接管业务；当发生区域性灾难时，异地多活部署单元在较短时间内接管业务。

## 2).各层多活设计要求

❖ 应用接入要求

- 当应用系统要满足多活需求是，需接入两个或两个以上部署单元。

- 若应用是从多点发起业务请求，应将应用系统多点均接入两个或两个以上的部署单元。

- 在部署单元不可用时，应用应保证及时将业务流量分配至其他接入的部署单元。

- 应保证对于某个接入路径不可用时，其余接入路径具有足够的网络带宽和业务处理能力接管故障接入路径的业务流量。

- 应支持对应用系统进行分级分类，设置差异化的接入要求，如接入专线数量、接入专线隔离要求、接入专线网络能力、业务流量分配变更时间等。

- 接入不同部署单元的网络链路宜具有相同的链路特征，如网络带宽、传输时延等。

- 应保证不因部署单元的业务流量分配变更造成网络地址冲突等问题。

- 应定期开展应用切换演练，以保证某个部署单元不可用时，可将原来通过该部署单元的业务流量分配到其他单元处理。

❖ 业务接入层要求

- 应支持应用系统同时接入两个或两个以上部署单元的业务接入层。

- 应支持将业务流量发送至两个或两个以上部署单元的业务处理层，支持按路由策略对接入的业务流量进行路由选择；对于业务流量转发至异地部署单元的情况，可通过异地部署单元的业务接入层间接转发。

- 应支持对路由策略进行实时控制。

- 应保证某个部署单元发生灾难或故障时，其他部署单元具有足够的业务接入能力，在较短时间内接管原由其接入的业务流量。

- 应支持根据业务逻辑实现用户的业务流量路由的一致性，或通过与业务处理层协同工作以规避路由不一致对业务处理结果的影响。

- 设备应冗余部署，避免设备单点故障对业务接入的影响。

- 网络线路应冗余部署，避免单条线路故障对业务接入的影响。

- 应支持自动切换或集中切换功能，当出现参与方信息系统与业务接入层之间故障、接入层内部故障、接入层与业务处理层之间故障、业务处理层故障时，可自动或集中切换路由，保障业务流量发送至可用的业务处理层。

- 应支持对大于当前业务接入能力的业务流量进行限流，避免对部署单元造成影响。

❖ 业务处理层要求

- 应支持同时处理多个部署单元业务接入层转发的业务流量。

- 应保证某个部署单元发生灾难或故障时，其他部署单元具有足够的业务处理能力，在较短时间内接管原由其处理的业务流量。

- 设备应冗余部署，避免设备单点故障对业务处理的影响。

- 网络线路应冗余部署，避免单条线路故障对业务处理的影响。

- 应满足业务处理的无状态要求，具体包括：多个部署单元的业务处理层应用之间解耦，不存在依赖关系；业务处理层将单次业务的处理结果发送至数据存储层存储；业务处理层处理单次业务请求不依赖其他业务请求，业务处理过程中只使用来自单次业务请求携带的信息以及数据存储层存储的信息。

- 应满足业务处理的幂等性要求，即单次业务请求与多次重复业务请求的处理结果一致，不因多次重复业务请求而产生不同的处理结果。

❖ 数据存储层要求

- 应支持同时处理多个部署单元业务处理层的数据存储请求，或者支持处理其他部署单元数据存储层的数据复制请求。

- 应保证某个部署单元发生灾难或故障时，其他部署单元具有足够的存储能力接管原由其存储的数据量。

- 业务数据应在多个部署单元的数据存储层存在数据副本。

- 对有数据一致性要求的数据，应在同城部署单元具有满足数据强一致性的副本，应在异地部署单元具有满足在较短时间内达成数据最终一致性的副本。

## 3).多活关键指标设定

部署单元的关键指标包括多活业务集中度、多活同城业务集中度、多活业务接管时间、多活数据恢复点目标、多活接管容量能力，这些关键指标共同决定了多活信息系统应对灾难的能力。

- 多活业务集中度

用于衡量业务在各个部署单元之间的分散程度，降低多活业务集中度可降低单一部署单元灾难或故障的业务影响范围。例如：多活业务集中度为 25%，其可能实现方式是部署 4 个部署单元，并且在各部署单元间平均分配业务接入流量、业务处理流量和数据存储量，当任何一个部署单元发生灾难或故障，受影响的业务均不超过全部业务的 25%，其余的业务不受任何影响。

- 多活同城业务集中度

用于衡量业务在各个不受同一区域性灾难影响的地理区域间的分散程度，降低同城业务集中度可降低区域性灾难的业务影响范围。例如：多活同城业务集中度为50%，可能的实现方式是两个地理区域分别部署两个部署单元，并且在四个部署单元间平均分配业务接入流量、业务处理流量和数据存储量；其他可能的实现方式是双活信息系统，两个部署单元部署在不同的地理区域，平均分配业务接入流量、业务处理流量和数据存储量。对于上述两种实现方式，均满足任何一个区域性灾难发生后，受影响的业务不超过全部业务的 50%，其余的业务不受任何影响。

- 多活业务接管时间

用于衡量灾难发生后，对受到影响的部署单元业务流量重新分配并由其他部署单元接管的时间。降低多活业务接管时间，可减少灾难引起的业务（部分业务）的中断时间。

- 多活数据恢复点目标

用于评价当发生灾难或故障时，部署单元中受影响的数据应恢复到的时间点要求。

- 多活接管容量能力

用于衡量灾难发生后，部署单元承载受影响业务的能力，可用部署单元能承载受影响业务的百分比表示。例如，设定在单一部署单元故障时，其他部署单元可接管 100%的业务；设定对于任何区域性灾难，其他部署单元可接管其 50%的业务。为了达到上述要求，需要合理分配部署单元的冗余容量，同时还要考虑冗余容量在各个部署单元之间的分布，以及冗余容量在不同地理区域之间的分布。

# 3. 多活架构演进策略

## 1).系统演进策略

❖ 应用场景分析

向多活演进前提是进行业务影响分析，确定采用多活技术的业务范围及其承载系统，然后评估向多活演进的可行性。

❖ 业务范围分析

在向多活演进的业务范围分析中，重点关注如下内容：

- 承载重要业务的系统宜考虑采用多活技术。

- 重要业务的支撑系统（如重要的认证和加密系统等）宜考虑采用多活技术。

- 已经出现处理能力瓶颈的系统，或业务突发性高的系统宜考虑采用多活技术。

❖ 可行性分析

在向多活信息系统演进的可行性分析中，重点关注如下内容：

- 是否缺少成熟的多活解决方案和技术组件。

- 系统上承载各应用间的耦合程度，以及改造涉及范围。

- 迁移至开放平台的业务较容易实现多活。

- 可根据系统重要程度依次进行多活演进。

- 部分账户型系统对于数据一致性要求较高，建设异地多活的难度较大，集中式系统上可考虑保留一类结算账户及与之结合紧密应用。

- 宜优先采用开放式系统承载新增业务、处理性能有扩展要求业务、创新型业务（如互联网金融等），以便于后续向多活系统演进。

## 2).系统演进路线

根据业务发展的不同阶段对金融信息系统业务连续性和灾难恢复的要求，金融信息系统向多活信息系统的演进路线大致会经历如下几个阶段，如图：

![](/home/attachment/202203/02/1228765_164620541350059.png)

- 阶段一：生产系统和数据备份

对系统关键数据进行同城或异地备份。数据备份的周期可是实时或者定期。生产中心发生灾难时，在灾备中心临时部署应用系统，加载关键数据，恢复业务服务。

- 阶段二三：生产系统（同城）和灾备系统（异地）

在同城或异地中心部署灾备系统，并在生产中心和灾备中心间建立数据同步，同步周期可实时或定期。日常由生产系统提供服务，生产系统发生灾难时，由灾备系统接管服务。灾备系统启动通常包括启用灾备中心系统环境、启动应用、加载数据、连通性验证等工作。为了提高资源的利用效率，在日常情况下充分利用灾备系统。部分金融信息系统在上述方式的基础上，由灾备系统同时提供查询服务，当发生灾难事件时，由灾备系统接管服务。灾备系统接管服务通常包括暂停数据库异步复制、修改灾备系统数据库状态、启动灾备系统应用环境、流量切换等工作。

- 阶段四五：生产系统（同城双/多活，异地多活）

从主备阶段向双活或多活演进的过程需要大量的业务梳理、系统能力评估、业务影响分析、风险分析等相关工作，还涉及到应用系统改造，对于不同的业务现状和系统现有架构情况，存在很大的差异。最核心的工作涉及到将原有生产系统上的应用和数据进行拆分，并且根据拆分规则建立新的数据同步关系，同时实现应用并行业务处理相关的改造等，在拆分的过程需要额外注意数据的备份，并且具备出现异常后的回退机制。从架构上看，双活可作为多活架构的一种特例来设计，但对于同城与异地则存在较大差异。下表简单总结两者区别：

![](/home/attachment/202203/02/1228765_164620544375986.png)

# 4. 多活架构实践说明

## 1).金融场景多活策略

下文根据金融行业特点，抽象出若干种场景，分析其多活策略。

- 流水型系统

流水型系统实现实时支付、证券交易、订单等业务的发起方和接收方之间的转接功能。典型的流水型系统是银行渠道系统、转接清算系统、非银行支付机构的快捷支付（协议支付）系统等。对于此类系统，业务请求和业务请求响应需要实时转发至业务发起方和业务接收方，对系统的实时性有较高的要求，但关键数据（如交易涉及的账户数据）的一致性由业务发起方和接收方保证，流水型系统对业务的流水信息进行记录。流水型系统的幂等性处理是架构设计的重点和难点，可采用多层幂等保障机制，如用户发起业务流量环节幂等、实时业务处理环节幂等、交易对账环节幂等。采用多活技术的流水型系统，可实现业务流水信息（如订单信息、交易信息等）的多点存储和业务的多点转接，各部署单元分担流量，并且在部分部署单元发生灾难或故障时，其他部署单元仍可接管业务流水信息记录和业务转接。对于处于重要业务处理路径上的流水型系统，采用多活技术可避免因流水型系统的灾难或故障造成重要业务的全业务流程中断。

- 账户型系统

账户型系统主要实现账户信息、用户信息等业务数据的处理和记录。此类系统需要优先保障关键数据的一致性，当灾难或故障发生时，应在达到关键数据一致性的前提下，实现业务可用性。账户型系统的数据一致性是架构设计的重点和难点，应结合业务模型选择解决方案，如关键数据采用同步复制等手段、将只读数据和可写数据分离、业务处理层与数据存储层协调工作等。采用多活技术的账户型系统，可根据需要设计各部署单元的并行策略，将账户拆分到多个部署单元，并行进行账务处理。当故障或灾难事件发生时，只有部分账户受到影响，并将其业务流量变更至其他多活子信息系统。

- 计算型系统

计算型系统实现清分清算、风险控制、商户结算等相关的计算，还包括金融领域的各种科学、工程、数据分析、音视频处理等相关的计算。此类系统对输入的业务进行计算，并将结果输出至其他系统，计算过程所需数据全部来源于单次计算业务请求或外部系统。此类系统重点保障计算应用的可用性和准确性。采用多活技术的计算型系统，可实现多点计算、多点输出结果。这样可将多个部署单元的输出结果相互核对，提高准确性，还可在部分部署单元灾难或故障时，直接取用其余部署单元的计算结果。在一些场景下，计算所需数据可能分散在分布式系统中，可能会采用多层级计算再汇总计算的方式。

- 查询型系统

查询型系统实现对用户提供各种用户信息、交易记录、交易行情、订单记录、发布信息等相关查询。此类系统中的查询应用不会对系统存储的数据进行修改（或者查询业务流量比率远远大于有数据写入和修改的业务流量的系统），数据主要由外部系统导入。此类系统重点保障查询应用的可用性，以及被查询数据的多副本存储、被查询数据的多副本之间的一致性，以保证各多活子系统查询结果相同。采用多活技术的查询型系统，可实现多点查询。多个部署单元之间可分担查询流量，并且在部分部署单元出现灾难或故障时，可通过其他部署单元查询信息。

## 2).多活设计常见误区

- 所有业务都需异地多活

异地多活，是为了保证业务的高可用。所以本质上，还是要看业务的高可用需求。一般情况下，会优先保证核心业务支持异地多活。

- 数据实时一致性

异地多活本质上还是通过异地的数据冗余，来保证极端情况下业务也能提供给用户。因此数据同步是异地多活的核心，但完美的数据实时同步是不可能的。业务要求数据可做到实时同步，物理约束又限制数据无法完美同步。虽然可通过搭建高速网络、减少同步规模、减少业务对数据同步依赖等手段来缓解上面问题，但根本上还是需要根据数据业务特征进行差异化处理，实现最终一致性满足业务需求。

- 依靠存储系统同步即可

数据同步是多活核心，一般存储系统（如数据库）都会有自身同步能力。虽然绝大部分场景下，存储系统自身同步功能是够用的，但在某些极端情况下还是有所欠缺。理想的做法是开拓思路，避免仅使用存储同步功能，将多种手段配合存储系统同步来使用，甚至可不采用存储系统的同步方案，改用自有同步方案。

- 要做到业务100%可用

异地多活无法保证100%业务可用，这是由物理规律决定的，光速和网络传输速度、硬盘写入速度、极端异常情况等，都是无法100%解决的。多活架构，通过单元化处理可满足系统整体上大部分可用，但是要忍受一小部分业务的损失。不存在完美的多活方案，可通过挂公告、事后补偿的方式进行安抚处理。

多活容灾金融

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！