弹性计算技术公开课——CloudOps云上运维季圆满结束了，阿里云弹性计算技术专家邓青琳在本次系列课程中带来了《云上跨可用区容灾和异地多活》主题课程，从系统容灾、主流容灾架构、ECS团队在容灾上的时间、云上容灾建设最佳实践等方面为大家进行了详细的课程分享。
以下是他的课程内容整理，供各位开发者学习：
大家好，我是邓青琳，来自阿里云弹性计算团队，今天很荣幸和大家一起讨论下云上跨可用区容灾和异地多活方面的最佳实践。
主要分为四个部分：
第一部分，进行系统容灾的必要性；第二部分，业界主流的容灾架构介绍及对比；第三部分，介绍ECS团队在容灾方面的具体实践经验；第四部分，在云上进行同城双活和异地双活的容灾能力建设。
1. 系统容灾
1） 常见故障类型
提到系统容灾，便不得不提到故障，因为故障是导致应用不可用性的重要因素。进行系统容灾的目的在于提升系统的可用性。
常见的故障类型，包括变更（如配置项变更、开关变更、日常应用程序的发布变更等，这些变更容易导致各种各样的故障）、硬件层面故障（如应用程序部署的物理机故障，机房中交换机、路由器等网络设备故障）、市政方面的断电断网的故障（如光纤中断、电网故障）以及自然灾害层面导致的故障（如地震、台风、洪水）。
这些故障发生的概率依次降低，但低概率不代表低影响。往往像市政类的断电断网，以及自然灾害类的地震台风洪水对业务的影响非常致命，如果系统没有进行相应的容灾能力建设，造成的损失往往是不可挽回的。
如下图左侧，2021年3月10日，欧洲最大的云服务公司OVH法国集团着火，导致数据中心被完全烧毁，350万个网站下线，部分客户数据完全丢失，且无法恢复。Rust 旗下的游戏工作室证实其数据在火灾中全部丢失，即便数据中心能够重新上线，也无法对数据进行恢复。OVH创始人兼董事长表示，他建议客户启动自己的容灾的恢复计划，即使应用部署在云上，也需要进行一定的容灾能力建设，避免类似市政断电断网及自然灾害带来的故障。
2） 常见容灾级别
首先，同城级别的容灾，又称为跨可用区容灾，包括同城灾备、同城双活以及同城多活；第二，异地级别的容灾，又成为快微镜或者跨地域容灾，常见的异地容灾包括异地双读、异地双活以及异地多活；第三，其他，如将同城容灾和异地容灾组合的两地三中心，两地三活，以及淘宝天猫等在进行异地多活容灾建设时提出的单元化概念，这些内容在后面的介绍中会进行详细地展开讲解。
在进行容灾能力的建设时，需要多种不同的容灾方案。而采用何种方案取决于所处的业务阶段、相应的业务特征，以及可在容灾建设中投入的资源情况，综合考虑选择当下最适合自身的容灾架构，且没有哪一种架构可以解决所有场景的所有问题。
2. 主流容灾架构
1） 容灾能力评价指标
在介绍容灾架构之前，先介绍两个在容灾的方面业界较有影响力的评价指标。
RPO，是指系统一旦出现故障，允许数据丢失的程度，而对于越重要的系统，要求数据丢失的程度越低，RPO越小。若是数据备份，一般应用一天备份一次，对于较为核心的应用则要求每小时备份一次；若是数据同步，RPO越小，则要求数据同步的延迟也要越低。而低延迟会对生产环境，包括网络带来更高的压力，同样也会带来更高的建设成本。
RTO，是指系统出现故障之后，能够允许故障恢复时间的长度。对于越重要的应用，一般要求RTO越小，以尽量降低业务的损失。
右侧图是国家信息委员会定义的信息系统展览恢复的规范，该规范将灾难恢复的能力定义成了1-6六个等级，随着等级越高，对RPO和RTO的要求也越高。以最高的等级6为例，其要求的RTO是数分钟，即应用出现故障时要在分钟级别进行灾难的恢复，RPO等于零，这意味着数据不允许丢失，这是一个较高的标准。
2）主流容灾架构对比
(1) 同城灾备
如左侧架构图所示，它具有以下几个特征：
∙ 主备两个数据中心位于相同的城市或地理区域，一般指两个数据中心之间的距离小于100千米，即可实现非常低延迟的数据复制。在该架构中，主要实现的是单向同步。
∙ 主数据中心最上层的流量占比是100%，备数据中心最上层的流量占比是0%，这意味着，平时主要的业务流量通过主数据中心承担，备数据中心主要用于数据备份的存储以及提供服务的冗余，而不提供业务流量的处理能力。
∙ 该架构部署较为简单，对业务的侵入也较小，基本无需对业务做较大的改造。
其挑战在于：
第一，由于主备数据中心位于相同的城市，则面对一些较大规模的灾害时，如洪水、地震，会同时影响两个数据中心；
第二，由于备数据中心平时不提供服务，则会导致较大的资源浪费，同时，若主数据中心出现故障，要将服务流量切到备数据中心，这个过程中有一定的可靠性风险，如备数据中心的软件版本、操作系统版本、内核的参数可能会与主数据中心不一致，带来服务的稳定性隐患。
这套架构适用于RTO满足分钟级别或小时级别，这主要是热备和冷备的区别，即在架构中，应用服务平时是否处于运行状态。如果处于运行状态的，则是热备，反之，则属于冷备。在冷备架构进行流量切换时，需要将备数据中心的所有应用先进行服务的拉起，耗时更长。在数据库层面，要进行主备的切换，其最上层的业务流量要进行DNS切换，将流量从主数据中心切到备数据中心。
对应的应用，一般建议把一些风险较小的应用，如一些中小企业的普通类型的应用，采用这套容灾架构。
（2）同城双活
如左侧架构图所示：
其与同城灾备有一定区别：
第一，主备数据中心都接收业务流量；
第二，备数据中心的应用进行了读写分离，写操作会到达主数据中心，读操作会到达备数据中心。
综上，其特征有三：
其一，两个数据中心仍在同城市运行的，即距离是小于100千米，两个数据中心之间的通信时长小于2ms；
其二，主备数据中心都处于活动状态，都对外提供服务，因此最上层一般就需要添加负债均衡，且最下层采用数据单向同步机制；
其三，在业务层面，需要对业务进行改造，主要指业务应用的读写分离改造。
其也带来了一定的挑战：
第一，主备数据中心仍位于相同的城市，在面对较大的灾难时，容灾效果会受一定影响；
第二，这套容灾架构会给系统带来一定的复杂度，包括前面提到的应用层面要进行读写分离改造，最上层需要有负债均衡能力，最下层进行数据的同步，以及相应的故障切换的能力建设。
其适应的场景包括：第一，RTO可以实现秒级或分钟级，这取决于最上层的流量切换是否具备自动探活能力，在数据层面，进行主备数据库的切换，最上层如果不具备自动探火，还可以进行DNS切换；第二，其适用于在线金融交易应用、互联网应用以及社交媒体应用，这些应用往往需要高可用以及负债均衡。
（3）异地双活
如左侧架构图所示，它具有以下几个特征：
第一，两个数据中心分布在不同的城市，满足“异地”的定义，一般指两个数据中心之间的距离大于1000千米，约为北京和上海之间直线距离，一般认为它可以避免市政级别的故障或自然灾害层面的故障；
第二，两个数据中心都处于活动状态，对外提供服务，由于数据中心距离较远，故使用广域网进行数据的同步，且是双向同步状态，从图中可以看到，两个数据中心都叫做主数据中心，在异地多活或异地双活架构中，每个数据中心都是主数据中心，且使用双向同步确保数据的一致性，这里的数据包括数据库的数据以及一些有状态的中间件数据；
第三，在最上层要在流量入口部署路由层，而路由服务主要的能力是使得相同特征的流量尽量在单个数据内闭环的处理，如可以按业务类型、用户ID或请求地理位置进行分类。一般会把接入层的路由及业务进行单元化改造。
若按业务类型分类，则是指系统有订单及库存服务，其中订单服务部署在北京，库存服务部署在上海，则所有订单的请求都要路由到北京，所有的库存请求都要路由到上海，否则就无法找到对应的业务服务器处理。若按用户ID分类，若用户A要路由到北京，则用户A所有的请求都要路由到北京，用户B要路由到上海，则用户B所有的请求都要路由到上海。若按地理位置分类，假设请求来自上海，则路由到上海地域的服务器，若请求来自北京，那则路由到北京的服务器。
做路由层的改造，核心原因在于两个数据中心之间的距离较远，其数据同步的延迟较大。当同一用户处理相同的数据时，发起了两个请求，如果第一个请求路由到北京，第二个请求路由到上海，由于两个请求发起的时间间隔很短，因此如果路由到不同的数据中心就可能会导致数据的紊乱，因为数据中心之间的数据同步本身就有一定的延迟，因此，我们要求相同业务特征的流量尽量在同一数据中心闭环处理，以避免数据同步延时带来问题。
这套容灾架构也会带来一些挑战，第一，由于数据中心之间距离较远，在使用广域网通信时会有一定的网络延迟；第二，这套容灾架构会使得应用系统变得更加复杂，包括进行最上层业务路由的划分，内部进行业务的单元化改造，以及数据的双向同步等措施。
其适用于RTO为秒级或分钟级，这取决于最擅长的路由服务是否可以实现自动探活，或者进行人工的路由切换。该架构适用的应用包括一些较为关键的金融系统、政府类型的应用以及云服务提供商等，即一类在面对大规模灾难时仍能够持续提供服务的应用。
（3）异地多活
与异地双活类似，差别在于数据中心变得更多了，各数据中心之间继续采用双向同步的数据链路，随着数据中心的增多，数据双向同步的拓普变得越来越复杂。
其特征包括：
多个数据中心的异地多火指的是多个数据中心部署在不同的城市，各城市之间的直线距离大于1000千米的；
第一，多个数据中心依然都处于活跃状态，同时对外提供服务，数据中心之间使用广域网进行数据的双向同步以确保数据的一致性，这里的数据同样包括数据库的数据以及一些有状态的中间件数据；
第三，最上层依然需要部署路由层，把相同特征的流量尽量在单个数据中心内闭环处理。
其带来的挑战包括，第一，配置和管理多个一体数据中心的复杂度非常高，三个数据中心相较于两个数据中心在数据的同步链路复杂度已经增加不少，若是十个数据中心，复杂度会更高，这要求我们需要有强大的网络和资源管理能力；第二，随着数据中心的增多，确保多个数据中心之间数据的一致性也是非常大的挑战，包括数据的同步、数据的冲突、数据的复制等问题。
这套架构依然适用于RTO秒级或分钟级，这取决于路由服务能否自动探活或进行人工切换。它适用于需要在全球范围内提供高可用、高容灾和高负债均衡的应用，如一些跨国企业或云服务提供商的基础服务。
更多精彩内容，欢迎观看：
带你读《云上自动化运维宝典》——一文详解云上跨可用区容灾解决方案和异地多活能力建设最佳案例（2）：https://developer.aliyun.com/article/1405311
