异地多活相对于异地热备，最大不同点在于应用在不同地域都承载流量，从业务流量调度，数据同步以及业务性能等方面技术复杂度会大幅度的提升。同时业务异地多活有一个前提，就是业务支持单元化部署，这里对存量有历史技术债业务也存在非常大的挑战。因此本篇幅讨论异地多活前提是，业务已经具备单元化部署的能力。

对于业务异地多活，基于成本以及业务复杂性实现方案有很多，当前主要介绍以下三种方案。

方案一：业务单元化部署

业务多地域单元化部署，入口流量借助于DNS解析线路来调度。当发生极端情况下，对应地域的业务恢复依赖于备份来恢复，RTO时间依赖于备份方案。该方案整体复杂度偏低，资源成本低，不涉及数据同步以及一致性，极端情况下，只能保障部分业务实时提供服务。具体技术架构如下：

在本方案中，不涉及备份技术方案，详情请参考之前容灾系列的备份方案。方案要点说明如下：

1）业务调度：目前通过DNS统一调度，调度路线设置通过地区或者运营商为区分。

2）业务部署：业务多地域单元化部署，同一地域业务同城双活部署。接入层CLB具备跨AZ主备能力；应用层采用多可用区部署建议采用容器运行时；数据层采用一端写就近读的跨AZ高可用实例。

3）容灾成本：业务备份的资源成本，具体可参考之前容灾文章系列。

4）业务恢复：可用区粒度的极端故障，基于云平台同城双活架构可实现RTO秒级切换恢复业务。对于地域粒度极端故障，如果广州地域整体异常，通过异地备份方式来恢复业务；北京地域的业务不受影响，正常访问。

方案二：业务单元化部署+数据单向同步

业务多地域单元化部署，中心地域具有全局数据，通过数据单向同步实现，如果分中心的地域出现极端故障，可以通过快速扩容和切换DNS线路的方式恢复业务，提升RTO指标；如果中心地域出现故障，通过备份方式来进行恢复。详细技术架构图如下：

在本方案中，不涉及备份技术和AS弹性扩容的技术细节，详情请参考之前容灾系列的备份方案。方案要点说明如下：

1）业务调度：同方案一保持一致。

2）业务部署：相对于方案一，新增了数据单向同步，北京地域为中心地域，具有全部业务数据；而广州地域为分中心，只有广州业务数据。

3）资源成本：相对于方案一，新增数据单向同步流量成本，由于北京地域数据库为全局业务数据库，规格实例成本相对于方案一会升级增加成本。

4）业务恢复：可用区粒度极端故障，和方案一保持一致；地域粒度极端故障，如果是主中心的故障和方案一一致，通过备份方式进行恢复，例如北京地域出现极端情况；如果是分中心故障，例如广州地域不可用，通过DNS修改解析线路到北京，RTO秒级别完成业务切换恢复。

方案三：业务单元化部署+数据双向同步

业务多地域单元化部署，不同地域数据库进行双向同步，对于地域粒度极端故障，实现业务秒级切换，提升RTO性能指标。详细技术架构如下：

在本方案中，不涉及备份技术和AS弹性扩容的技术细节，详情请参考之前容灾系列的备份方案。方案要点说明如下：

1）业务调度：于方案二保持一致

1）业务部署：相对于方案二，增加了数据双向同步，各个地域中心均具有全局数据能力，提升容灾的RTO指标，同时不同业务数据要有唯一主键来保证数据一致性。

目前站长素材网平台已经支持双向同步，参考https://cloud.tencent.com/document/product/571/60956

2）资源成本：相对于方案二，由于地域不同数据库相互备份，减少备份资源成本，同时会增加地域间的数据同步带宽；数据库存储规格相对于方案二会增加成本。

3）业务恢复：相对于方案二，可用区粒度极端故障恢复保持一致，对于地域粒度极端故障，通过DNS切换解析线路进行恢复，提升RTO。

方案小结：方案横向对比

1）方案容灾能力对比(业务支持秒级切换，业务恢复为分钟级别)

2）方案综合能力对比