1 什么是异地多活？
异地多活，英文Multi-Site High Availability，顾名思义就是分布在异地多个站点同时对外提供服务。与传统灾备最主要的区别是“多活”里所有站点都是同时在对外提供服务的，具体有以下几点不同：
- 传统的灾备中心平时不提供服务，关键时刻无法确定切换到灾备中心是否可以切换成功。
- 传统的灾备中心平时不提供服务，整个灾备资源会处于浪费状态，成本比较高。
- 传统的灾备中心平时不提供服务，所以平时提供服务的数据中心还停留在单地域，当业务体量大到一定程度时，这种模式无法解决单地域资源瓶颈的问题。
因为通过传统的灾备手段无法解决上述问题，阿里巴巴经过多年研究，成功在2013年的双十一实现了“丝般柔顺”的用户体验后，“异地多活”这项基础技术首次在业界亮相。
2 “多活”和“双活”有什么区别？
单从字面上看，“多活”和“双活”的区别仅是同时提供服务的站点数量的区别。一个是“多个”站点同时提供服务，一个是“两个”站点同时提供服务。但即使都是“双活”，也会因为前面加了“同城”还是“异地”而有着本质的区别。如果是“异地双活”，就是和“异地多活”仅存在站点数量上的差别。但如果是同城双活，在阿里内部，采用的是不同的技术。阿里的同城双活，整个模式应用层是双活的，两边的业务都有，用户访问过去都会处理请求，一旦进入某个数据中心，流量交付优先在本数据中心封装。但存储层都是主备或者本身的高可用模式的，主备模式即主在A机房，备在B机房，不会同时用，严格意义上来讲，这是伪双活，因为数据不是真正意义的双活。但即使是这样的双活，阿里巴巴内部也是经历了很长一段时间的摸索才实现，双活其实也是一样的，如果真正做到就意味着同城任何一个机房出问题都要可以高效可靠地切换到另外一个机房，如果没有经过很多次真正切换的话，没有人敢说是一定能成功的。这里不只包含数据库主备的问题，还涉及到应用的业务依赖梳理、众多中间件层面的服务路由、调用和集群冗余的问题。
一句话总结，就是“异地双活”和“异地多活”仅是数据中心数量的差别，但“同城双活”则是完全不同的技术。采用哪一种，完全取决自己的多个数据分布在同城还是异地，以及以后的业务扩展方向问题。
3 多活的设计误区
3.1 实时异地多活
异地多活本质上是通过异地的数据冗余，来保证在极端异常的情况下业务也能够正常提供给用户，因此数据同步是异地多活设计方案的核心。但由于目前的技术还无法突破数据传输与物理距离解耦合，也就是说两个异地数据中心之间一定存在一定程度的延时，如果业务对实时性要求极高，那就无法实现异地多活。
3.2 所有用户异地多活
同样是由于物理距离造成的数据传输的延迟，数据只能做到最终一致，在一些极端情况下，部分用户的数据无法及时同步到新切换到的中心，这时，这部分用户的业务会受到一定程度的影响。
3.3 所有业务异地多活
异地多活效果看起来很诱人，但如果不假思索贪大求全地要求所有业务都实现异地多活的话，很可能什么也做不成。原因是异地多活是有成本的，根据业务类型有不太一样的开发和运维成本，但如果全做加之对业务梳理不到位，会造成整个工期不可控，即使完成，上线后的效果也需多重验证。阿里第一次做异地多活也只是选取了与“买家”下订单相关的电商业务做的多活，然后根据业务需求，逐渐有新业务改造上线，到了今天的规模。
3.4 通用的异地多活
异地多活的实现根据业务类型的不同也有一定程度的差异，为了让业务尽量少的做改动，尽可能把这种能力都封装在中间件和基础工具中，但即便如此，也无法保证这些能覆盖所有的业务类型。遇到特殊的业务类型或者用户自己实现的基础组件，仍然需要根据具体的业务特点制定新的多活方案。
4 异地多活的适用场景
异地多活本质上就是通过自上而下的全域流量隔离来解决数据同步延时无法突破物理限制的问题，但异地多活也不是银弹，且不同的场景来做异地多活的成本也不一样，不一定适用于所有场景。下面把用户的业务按数据维度分成三种类型来看异地多活的适用场景：
4.1 读多写少型业务
- 业务应用场景：典型的业务场景就是资讯、导购类的服务，比如商品浏览、新闻资讯...
- 数据特点：典型的数据特点就是读多写少，用户以浏览为主，核心业务场景只读，单元里部署的都是只读业务
- 多活接入成本：接入成本低，只需要用户在请求里标记上分流的标识即可
4.2 流水单据型业务
- 业务应用场景：典型的业务场景就是电商交易、帐单流水类服务，比如用户的订单、用户的通话记录...
- 数据特点：典型的数据特点就是数据可按照一定的维度进行分片且可以接受最终一致
- 多活接入成本：接入成本略高，用户需要梳理业务，理出单元内部署的核心业务及其数据，对于单元依赖且无法拆分的业务采用读写分离，然后按照多活接入规范重点对服务层及数据层进行相应改造即可
4.3 状态依赖型业务
- 业务应用场景：典型的业务场景就是银行账务，比如A、B在某银行均有帐户，A、B数据分片位于不同的数据中心，A和B之间会有转账行为
- 数据特点：典型的数据特点就是数据有状态依赖且无法最终一致，数据还存在跨数据中心的交互
- 多活接入成本：接入成本高
5 异地多活的设计原则
意识到上面这些思维误区后，我们重新思考异地多活，确定一些设计原则：
- 选取分区维度：选择一个数据维度来做数据切片，进而实现业务可以分开部署在不同的数据中心
- 确定改造范围：选择与上次选取的数据维度相关的业务范围来做多活
- 单元封闭：尽量让调用发生在本单元，尽量避免跨数据中心的调用，一方面为了用户体验，本地调用RT更短，另一方面为了稳定性，防止一个数据中心出了问题，其它数据中心受影响
- 无法接受最终一致的数据要进行单点写：对于一些实时性要求极高，无法接受最终一致的数据只能进行单点写
6 异地多活的价值
虽然最初创造异地多活是为了解决容量和容灾的问题，但异地多活发展到今天其价值已远不止这些了，更大的价值是为阿里新技术演进提供试验田，甚至可以驱动商业上的一些玩法。
6.1 解决了容灾的问题，提升了业务的连续性
现实运行过程中，容灾可不只是地震、挖光纤这些低概率事件，同样还有人为原因等高概率的事件，这些通过异地多活均可以解决。以下罗列一些常见的场景：
- 人为操作失误：常见的有配置错误、应用发布失败等等
- 硬件故障：常见的有网络设备出故障，导致机房或集群内多台服务器受影响
- 网络攻击：DDoS等网络攻击
- 断网/断电：支付宝光缆被挖断
- 自然灾害：青云雷击导致机房电力故障
有了异地多活，以上这些场景出现时，秉承“先恢复，再定位”的原则，可以有效提升业务的连续性。某互联网公司通过自己的实践验证取得了非常不错的成绩，可做到让“业务恢复时间”和“故障恢复时间”解耦合。
6.2 解决了容量异地扩展的问题
有了异地多活，当机房或者地域容量遇到限制的时候，可以在其它机房或者其它地域快速扩建业务单元，实现快速水平扩容的目的。
图1：业务多单元化
6.3 为新技术演进提供了试验田
异地多活本质上是提供了自上而下的一种流量隔离能力，基于这种能力，我们完全可以做到单元之间的隔离，进而完成一个技术上需要的场景：
- 基础设施的升级
- 大的技术架构升级
- 新技术验证
阿里巴巴每年进行大促的技术大步演进但又风险可控，完全就是基于这种能力来实现的，每年有多个重大的技术演进，演进过程中难免遇到问题，但却从未造成大的影响。
6.4 驱动商业上产品创新玩法
同样基于这种流量隔离能力，商业上也可以产生一些新的玩法：
- 把VIP和普通用户分开到不同的集群
- 把真实用户和爬虫分开
- 新旧机器分成不同的物理集群，做流量隔离，进而做分级别的服务
7 异地多活（MSHA）产品介绍
7.1 产品形态
图2：多活管控平台架构图
异地多活是一个架构属性比较重的产品，其整个产品由管控+组件组成，同时需要和其它产品结合来完成整个异地多活。一个完整的异地多活应该包括如下组成部分：
A. 控制台
控制台提供多活配置及运维闭环的功能：
接入层、应用层、数据层的各层接入多活的初始化操作和日常运维。
发生灾难场景的切流操作。
多活场景下的数据监控。
多活切分规则的展示及查看。
B. 接入层
目前这层主要是一个基于Tengine的多活组件，我们称之为MSFE。
MSFE需要多单元部署，它能承接所有的单元前端流量，并按照路由规则路由到正确单元的后端应用。多活控制台提供MSFE集群新建、扩容、缩容等常规运维能力。
C. 应用层
应用层主要包括基于EDAS的RPC服务组件和基于MQ的消息队列组件：
EDAS：EDAS的新增多活参数及处理逻辑支撑多活RPC能力，接入时业务需声明RPC-Provider的多活属性及升级EDAS容器版本。
CSB：通过级联CSB组件实现单元间的RPC服务互通，并在MSHA管控台进行发布操作。
ONS：基于ONS的同步能力和多活处理逻辑支持多活MQ能力，接入时需要在多活管控开启Producer和Consumer的单元属性及同步链路配置。
D. 数据层
目前这层主要是包括一个客户端和一个基于DRDS的多活组件，两者共同配合完成对多活数据层的管控：
多活数据Driver：这是一个基于JDBC标准Driver进行二次封装的Driver，主要是用于传递一些标准的元信息给DRDS，同时封装了一些本地处理的多活逻辑。
DRDS多活组件：该组件需要安装在DRDS的Server端，主要是与多活的Drvier共同配合完成异地多活的逻辑处理。
除了上述多活数据层的组件外，要想完成异地多活，还需要依赖数据同步相关的云产品：
DTS：基于DTS的单/双向同步能力，与多活管控共同配合完成异地多活的数据同步控制逻辑处理。
7.2 产品特点
A. 一站式多活管控
一站式管控主要体现在下述两个方面：
- 横向从单元上线，到单元日常（监控、运维、切流），再到单元下线的全生命周期管理。
- 纵向从单元流量入口，到服务化调用，异步化消息，再到数据入库的全方位管控。
B. 单元化类型*扩展
单元化类型routeType，描述的是业务类型。以电商场景为例，有买家业务、商家业务等。淘宝的交易单元化是以买家业务做的单元化，分流规则是买家id，也就是说买家的流量能分流到各个单元，而商家却没有多活。单元化类型*扩展，能同时支持买家与商家业务的多活，赋能用户，使用户在业务扩展上拥有更大的灵活性。
C. 运维全自动化
- 运维全自动化，主要体现在接入层、服务层、数据层的变更操作自动化以及接入层集群运维的全自动化。
- 在接入层集群运维上，主要包含创建集群、扩缩容服务器、扩缩容SLB等，提供一键式运维变更方案，完全无需登录服务器。
D. 流量调度高可用
- 由于流量分发路由规则在各个机器上，因此其会受如下因素影响：
网络分发开销。
配置中心性能。
多个有序规则下发，乱序会导致流量执行逻辑错乱。
- MSHA与上述影响点解耦：
仅依赖ntp进行实际规则执行，弱化了网络和配置中心的时效性依赖，同时存在对ntp各机器不一致的容错时间，保证在切流期间，切流用户数据强一致的前提下规则执行的最终一致。
多个有序规则合并为一个规则，去除对有序的依赖。
当ntp灾难不可用时，启用容灾及时规则下发状态，即不依赖ntp，此时依赖配置中心下发后，禁写保切流用户强一致，而后生效。
8 服务案例
在阿里云异地多活的服务项目中，较为典型的有饿了么与国家某部委的专有云项目。其中饿了么的业务场景、架构与阿里均有较大差异，在阿里的支持下用三个月走完阿里三年的多活改造之路，服务可拓展至多个机房，并且能够应对整个机房级别的故障。国家某部委的专有云平台自上线运行以来注册用户过亿，平日在线用户数超千万，日均交易量过千万，业务系统稳定性至关重要。2019年客户在广东、北京两个中心分别搭建混合云平台，整体解决方案实现两个中心联机业务“一写双读”，共同对外提供服务，大数据离线业务采用“异地容灾”技术进行业务连续性支撑，整个解决方案借助大量阿里云先进的技术及产品，为项目提供了业务双活和大数据容灾两个重要的容灾能力。
作者：谢吉宝
阿里云智能GTS-SRE团队高级技术专家
阿里云智能GTS-SRE团队高级技术专家，阿里云智能架构组成员，2010年加入阿里，10余年技术研发和系统架构经验，见证了阿里巴巴的高可用产品体系从1.0到3.0的整个发展历程，目前主要负责阿里容灾和高可用体系的建设及商业化。
作者：钟熙耿
阿里云智能GTS-SRE团队技术专家
阿里云智能GTS-SRE团队技术专家，2017年加入阿里，专注于容灾高可用领域探索，持续推动集团多活容灾（同城/异地）演进，目前主要负责容灾商业化体系和集团容灾架构工作。
作者：缪锐
阿里云智能GTS-SRE团队技术专家
阿里云智能GTS-SRE团队技术专家，2014年加入阿里，多年DevOps及系统高可用架构经验，深度参与了阿里巴巴的DevOps转型与异地多活容灾架构的发展，目前主要负责阿里服务度量体系以及容灾商业化。
我们是阿里云智能全球技术服务-SRE团队，我们致力成为一个以技术为基础、面向服务、保障业务系统高可用的工程师团队；提供专业、体系化的SRE服务，帮助广大客户更好地使用云、基于云构建更加稳定可靠的业务系统，提升业务稳定性。我们期望能够分享更多帮助企业客户上云、用好云，让客户云上业务运行更加稳定可靠的技术，您可用钉钉扫描下方二维码，加入阿里云SRE技术学院钉钉圈子，和更多云上人交流关于云平台的那些事。