1、概念
异地多活顾名思义就是在不同的城市部署多个数据中心。
多活一方面是多数据中心之间地位均等，正常模式下协同工作，并行为业务访问提供服务。
另一方面是在一个数据中心发生故障的情况下，其它数据中心可以正常运行并对关键业务或者全部业务实现接管。
2、业务类型的划分
而要达到并行服务的目标，其关键在于如何实现业务调用在业务单元内封闭，避免需要跨地域调用。服务调用根据业务标记和业务类型来进行正确的选址和调用保护。只有服务所在单元和业务标记归属单元一致，服务才能正常发起调用，我们把这一类称之为单元业务（UnitService）。
除了单元业务，还有一些业务是要求数据强一致的，例如库存服务，这种服务我们称之为全局业务（GlobalService）。
除了上述2种业务类型以外，我们额外增加了一种只读业务（ReadService）用于提供只读查询服务，对于这种业务，可以通过简单数据复制进行性能的线性扩展，减轻单元业务和全局业务的压力，例如字典服务、商品信息等。
3、业务系统改造规划
下面我们以电商业务为例，包括导购、购物车、交易等业务场景，单地域架构如下：
首先我们分析业务类型如下：
- 库存服务：业务强一致，设计为全局业务，部署到北京主数据中心。
- 购物车应用、下单应用：可以以用户ID为业务标记进行划分，设计为单元业务，UserID 0~2999路由到广州数据中心、3000~5999路由到上海数据中心、6000~9999路由到北京数据中心。
- 商品应用：只读，设计为只读业务，每个地域各配置一份。
然后将上述应用按照规范接入异地多活管控中心，多个数据中心的数据库两两间配置双向同步，并进行多地域部署：
最后，将MSAP、消息等框架组件切换到多活，然后按标准的日常、预发、线上流程进行上线，完成异地多活改造。
4、主要功能
4.1、业务调度
按上述业务架构的设计，一个下单请求可能要经过以下步骤：
- DNS分发
- 接入层路由纠错
- 访问购物车应用，获取商品列表
- 访问下单应用
- 清空购物车
- 获取商品信息
- 库存扣减
- 提交订单
其中，用户接入部分可以按固定规则，也可以根据用户所属地域就近访问。
用户下单请求提交后，对于购物车应用、下单应用在指定地域完成业务流程中的大多数操作封闭在本地数据中心，而对于库存业务则需要路由到全局业务数据中心去完成。
4.2、故障切换
一旦用户所属的数据中心发生故障，则由异地多活管控中心发起流量切换，下发新的流量规则，将故障的数据中心的业务转移到其它正常的数据中心中。
切换的过程中，关键点是要避免数据库双写冲突，只要在进行流量切换的过程中打开数据库的写保护，等待数据库同步完成、流量切换完成，再解除数据库写保护即可。
4.3、数据同步
对于全局业务来说，数据只有一份，所以不存在数据同步问题。
对于单元业务来说，各个数据中心处理的业务数据需要按某个业务标记例如用户ID进行隔离，所以也不存在数据不一致的问题。
对于只读业务数据，例如商品信息，通过多个数据中心之间的双向同步完成最终一致性复制即可，用户或者应用可以就近访问获取信息。
