应用多活的相关概念
容灾（Disaster Tolerance），是指在自然灾害、设备故障、人为操作破坏等灾难发生时，尽可能保证生产系统数据少丢失，保持生产系统的业务不间断地运行。
在衡量系统容灾效果或高可用特性时，一般有两个指标：
- RPO（Recovery Point Objective）：即数据恢复点目标，主要指的是业务系统所能容忍的数据丢失量，也就是业务系统恢复服务功能时，恢复得来的数据对应的时间点。
- RTO（Recovery Time Objective）：即恢复时间目标，主要指的是所能容忍的业务停止服务的最长时间，也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。
在高可用方面有一些与容灾接近的概念，有时它们之间是相通的，但侧重点不同：
- 容错（Fault Tolerance）：指系统在部分组件（一个或多个）发生故障时仍能正常运作的能力，侧重于原基础设施，强调冗余和业务连续性，允许接受系统降级。
- 灾难恢复（Disaster Recovery）：指系统在灾难发生后的恢复能力，侧重于新基础设施，强调数据找回和恢复效率，尽可能挽救业务。
容灾的基本方式，是在生产站点以外建立的冗余站点，灾难发生后，冗余站点可以接管用户正常的业务，达到业务不间断的目的。按照容灾系统对应用系统的保护程度可以分为数据级容灾、应用级容灾和业务级容灾。
- 数据级容灾：仅将生产中心的数据复制到容灾中心，在生产中心出现故障时，仅能实现存储系统的接管或数据的恢复。基于数据级容灾实现业务恢复的速度较慢，需要在容灾站点恢复数据实例和部署恢复应用，通常情况下RTO在天级别。
- 应用级容灾：在数据级容灾的基础上，增加对生产中心系统的基本复制，容灾中心建立起一套和本地生产环境相当的备份环境，包括主机、网络、应用、IP等资源。当生产系统发生灾难时，异地系统可以提供完全可用的生产环境，应用级容灾的RTO通常在小时级别。
- 业务级容灾：容灾中心具备业务系统的完全复制，生产中心与容灾中心对业务请求同时进行处理，故障时只需切换业务流量，能够确保业务持续可用。采用这种方式，业务恢复过程的自动化程度高，RTO可以做到分钟级别。
到目前为止，灾备容灾都是行业内应对灾难的主流方式，也就是常说的冷备、热备。灾备容灾建立在数据级容灾或应用级容灾基础上，常用的实现方式是在备份机房构建一套相同的应用系统，灾难发生时会在约定的时间范围（RTO）内恢复运行，尽可能减少灾难带来的损失。
灾备容灾建设普遍都有建设周期长、业务成本高、使用频率低等问题，建设成本是所有应用容灾必然的共性，灾备容灾的局限性主要由于灾备中心平时不提供服务：
- 灾备中心平时不提供服务，关键时刻无法确定是否可以成功切换，灾难发生时不敢切
- 灾备中心平时不提供服务，整个灾备资源处于闲置状态，成本浪费较高，如果压缩灾备资源，恢复时可能进一步恶化切换成功率，或导致更大的RTO
- 灾备中心平台不提供服务，说明提供服务的机房还停留在单地域的生产中心，当业务体量上升到一定程度，无法解决单地域资源瓶颈问题
应用多活是应用容灾技术的一种高级形态，指在同城或异地机房建立一套与本地生产系统部分或全部对应的生产系统，所有机房内的应用同时对外提供服务。当灾难发生时，多活系统可以分钟级内实现业务流量切换，用户甚至感受不到灾难发生，对应前面提到的业务级容灾等级。
相较于传统的灾备容灾，应用多活具备如下优势：
- 故障隔离：切换只影响部分用户
- 恢复时间快：容灾只需切换流量，自动化程度高，一般分钟级RTO
- 支持异地扩展：所有机房内的应用同时对外提供服务，没有单地域资源瓶颈问题
- 资源利用率高：资源不存在闲置问题，多机房多资源充分利用，避免资源浪费
- 切换成功率高：标准化和常态化流量管理，关键时刻切换结果可预期
应用多活的典型架构
与其他所有容灾解决方案一样，应用多活的根本目标是保障业务连续性，而故障是不可避免的，所以目标主要包含两个方面：
- 尽可能减少故障的影响面
- 尽可能加快故障后的恢复
实现上由三个核心要点组成：
- 隔离：控制影响面和爆炸半径
- 冗余：提供容错和恢复的基础
- 路由：维持业务动态的可用性
在考虑系统架构时，一定的顺序可以帮助厘清这三者的关系：隔离代表着拆分的粒度，其中包括逻辑数据拆分和物理部署拆分；拆分决定着冗余的方式，其中包括数据备份方式和冗余部署方式；隔离和冗余决定系统静态的结构，路由通过流量调配，在静态的结构上维护系统动态的可用性。
应用多活构建于上述三点之上，需要实现两个一致性，即流量路由一致性和数据读写一致性：
- 流量路由一致性：从可用性的角度，所有业务请求均能在可接受的时间内有所响应，并且请求质量不随着部署机房的物理距离和底层设施的不同而改变。因此就需要从入口流量开始，每一层技术组件都能识别和纠错流量，减少不合理的跨机房或跨地域带来的访问延迟。
- 数据读写一致性：从一致性的角度，所有业务数据都要在可接受的时间内保持数据正确性，即数据延迟足够短和不出现数据错乱。这要求数据层具备数据同步的能力，以及在流量调配下，数据层组件能面向业务提供容错和保护的方案，避免数据冲突导致的不一致问题。
在物理架构方面，隔离拆分与物理距离相关，冗余类型与集群模式相关，如下表所示。
|
隔离|冗余 |
单集群 |
多集群 |
|
同城
|
|
|
|
异地
|
|
|
根据特征，尝试从表格中归纳三类应用多活的典型架构：单集群模型、多集群模型、单元化模型。
单集群模型：同城场景应用多活，实现机房级别容灾，依赖技术组件支持跨机房组成高可用集群，对应用系统的代码侵入较小。
多集群模型：同城场景应用多活（或接受跨地域调用延迟的异地场景），实现机房级别容灾，技术组件无法跨机房组成高可用集群，依赖跨集群数据单向同步以及集群切换的数据容错和保护，对应用系统的代码侵入较大。
单元化模型：为了解决单集群无法突破物理距离限制的问题，阿里提出了“单元化”方案。核心思路是对数据进行分片，通过自上而下的流量路由，让特定分片的数据到特定中心完成读写，以此解决数据一致性的问题， 并在此基础上解决了业务的容灾和水平扩展问题。这个可以水平扩展的逻辑中心称为"单元"。
单元分为两种类型，中心单元与普通单元。单元内部署的业务分为三种类型，全局业务、核心业务、共享业务。中心单元只有一个，部署全局业务、核心业务、共享业务。普通单元部署核心业务、共享业务， 普通单元具备水平的扩展能力，可以任意复制。
- 全局业务：强一致性的业务，在中心单元写，在中心单元读。
- 核心业务：做单元化拆分的业务，在普通单元写，在普通单元读。
- 共享业务：被核心业务高频依赖的全局业务读服务，在中心单元写，在普通单元读
对比前两个模型，单元化业务具备更高层级的抽象，核心是将业务逻辑和数据在同一个单元闭环，有点类似微服务的思想，以跨单元业务调用代替跨单元产生和消费数据。
三种业务分类在概念上易于理解，但底层还是依赖于技术组件的跨集群数据同步，并且路由调配需要与数据分片保持一致，实现上更加复杂，对应用系统的代码侵入最大。对于核心业务类型，需要支持数据双向同步，并以中心单元为中心构建星状数据同步，这样才能在某个单元故障时，其他单元能接管它的数据。
应用多活的技术方案
应用多活的技术方案，一般分为四个部分，分别是接入层、应用层、数据层和管理层，四层组件遵循应用多活的设计目标，支撑应用构建应用多活架构能力。
- 接入层：承接进入机房的业务流量，负责应用多活流量的识别和分发，具备机房路由和应用路由两个核心能力
- 应用层：业务应用流量主经的链路，主要包括微服务和消息两部分，具备流量路由、流量保护、故障隔离三个核心能力
- 微服务：业务流量在机房内部和跨机房的同步调用方式，一般有Consumer、Provider、注册中心等角色
- 消息：业务流量在机房内部和跨机房的异步调用方式，一般有Producer、Consumer、Broker等角色
- 数据层：涵盖业务应用数据读写、数据存储和数据同步，具备流量路由、数据一致性保护、数据同步三个核心能力
- 管理层：在各层组件的基础上实现全栈的多活管控能力，为上层业务屏蔽运维和管控的差异性，支撑业务应用运行
接入网关
一次业务流量请求，从移动端或PC端发起调用，到进入业务应用的整个流量链路过程中，期望能尽早进行路由纠错，以减少下游不必要的二次纠错和跨机房调用。
在流量链路上，DNS域名解析是最早的一个环节，但DNS仅支持按权重随机分流，无法满足应用多活架构流量灵活路由的需求。HTTPDNS具备自定义路由规则的能力，但HTTPDNS也存在着不适用于PC端流量的局限性。综上所述，应用多活架构需要在机房入口处部署一套流量接入网关，来负责七层流量的灵活路由。
接入网关核心能力可以概括为：
- 机房粒度流量路由：支持根据一定的比例规则，将流量分流到不同机房（比例分流）；支持从流量请求中提取携带的业务标识，并根据一定的路由规则，将流量路由纠错到正确的机房（路由纠错或精准路由）
- 应用粒度流量路由：支持根据流量属性按照一定映射规则，将流量路由到不同的后端应用
接入网关在技术架构设计时，存在单集群和多集群两种模式：
单集群模式：
- 接入网关集群对外提供一个统一接入点，流量进入网关后集群后，按照一定的路由规则将业务流量调度到相应机房内的应用
- 当某机房发生故障时，可以通过修改接入网关的流量规则，从而将故障机房流量切换到其他正常机房，实现故障机房流量切零
多集群模式：
- 每个接入网关集群对外提供一个统一接入点，使用DNS按权重解析访问到不同的网关集群，多个关集群均按照相同一致的的流量规则进行路由纠错
- 当某机房发生故障时，通过修改所有网关集群的流量路由规则，将故障机房的流量切换到其他正常机房。若故障影响到了接入网关集群，则还需要调整DNS权重来将故障机房整体流量切零
微服务
应用多活架构中，微服务多活组件同样需要具备流量路由纠错能力，来满足多种微服务调用场景的路由需求：
- 可能存在流量不经过接入网关的场景（例如定时任务调度发起的流量调用）
- 可能存在需要使用不同业务标识进行路由纠错的场景（例如用户A向用户B转账处理过程中的服务调用，需要分别使用2个用户ID进行路由）
- 可能存在需要使用不同数据维度的路由规则进行计算和纠错的场景（例如电商交易下单处理过程中的服务调用，需要使用用户ID和商品ID来分别进行路由）
业务应用集成微服务多活组件通常有SDK、Agent、Sidecar等不同形态，核心能力可以概括为：
- 流量路由：支持根据服务属性和参数等信息，按照一定条件进行规则匹配和路由，使服务调用到相应机房内的Provider节点（条件路由）；支持Consumer优先调用同机房内的Provider，从而减少跨机房调用，同时还能将故障的爆炸半径控制在一个机房内（优先路由）
- 流量保护：Provider接收到服务请求时，根据最新的路由规则进行计算，若识别为错误流量，则拒绝处理请求，保证全局流量路由的一致性
- 故障隔离：当局部Provider出现异常时，支持将异常的Provider进行故障隔离，保证所有机房内的Consumer 均不会调用到异常的Provider，实现微服务流量的故障逃逸
微服务多活组件在技术架构设计时，存在单集群和多集群两种模式：
单集群模式：
- 多个机房内的应用共享同一个注册中心集群，Provider对所有机房的Consumer可见，微服务调用时按照一定的流量规则进行路由纠错，使Consumer调用到正确机房内的Provider
- 当流量没有命中路由规则时，支持同机房优先调用，避免跨机房带来的RT增长
- 当某机房发生故障或局部Provider出现故障时，根据一定的异常识别策略可以自动进行故障隔离
- 当机房内健康的Provider低于一定数量时，则同机房优先调用策略失效，随机调用到所有机房内的健康Provider节点，避免继续同机房调用流量压垮下游Provider应用
多集群模式：
- 应用固定访问本机房对应的一个注册中心集群，服务同步组件通过异步复制的方式，实时将所需的Provider 服务同步到其他集群
- 基于跨注册中心的服务发现，微服务调用时就能按照一定的流量规则进行路由纠错，使Consumer调用到正确机房内的 Provider
- 当微服务调用没有命中路由规则时，可以同机房优先调用，避免跨机房调用带来RT增长
- 当某机房发生故障时，可以通过修改流量路由规则将故障机房微服务流量切零，使得所有机房内的Consumer不再调用故障机房的 Provider
消息组件
由于消息是异步消费的，从消息被生产出来再到被消费到的时间段中，流量路由规则可能发生了变化（例如进行了切流）。如果消息有堆积的话，那么这个异步消费的时间差还会更长，生产和消费两个时间点路由规则不一致的概率会更大。因此只在上游通过接入网关、微服务调用进行流量路由是不够的，还需要在消息消费时按照最新的路由规则再次进行路由纠错。
业务应用集成消息多活组件通常有SDK、Agent、Sidecar等不同形态，核心能力可以概括为：
- 流量路由：消息需要根据最新的路由规则进行路由，仅在正确的机房内进行消费
- 流量保护：Consumer接收到消息时，根据最新的路由规则进行计算，拒绝路由错误的流量
- 故障隔离：当某机房发生故障时或局部Consumer出现异常时，支持对异常的Consumer进行故障隔离，保证异常的Consumer不再消费消息，实现消息流量的故障逃逸从而快速恢复业务
消息多活组件在技术架构设计时，存在单集群和多集群两种模式：
单集群模式：
- 多个机房内的应用均共享同一个消息队列集群，上游应用生产的消息，根据路由规则分配到下游Consumer应用进行异步消费
- 当某机房发生故障时，可以对故障机房内的Consumer进行故障隔离，避免故障机房内的Consumer继续消费消息
多集群模式：
- 应用固定访问本机房对应的一个消息队列集群，多个集群之间通过消息同步组件实现消息数据的同步。一个机房内应用生产的消息，会异步同步到其他所有机房，但消息消费时会进行路由纠错， 仅允许正确的机房进行消费，其他机房则识别为错误流量不消费
- 当某机房发生故障时，可以通过修改路由规则，将故障机房的流量切换到其他机房，从而让其他机房内的 Consumer能够在消费路由计算时，识别为正确流量从而进行消费。另外多个消息队列集群的消息消费速率和堆积情况是不一样的，为了避免故障机房堆积未消费的消息已经被其他机房丢弃，因此修改路由规则生效后，还需要对流量切换的目的机房进行消费位点回溯
数据层
数据层多活核心需要解决的是数据一致性的问题，需要针对可能出现数据不一致的问题场景进行数据一致性保护：
- 一个真实复杂的业务系统当中，即使有上游链路的路由纠错，仍然有可能出现流量路由不一致的情况（例如调用链路路由标丢失导致路由失效、路由规则推送部分应用节点失败等）
- 切流时，变更的路由规则推送给接入网关集群、应用节点过程中，短时间内会存在不同机器上路由规则不一致的情况
- 切流时，如果数据异步同步存在延迟，则切流目的机房内的应用可能读写到旧数据，以及写后被同步数据覆盖的问题
数据层是读写数据库前的最后一道关卡，相比采用异步或定时数据对账来事后发现数据不一致问题的方式，在数据写入前通过路由正确性校验和错误流量禁写等保护措施，能够提早杜绝数据不一致的发生，从而避免此类问题的进一步扩大和蔓延。
业务集成数据层多活组件通常有SDK、Agent、Sidecar等不同形态，核心能力可以概括为：
- 数据一致性保护：
- 日常态禁写保护：支持写数据时根据最新的路由规则进行计算，若是错误流量则禁止写入，避免正确路由流量和错误流量分别在多个机房读写数据，造成脏写
- 切流态禁写保护：切流时，支持在流量路由规则变更和推送到接入网关和应用节点期间，禁止所有机房内的写数据库操作，保证切流期间数据不脏写（规则变更期间禁写）；切流时，支持在数据同步延迟期间，对切流目的机房内的应用采取禁更新策略，禁止数据更新操作的执行（可以针对受切流影响的数据范围进行控制），避免出现脏写以及写后又被同步数据覆盖的问题（同步延迟禁写）
- 数据同步：支持将数据异步复制到其他机房，以便实现数据的冗余备份，保障故障场景数据不丢失和极端场景数据少丢失
- 数据源切换：在多机房内的应用均读写单数据库集群的情况下，支持单集群发生故障时能够将应用访问连接的数据源切换到另一个备数据库集群
数据层多活组件在技术架构设计时，存在单集群和多集群两种模式：
单集群模式：
- 同城近距离场景，由于机房间网络延迟小可以选择数据库单集群的模式进行强一致的数据读写
- 多个机房内的应用均读写单集群数据库，这样能够保证数据的强一致，但业务也需要承担跨机房访问网络延迟带来的RT升高问题
- 当某机房发生故障时，仅需将故障机房的上游流量切零即可，分布式数据库就是典型的单集群模式
多集群模式：
- 同城近距离场景，多个机房内的应用可以读写主集群数据库，与单集群模式类似，但容灾时需要进行数据源切换和数据禁写保护
- 异地远距离场景，数据按一定业务维度进行分片（分片的规则就是流量路由规则），一个业务请求经过上游层层路由纠错后，最终保证只在正确的机房强一致的读写对应分片范围内的数据，容灾时需要接管分片数据和数据禁写保护
