1. 前言
多活容灾 MSHA（Multi-Site High Availability），是在阿⾥巴巴电商业务环境演进出来的多活容灾架构解决⽅案，可以将业务恢复和故障恢复解耦，有基于灵活的规则调度、跨域跨云管控、数据保护等能力，保障故障场景下的业务快速恢复，助⼒企业的容灾稳定性建设。
多活，顾名思义就是分布在多个站点同时对外提供服务。与传统的灾备的最主要区别就是多活里的所有站点同时在对外提供服务，不仅解决了容灾本身问题，还提升了业务连续性，并且实现了容量的扩展。
本文结合实际案例来阐述下企业接入多活的架构变化，下文的逻辑业务中心均简称为“单元”。
图1：企业接入多活的架构变化
2. 架构案例
2.1 异地双读
2.1.1 客户背景
国家某*机构的专有云大数据项目在云平台建设完成后，随着业务规模的不断增长，数据量级不断突破预期上线，客户的 ADB服务压力随之增大。在新业务逐个上线的过程中，客户开展实时数据分析常出现 ADB资源不足的情况，影响线上业务稳定性。
由于客户本身建立两个数据中心，前期因为 RT 问题，仅使用一个数据中心，另外一个并未投入使用。客户期望充分发挥两个中心的计算资源，基于 MSHA 容灾解决方案构建“异地双读”体系，以达到保障基于 ADB数据库的各类查询业务稳定性的目的。
2.1.2 方案落地
2.1.2.1 选取分区维度
基于实际业务流程，分析得到查询业务存在核心操作人员，操作人员登录系统后，进行基础业务操作行为，确定两种分片方式进行选型考虑，分别为“按分流标识分流”和“按功能URI分流”。
按分流标识分流
根据实际流量请求中携带的分流标识进行分流，是异地双活解决方案里的标准方案。业务按照自身实际情况选取合适的分流标识。
原则上选取尽可能分摊均衡的维度进行分流，便于后续动态灵活调控不同数据中心比例。比如：
- 以省份分流。x省、xx省分流到单元A，其他省分流到单元B，控制不同的省流量路由到不同的数据中心。
- 以用户分流。将一批有规律的用户分流到单元1，例如尾号为奇数的用户；其余用户分流到单元2。
按分流标识分流的优点为灵活可控，可以通过切流进行精细的流量调控。但也需要关注以下问题：
- 业务侧需要进行一定的功能改造，与多活相关的流量必须携带分流标识；
- 若单一维度的流量占流量大头，则此分流方式仍然做不到精细调控，比如按省分流的情况下某省的流量占总流量的大部分。
按功能 URI 分流
根据 URI 前缀进行分流，比如某域名的流量存在80个 URI ，将其中40个分流到单元A，另外40个分流到单元B。
按功能 URI 分流的优点是业务无需改造，仅需梳理出所有 URI 即可，但也存在以下问题：
- 可维护性差。URI 会跟随业务的开发迭代不断变化，后续无法长期保证 URI 分流配置的正确性。
- 切流变更复杂。每个域名每个 URI 的分流配置都不一样，切流需要变更到所有域名的配置，变更操作复杂。
- 若单一 URI 占所有流量的大部分，则此分流方式无法精细调控。
最终选型
经过跟客户深度沟通交流，由于当前业务操作均按省维度进行登录操作，改造成本小且不存在一个超大占比的省份，因此选择“按分流标识分流”的方式并按省作为分流标识。
2.1.2.2 方案计划
基于确定的分区维度，双活项目组指定详细的落地计划，大致分为前期准备、业务改造、测试实施、生产实施、技术交流等步骤环节。
图2：双活项目组指定详细的落地计划
2.1.2.3 架构演进
由于方案确定之时，客户两个云平台版本一个为 3.5.x，一个为 3.9.0，而相应的多活产品（MSHA）对云平台有版本要求，仅其中一个符合要求。考虑业务的高可用能力，我们确定分阶段进行，逐步让业务具备异地双读能力。
阶段一：仅在符合要求的云内部署多活产品（MSHA）
优势：
- 实施简单。应用改动小，仅需进行域名、URI、多活标识的订正，接入层接入多活管控体系即可。
- 个性灵活。多活产品支持 URI 精细化控制，可达到业务个性化诉求，部分功能点全部保留在原有的单元，其他功能点按省进行划分，分流到两个不通的单元。
- 快速恢复。灾难场景下，双活业务基于多活控制台（MSHA）可进行快速切流，达到恢复业务的目的。
- 逐步实施。日常场景下，双活业务具备小规模灰度放量的切流能力。
劣势：
- 高可用能力无。由于仅一个云平台部署多活产品，该云平台发生故障时，该云所有的业务均不可用，高可用能力一般。但，此风险，在没做双活的时候，本身也具备。
劣势解决方案：
- 快恢预案。日常场景维护灾难场景的应急预案，当出现劣势的灾难场景，执行预案，另外一朵正常云的业务VIP下挂在业务域名下。
图3：仅在符合要求的云内部署多活产品（MSHA）
阶段二：两朵云均部署多活产品（MSHA）
优势：在阶段一具备的优势前提下，规避了其劣势，保障了灾难场景时，多活产品自身高可用能力，进一步提高业务的抗风险能力。
图4：两朵云均部署多活产品（MSHA）
2.2 异地双读
2.2.1 客户背景
国家某*机构的在线业务云平台当前采用单中心单节点的部署模式，集中在同一栋楼中，核心在线业务存在“单点”运行的安全隐患：
- 自然灾害。业务所在的数据中心位于台风、洪涝等自然灾害高发地区，一旦因为自然灾害造成电力中断、机房损坏等情况，平台可能全面瘫痪。
- 网络风险。业务所在的数据中心目前电力采用双路供电，与下属的省系统基于联通、电信等链路进行通信，一旦出现如施工挖断线缆造成电力中断、网络中断等极端情况，平台服务将全面中断。
- 人为操作。人为操作失误或蓄意破坏导致平台故障或数据丢失，导致平台不可用。
云平台承载的在线业务系统直接关系到国计民生，影响重大，一旦出现数据篡改丢失和系统长期无法访问，后果难以承受。为落实各项安全整改建议，确保数据安全、万无一失，客户期望在原有的数据中心云平台之外，再建设“异地双活”第二中心，基于“异地双活”解决方案能力，提高核心业务的业务连续性。
2.2.2 方案落地
上文详细介绍分区维度和方案计划，此案例简要描述，重点在业务改造接入落地。
2.2.2.1 选取分区维度
核心业务进行双活建设的时候，客户梳理其核心的业务职能可分为终端用户和*机关两部分分流标识，二者均可以为唯一分流标识进行分流。
- 按终端用户标识分流。以用户 ID 为分流标识，由于此字段无法变更，保证了分流标识的确定性，实施成本小。
- 按*机关标识分流。相当于把用户聚类到*机关上，需要每月动态更新用户身上的标签。由于用户存在变更*机关的可能性，导致标签动态变更，延伸出变更禁写、数据保障、标签映射等一系列复杂问题，若存在部分老标签没更新成功，最严重会导致规则不一致及数据脏写，风险较高。
因此，最终选择“终端用户”为分流标识。
2.2.3 架构演进
图5：架构演进
基于双活解决方案，核心业务的部署模型分为如下三层。
2.2.3.1 接入层
- 用户访问域名，随机cname到某单元的子域名，再A记录到某单元的接入层负载均衡SLB上。
- 接入层提取流量请求中的路由参数，以确定流量的归属单元，如果请求中没有路由参数，则默认归属本单元。
- 接入层按照请求域名，或请求域名+URI前缀，以及请求的单元归属，将请求路由到正确单元的相应后端业务SLB。
2.2.3.2 应用层
- 服务RPC组件
基于阿里云 EDAS-HSF 框架和 CSB 云服务总线基础能力，多活产品新增多活插件用于处理单元封闭逻辑，支撑*机构核心分流业务流量单元内自封闭，数据最终一致的业务跨单元请求到中心单元。
- 消息组件
日常场景。保障“终端用户”流量在单元内发送的消息自闭环在单元内消费，其他流量产生的消息在中心单元被消费，兼容业务原有的消费体系。
切流场景。为保障消息不丢失，基于消息同步、重置位点、多活管控等核心能力使得用户流量到新单元后，原有单元堆积的消息不丢失，在新单元继续消费。
2.2.3.3 数据层
数据层设计遵循CAP理论的保AP模型，什么是 CAP，可以简单概括为：
- C（Consistency）:数据强一致
- A（Availability）：高可用性
- P（Partition Tolerance）：分区可容忍性
基于当前业务特性，高可用对于业务来说是至关重要的，同时随着数据量的增长，分区也难以避免，因此我们对于强一致做了让步，允许数据最终一致性而放弃强一致性。
在双活场景中，各个单元按照指定的规则承担不同比例的流量写入和读取，同时中心会通过 dts 同步部分数据到各个单元，使得单元具备快速的业务恢复能力，当某个单元出现任何异常不可用场景时，业务流量随时可以切换到其余冗余当前单元数据的正常单元，保障了业务可持续性和稳定性。
2.3 改造成本
方案实施期间，客户的改造成本集中在数据平面的代码依赖及流量染色、管控平面的双活资源接入管理上，概述如下图。
图6：客户改造成本简要介绍
3. 后记
本文案例中描述的异地多活产品-MSHA，2019 年基于阿里集团异地多活体系孵化而出，2020年先后在国家某*机构、某头部运营商新客服等客户生产落地，混合云及公有云产品均对外商业化中，有容灾高可用相关诉求的客户欢迎咨询和试用。
我们是阿里云智能全球技术服务-SRE团队，我们致力成为一个以技术为基础、面向服务、保障业务系统高可用的工程师团队；提供专业、体系化的SRE服务，帮助广大客户更好地使用云、基于云构建更加稳定可靠的业务系统，提升业务稳定性。我们期望能够分享更多帮助企业客户上云、用好云，让客户云上业务运行更加稳定可靠的技术，您可用钉钉扫描下方二维码，加入阿里云SRE技术学院钉钉圈子，和更多云上人交流关于云平台的那些事。