1. 系统容灾
1.1 常见故障类型
提到系统容灾，便不得不提到故障，因为故障是导致应用不可用性的重要因素。进行系统容灾的目的在于提升系统的可用性。常见的故障类型，包括变更（如配置项变更、开关变更、日常应用程序的发布变更等，这些变更容易导致各种各样的故障）、硬件层面故障（如应用程序部署的物理机故障，机房中交换机、路由器等网络设备故障）、市政方面的断电断网的故障（如光纤中断、电网故障）以及自然灾害层面导致的故障（如地震、台风、洪水）。这些故障发生的概率依次降低，但低概率不代表低影响。往往像市政类的断电断网，以及自然灾害类的地震台风洪水对业务的影响非常致命，如果系统没有进行相应的容灾能力建设，造成的损失往往是不可挽回的。
如下图左侧，2021年3月10日，欧洲最大的云服务公司OVH法国集团着火，导致数据中心被完全烧毁，350万个网站下线，部分客户数据完全丢失，且无法恢复。Rust 旗下的游戏工作室证实其数据在火灾中全部丢失，即便数据中心能够重新上线，也无法对数据进行恢复。OVH创始人兼董事长表示，他建议客户启动自己的容灾的恢复计划，即使应用部署在云上，也需要进行一定的容灾能力建设，避免类似市政断电断网及自然灾害带来的故障。
2.2 常见容灾级别
首先，同城级别的容灾，又称为跨可用区容灾，包括同城灾备、同城双活以及同城多活；第二，异地级别的容灾，又成为快微镜或者跨地域容灾，常见的异地容灾包括异地双读、异地双活以及异地多活；第三，其他，如将同城容灾和异地容灾组合的两地三中心，两地三活，以及淘宝天猫等在进行异地多活容灾建设时提出的单元化概念，这些内容在后面的介绍中会进行详细地展开讲解。
在进行容灾能力的建设时，需要多种不同的容灾方案。而采用何种方案取决于所处的业务阶段、相应的业务特征，以及可在容灾建设中投入的资源情况，综合考虑选择当下最适合自身的容灾架构，且没有哪一种架构可以解决所有场景的所有问题。
2. 主流容灾架构
2.1 容灾能力评价指标
在介绍容灾架构之前，先介绍两个在容灾的方面业界较有影响力的评价指标。
RPO，是指系统一旦出现故障，允许数据丢失的程度，而对于越重要的系统，要求数据丢失的程度越低，RPO越小。若是数据备份，一般应用一天备份一次，对于较为核心的应用则要求每小时备份一次；若是数据同步，RPO越小，则要求数据同步的延迟也要越低。而低延迟会对生产环境，包括网络带来更高的压力，同样也会带来更高的建设成本。
RTO，是指系统出现故障之后，能够允许故障恢复时间的长度。对于越重要的应用，一般要求RTO越小，以尽量降低业务的损失。
右侧图是国家信息委员会定义的信息系统展览恢复的规范，该规范将灾难恢复的能力定义成了1-6六个等级，随着等级越高，对RPO和RTO的要求也越高。以最高的等级6为例，其要求的RTO是数分钟，即应用出现故障时要在分钟级别进行灾难的恢复，RPO等于零，这意味着数据不允许丢失，这是一个较高的标准。
2.2 主流容灾架构对比
2.2.1 同城灾备
如左侧架构图所示，它具有以下几个特征：
- 主备两个数据中心位于相同的城市或地理区域，一般指两个数据中心之间的距离小于100千米，即可实现非常低延迟的数据复制。在该架构中，主要实现的是单向同步。
- 主数据中心最上层的流量占比是100%，备数据中心最上层的流量占比是0%，这意味着，平时主要的业务流量通过主数据中心承担，备数据中心主要用于数据备份的存储以及提供服务的冗余，而不提供业务流量的处理能力。
- 该架构部署较为简单，对业务的侵入也较小，基本无需对业务做较大的改造。
其挑战在于，第一，由于主备数据中心位于相同的城市，则面对一些较大规模的灾害时，如洪水、地震，会同时影响两个数据中心；第二，由于备数据中心平时不提供服务，则会导致较大的资源浪费，同时，若主数据中心出现故障，要将服务流量切到备数据中心，这个过程中有一定的可靠性风险，如备数据中心的软件版本、操作系统版本、内核的参数可能会与主数据中心不一致，带来服务的稳定性隐患。
这套架构适用于RTO满足分钟级别或小时级别，这主要是热备和冷备的区别，即在架构中，应用服务平时是否处于运行状态。如果处于运行状态的，则是热备，反之，则属于冷备。在冷备架构进行流量切换时，需要将备数据中心的所有应用先进行服务的拉起，耗时更长。在数据库层面，要进行主备的切换，其最上层的业务流量要进行DNS切换，将流量从主数据中心切到备数据中心。
对应的应用，一般建议把一些风险较小的应用，如一些中小企业的普通类型的应用，采用这套容灾架构。
2.2.2 同城双活
如左侧架构图所示：
其与同城灾备有一定区别，第一，主备数据中心都接收业务流量；第二，备数据中心的应用进行了读写分离，写操作会到达主数据中心，读操作会到达备数据中心。综上，其特征有三，其一，两个数据中心仍在同城市运行的，即距离是小于100千米，两个数据中心之间的通信时长小于2ms；其二，主备数据中心都处于活动状态，都对外提供服务，因此最上层一般就需要添加负债均衡，且最下层采用数据单向同步机制；其三，在业务层面，需要对业务进行改造，主要指业务应用的读写分离改造。
其也带来了一定的挑战，第一，主备数据中心仍位于相同的城市，在面对较大的灾难时，容灾效果会受一定影响；第二，这套容灾架构会给系统带来一定的复杂度，包括前面提到的应用层面要进行读写分离改造，最上层需要有负债均衡能力，最下层进行数据的同步，以及相应的故障切换的能力建设。
其适应的场景包括：第一，RTO可以实现秒级或分钟级，这取决于最上层的流量切换是否具备自动探活能力，在数据层面，进行主备数据库的切换，最上层如果不具备自动探火，还可以进行DNS切换；第二，其适用于在线金融交易应用、互联网应用以及社交媒体应用，这些应用往往需要高可用以及负债均衡。
2.2.3 异地双活
如左侧架构图所示，它具有以下几个特征：
第一，两个数据中心分布在不同的城市，满足“异地”的定义，一般指两个数据中心之间的距离大于1000千米，约为北京和上海之间直线距离，一般认为它可以避免市政级别的故障或自然灾害层面的故障；第二，两个数据中心都处于活动状态，对外提供服务，由于数据中心距离较远，故使用广域网进行数据的同步，且是双向同步状态，从图中可以看到，两个数据中心都叫做主数据中心，在异地多活或异地双活架构中，每个数据中心都是主数据中心，且使用双向同步确保数据的一致性，这里的数据包括数据库的数据以及一些有状态的中间件数据；第三，在最上层要在流量入口部署路由层，而路由服务主要的能力是使得相同特征的流量尽量在单个数据内闭环的处理，如可以按业务类型、用户ID或请求地理位置进行分类。一般会把接入层的路由及业务进行单元化改造。
若按业务类型分类，则是指系统有订单及库存服务，其中订单服务部署在北京，库存服务部署在上海，则所有订单的请求都要路由到北京，所有的库存请求都要路由到上海，否则就无法找到对应的业务服务器处理。若按用户ID分类，若用户A要路由到北京，则用户A所有的请求都要路由到北京，用户B要路由到上海，则用户B所有的请求都要路由到上海。若按地理位置分类，假设请求来自上海，则路由到上海地域的服务器，若请求来自北京，那则路由到北京的服务器。
做路由层的改造，核心原因在于两个数据中心之间的距离较远，其数据同步的延迟较大。当同一用户处理相同的数据时，发起了两个请求，如果第一个请求路由到北京，第二个请求路由到上海，由于两个请求发起的时间间隔很短，因此如果路由到不同的数据中心就可能会导致数据的紊乱，因为数据中心之间的数据同步本身就有一定的延迟，因此，我们要求相同业务特征的流量尽量在同一数据中心闭环处理，以避免数据同步延时带来问题。
这套容灾架构也会带来一些挑战，第一，由于数据中心之间距离较远，在使用广域网通信时会有一定的网络延迟；第二，这套容灾架构会使得应用系统变得更加复杂，包括进行最上层业务路由的划分，内部进行业务的单元化改造，以及数据的双向同步等措施。
其适用于RTO为秒级或分钟级，这取决于最擅长的路由服务是否可以实现自动探活，或者进行人工的路由切换。该架构适用的应用包括一些较为关键的金融系统、政府类型的应用以及云服务提供商等，即一类在面对大规模灾难时仍能够持续提供服务的应用。
2.2.4 异地多活
与异地双活类似，差别在于数据中心变得更多了，各数据中心之间继续采用双向同步的数据链路，随着数据中心的增多，数据双向同步的拓普变得越来越复杂。
其特征包括：第一，多个数据中心的异地多火指的是多个数据中心部署在不同的城市，各城市之间的直线距离大于1000千米的；第二，多个数据中心依然都处于活跃状态，同时对外提供服务，数据中心之间使用广域网进行数据的双向同步以确保数据的一致性，这里的数据同样包括数据库的数据以及一些有状态的中间件数据；第三，最上层依然需要部署路由层，把相同特征的流量尽量在单个数据中心内闭环处理。
其带来的挑战包括，第一，配置和管理多个一体数据中心的复杂度非常高，三个数据中心相较于两个数据中心在数据的同步链路复杂度已经增加不少，若是十个数据中心，复杂度会更高，这要求我们需要有强大的网络和资源管理能力；第二，随着数据中心的增多，确保多个数据中心之间数据的一致性也是非常大的挑战，包括数据的同步、数据的冲突、数据的复制等问题。
这套架构依然适用于RTO秒级或分钟级，这取决于路由服务能否自动探活或进行人工切换。它适用于需要在全球范围内提供高可用、高容灾和高负债均衡的应用，如一些跨国企业或云服务提供商的基础服务。
3. ECS团队在容灾上的实践
该部分以ECS内部某具体的Web服务为例，根据业务不同的发展阶段所经历的不同的容灾架构能力建设。根据Web服务经历的不同业务发展阶段，将其分成了三个阶段：
第一阶段，业务的起步阶段。在该阶段，整体的业务量较小，只有国内较少的Region对外提供了服务，这个阶段的客户也主要以中小客户为主。在该阶段，采用同城双活的容灾架构。
第二个阶段，业务开始快速发展，新Region开始持续不断开服，企业客户开始上云，对服务提出了更高的稳定性诉求。在该阶段，采用单元化的垄断架构。这里的单元化和与前面提到的淘宝天猫的异地多活单元化存在概念上的区分，后面会进行详细的介绍。
第三阶段，业务继续快速发展，Region开始遍布国内外。在该阶段，国内外的客户数量都在快速增加，这也会导致一些体验方面的问题。如跨国访问速度慢，域名切换体验差。在该阶段，为解决相应的问题，满足业务上发展的诉求，又升级到了异地多活的架构，在内部又称之为全球化的架构。
3.1 同城双活（跨可用区）
观察图左侧，最上层用户的请求通过DNS解析到公网SLB上，其具备可用区级别的主备的容灾能力，把请求再继续路由到可用区级别的应用级别的负载均衡，而应用级别的负载均衡也具备主备的容灾能力，进而将业务请求再路由到业务层面的应用。而应用无论是部署在主数据中心还是备数据中心，其所有数据的读写操作都会请求到主数据中心，包括中间件、数据库的一些操作，且中间件和数据库的数据采用单向同步机制把数据同步到备数据中心。在最下层，应用支持操作所有地域的ECS资源。因此，这套容灾架构可以很好地满足现阶段的业务情况，如业务质量较小、开服Region较少、客户以中小客户为主且主要集中在国内的现状。
它可以满足用户在高可用方面的诉求，包括毫秒级别的RPO，因为数据同步是可用区级别的，一般在几毫秒左右。第二，分钟级别的RTO，主要包括最上层的流量切换。为进一步提升应用的性能，在其内部也做了一定的业务改造，主要包括RPC流量在可用区内部封闭处理，目前主流的RPC框架都具备这种能力。
这套容灾架构是的我们具备了同城级别的容灾能力，但由于操作的是所有地域的ECS资源，当出现故障时，其影响面较大。
3.2 单元化
这个阶段业务开始快速发展，是因为Region持续不断开服,企业客户开始上云，对服务提出了更高的稳定性的诉求。因此这个阶段在高可用方面除了以上提到的几点，还应新增一点，即在故障时尽量控制影响面，仅影响单个地域，而不影响全网其他地域云资源的操作。
因此，将该阶段的容灾架构升级为了单元化的容灾架构。这里的单元化是指每个Region的操作都在单元内部闭环处理。当Region出现故障时不会影响另外的Region。这里的单元化与淘宝、天猫异地多活的单元化有一定差异。
观察图左侧的架构图，最上层用户请求不同地域时，其对应访问的域名不同，每个域名解析到对应的Region的公网SLB，到单元内部，架构与同城双活的架构基本一致，唯一的差别在于最下方Region A只支持操作Region A的云产品，Region B只支持操作Region B的云产品，进行了单元的隔离。
这样，第一，提供了单元化的服务能力，因此在故障时可尽可能地缩小影响面；第二，单元内部依然进行了同城级别的容灾能力，而不具备异地的容灾能力；第三，每个单元都会对外提供访问的域名，随着Region数量的持续新增，会给用户带来体验较差、跨境访问速度较慢等问题。
3.3 异地多活（全球化）
随着业务的发展，进入到了第三个阶段。在业务层面的主要特征包括：其一，Region开始快速增加，包括国内外的、开服的Region数量很多；其二，该阶段客户的分布也发生了较大的变化，国内外的客户数量都在快速增加，在进行跨国访问时速度较慢（这里的跨国访问指的说用户在美国，却要操作北京的Region资源，或用户在国内，要操作英国Region的资源，这便涉及到了跨国访问）；其三，域名切换体验较差，每个Region都对外提供访问域名，当要操作不同Region的云资源时，就要在各域名之间进行反复的切换，体验较差。
在该阶段，用户也提出了更高的可用性诉求，如地域出现故障时，是否可以把请求路由到另外地域进行处理，以那进一步降低故障的影响面。
观察左侧的架构图，最上层是一套DNS，DNS具备就近路由智能解析能力（用户在不同地域发起请求时，会就近解析出来最近的服务提供的地域，如用户在美国发起请求，则会把请求了路由到美国的服务器上面，如果用户在英国发起请求，则会把请求路由到最近的如德国的服务器上。
图片中展示了三个数据中心，而这套架构在线上实际有接近十个左右的数据中心，已基本上实现了全球每个大洲1-2个数据中心的部署，因此，在内部又称之为全球化架构。通过观察图上展示的三个数据中心，可以发现他们之间有一定的差异，数据Region a和Region c所有应用的写操作都回到了Region b的，则一般把Region b称为主数据中心，Region a和Region c称为备数据中心。所有备数据中心应用的写操作都回流到主数据中心，主数据中心把数据更新到数据库之后，数据库又会把数据采用单项同步的方式同步到各个备数据中心。
之所以要进行这样的改造，与自身应用的业务特征是有强关联性，因为该应用是非常典型的“读多写少”的应用，这样改造之后可以大幅降低应用本身的复杂度以及容灾系统部署的复杂度。在最下方，支持操作所有地域的ECS资源，在每个Region内部采用的还是同城双活的容灾架构。
关于容灾的效果，第一，所有的读操作都具备了异地级别的容灾能力，而写操作依然是同城级别的容灾能力，因为所有的写操作都会回流到主数据中心，主数据中心内部采用了同城双活的容灾架构；第二，单元内部是具备的同城级别的容灾能力；第三，使用了DNS智能就近解析能力，可以提升用户的访问体验，现在一般云厂商提供的DNS解析服务中都有智能就近解析的能力。如全球洲级别的路由能力或国家级别的路由能力。
这套架构本身有一定的复杂程度，对业务的改造量较大，如刚才提到的所有备数据中心的写操作都要回流对到主数据中心，因为每个数据中心都有缓存中间件，所有的写操作都回到主数据中心之后，数据进行了更新，操作之后如何同步更新备数据中心的缓存也是非常大的挑战。
4. 云上容灾建设最佳实践
4.1 建设路径
以上这张图片是阿里云对外提供的云上容灾交付服务白皮书中关于云上建设容灾能力的路径说明，主要分成五个步骤：
- 需求分析
在该阶段，主要关注服务是否需要进行容灾建设，以及需要建设到何种程度的容灾能力。因为对于业务不同的阶段，所要关注的重点也不同。如对于起步阶段的业务，其更多关注的是如何吸引更多的客户；第一阶段发展过后，客户数量有了一定程度的增加，此时则会对应用带来更高的流量，此时更关注的是如何建设应用的稳定性，如高并发或慢搜克的问题，该阶段一般采用同城双活的容灾架构。即可满足大部分的诉求；再进一步，如果业务发展成了国民级别，或公司的基础层面的设施服务，则要考虑进一步的容灾能力的建设，包括异地双活火或异地多活的容灾能力。
因此，要基于自身业务的发展情况及自身应用的特征分析所需的应用的容灾要满足怎样的诉求，定义具体的RTO和RPO。即使是同一公司，不同的应用、不同的服务对容灾的诉求也是不同的。比如库存服务，因为库存对数据一致性要求非常高，因此库存一类的服务就不太适合进行异地多活或异地双活的容灾架构建设。
- 现状调研
包括去分析每个应用的情况（不同的应用对业务的重要程度不同，对容灾的诉求也不同），云平台的调研（如云平台上能提供哪些容灾能力，可以在哪些层面降低容灾建设的成本），以及基础设施层面的调研。在调研阶段，可以产出调研报告指导设计工作。
（3）容灾方案设计
包括总体的容灾方案，云平台方面进行容灾部署的方案，应用层面要进行容灾方面的改造设计，以及在具体的应用容灾部署方案。这一阶段可以产出应用容灾的方案以及平台容灾的方案。
- 容灾能力的演练设计
包括要进行哪些场景的演练，对应的应急预案如何，DRP方案如何。这个阶段可以产出容灾演练的方案。
- 演练的实施
包括演练如何操作，演练之后内部的复盘会议。通过演练的实施，可以产出容灾演练报告，进行相应的查漏补缺，以完善系统整体的容灾能力。
4.2 同城双活
接下来以具体的云上同城双活容灾建设为例，学习在云上如何做容灾能力建设。
在云上进行容灾建设，目前云上很多的云产品都已经具备了容灾的能力，可以大幅降低自身业务层面落地容灾能力时的成本。这里主要从计算高可用、存储高可用，以及业务改造层面学习在云上做同城双火时，可以借助云上的哪些服务降低容灾能力建设的成本。
首先，在应用高可用部署层面，可以采用跨可用区的ECS或ECI进行冗余部署。ECS主要解决的是VM层面部署的技术部署方案，ECI可以解决容器层面的技术部署方案。如果服务目前还是在云下，未部署到云上，可以考虑使用服务器迁移中心SMC云产品把线下的云下的服务栏快速部署上云，甚至服务无需要中断。如果服务已经部署在云上，为了进行同城双活容灾，则需要将服务同从一个可用区快速部署到另外一个可用区，则可以考虑使用资源编排ROS云产品，满足服的一键快速部署。最上层还需要进行流量的负债均衡，可以考虑使用SLB的多可用区部署。
在存储高可用方面，主要关注数据库以及缓存中间件、消息中间件以及文件的存储。在这一层面，很多云产品也都提供具备容灾能力的产品服务，包括说云数据库RDS的高可用系列多可用区部署方案，云数据库 Redis高可用系列双可用区部署方案，消息队列 RocketMQ 版，它本身具备容灾能力，以及OSS 同城冗余存储。
在具体的业务改造层面，首先要做的是业务要支持读写分离，第二为了满足更好的应用性能，应尽量是做到可用区内部RPC流量的封闭。基本上，目前主流的W3等都支持该能力的。
4.3 异地双活
异地双活由于两个数据中心距离较远，直线距离大于1000千米。
在计算高可用方面，除了刚提到的应用高可用容灾部署，以及流量的负债均衡之外，还需要跨地域高可用的网络服务，推荐使用云企业网CEN云产品，它可以帮助我们构建数据中心之间较高质量的网络链路。
在数据存储的高可用方面，除了刚才提到的数据库高可用、缓存组件的高可用、消息组件高可用和文件存储高可用之外，由于涉及到数据中心广域网的数据同步，还需要进行数据双向同步服务，可以采用数据传输服务DTS云产品，帮助我们解决包括常见数据库以及数据类的中间件组件层面的数据的双向同步能力。
最大的挑战还是在业务改造层面，在业务改造层面，除了要继续支持RPC流量内部封闭之外，还需要在最上层进行业务路由层的改造、业务单元化的划分以及一些读写分离方面的改造。这里的路由层还要满足使得相同特征的流量尽量能够在单个数据中心闭环处理。如果使用的是地理位置方面的路由服务，可以考虑使用云解析 DNS - 智能DNS解析能力，前面提到ECS内部的Web应用现在采用的异地多活全球化的容灾架构最上层的DNS是解析使用的云解析 DNS - 智能DNS解析能力。
异地双活对业务改造成本较高，因此，我们推荐进一步采用阿里云提供的多活容灾 MSHA云产品，进一步降低在业务层面的改造成本。
最后就本次的交流内容进行简单的总结和回顾。
在第一部分的内容中介绍了系统容灾方面的内容，包括常见的故障类型，特别是市政方面的断电断网以及自然灾害方面的故障。在介绍故障的同时，以具体的案例展开讲解了在云上也需进行容灾方面的能力建设，以避免此类故障对业务产生的致命的影响。此外，还介绍了常见的容灾级别，包括同城级别的容灾，异地级别的容灾，以及同城容灾和异地容灾的组合形态。
在第二部分，介绍了业界比较主流的容灾架构，以及在容灾能力方面比较有影响力的两个评价指标，分别是RPO和RTO。在主流容灾架构对比中，详细展开介绍了包括同城灾备、同城双活、异地双活和异地多活四种容灾架构。
在第三部分，就ECS团队内部某具体Web服务在业务不同的发展阶段采用不同的容灾架构的思考和实践进行了详细的介绍。包括在应用的起初始阶段采用的同城双火容灾架构，以及随着业务的快速发展和客户数量的增加，逐渐演变到单元化和全球化容灾架构。
最后一部分，介绍了在云上如何进行容灾能力的建设，包括在云上如何进行容灾建设的最佳实践路径，以及具体地在云上如何进行同城双活和异地双活能力的建设。在具体的案例介绍中，还介绍了包括在计算高可用、存储高可用以及业务具体的改造方面的一些内容，以及相关的具备灾备能力的云产品，在云上进行容灾能力建设的同时，借助这样云产品可以大幅降低在云上容灾建设的成本。
