简介： 异地多活之企业架构案例
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 年先后在国家某政府机构、某头部运营商新客服等客户生产落地，混合云及私有云产品均对外商业化中，有容灾高可用相干诉求的客户欢送征询和试用。
原文链接
本文为阿里云原创内容，未经容许不得转载。