在7月初举行的「可观测，才可靠——云上自动化运维CloudOps系列沙龙第一弹」，阿里云弹性计算技术专家邓青琳分享了《云上跨可用区容灾和异地多活》，本文根据其演讲内容整理而成。
系统容灾
提到容灾，必然会关联到故障。常见的故障类型有变更、硬件故障、断电断网以及自然灾害，发生的频率依次降低。但发生频率低并不意味着不重要，断电断网或自然灾害产生的故障往往是致命的。
2021 年 3 月 10 日，欧洲最大的云服务公司 OVH 位于法国的机房着火，导致数据中心被完全烧毁，致使 350 万个网站下线，部分客户的数据永久丢失，无法恢复。OVH 公司 CEO 在推特上关于此次火灾的说明中提示客户启用自己的容灾方案。由此可见，即使应用部署在云上，也无法避免市政方面的故障比如断电断网以及极端自然灾害引起的故障，因此也需要做好相应的容灾方案。
目前主要的容灾类型可以分为以下三类：
- 同城（跨可用区），主要分为同城灾备、同城双活以及同城多活。
- 异地（跨地域），主要分为异地双读、异地应用双活以及异地双活。
- 其他类型，包括两地三中心、两地三活以及单元化。
没有一套容灾方案可以适用于所有场景，我们需要结合实际业务发展趋势、业务系统的特征以及能够投入多少资源成本等方面综合评估，最终选出最适合的容灾架构方案。
主流容灾架构
容灾能力主要有 RPO 和 RTO 两个评价指标。
RPO 指应发生故障时能忍受数据丢失的最大程度。系统越重要，要求 RPO 越小。如果做数据备份，RPO 越小意味着数据的备份频率更高，比如一般的系统可能一天备份一次，非常重要的系统可能一小时备份一次；如果做数据同步，RPO 越小意味着要求数据同步链路的可靠性更高或延迟更低，对整个生产环境和网络的压力越大，需要的成本也更高。
RTO 指应用从出现故障到故障恢复能接受的最大时间。系统越重要，要求 RTO 越小。
上图右侧为国家信息委员会制定的灾难恢复能力等级，分为 1-6 六个等级。其中 6 为要求最严格的等级，RTO 要求为数分钟，RPO 要求为 0，意味着系统数据不允许丢失。
下图为目前四个主流容灾架构的对比。
同城灾备
同一个城市至少部署两个机房，备机房平时不提供服务能力，主要作为主机房的备份，主备之间数据采用单向同步的形式。
优势为部署简单，将同一套架构完全复制到另外机房即可，数据做单向同步，对业务的改造极少。
劣势为备数据中心存在资源浪费的情况；关键时刻不敢切流，容易出现版本、参数、操作系统不一致等情况；RTO 需要十分钟级。
同城灾备架构做容灾切换时，首先需要做数据库的主备切换。如果是冷备状态，还需要启动应用服务，最上层 DNS 也需要做解析的切换，整过程需要十几分钟。
同城双活
两个机房同时对外提供服务。为了数据的一致性，备数据中心所有涉及到数据层面的操作都会打回到主数据中心，因此两个数据中心的距离要求小于 50km，RT 小于 2ms。如果请求落在备数据中心，则涉及到跨机房操作。如果跨机房的 RT 非常大，数据请求在主、备数据中心的性能差异也会非常大，无法提供很好的用户体验。此架构下数据采用单向同步方式。
优势为解决了备数据中心资源浪费的问题，并且因为日常保持提供服务状态，出现故障时可以随时切换，只需做数据库的主备切换，RTO 为分钟级。
劣势为局限在同城区域内，距离受限。
异地应用双活（伪异地双活）
它与同城双活有很多相似之处，唯一的区别在于备数据中心的读写进行了分离，读操作直接读备数据中心，而写操作为了保证数据一致性，将打到主数据中心的数据库上。要求两个数据中心距离小于 100km，RT 小于 7ms。如果两个机房的距离过远，请求在两个机房之间的性能表现差异会很大。此架构比较适合读多写少的系统。
优势为具备了一定程度的地域级别容灾能力，虽然架构要求距离小于 100km，但是对于大部分地级城市而言，100km 已经能够覆盖两个地级城市，RTO 只需分钟级别。
劣势为业务系统需要能够接受一定的跨机房网络延迟；另外，业务需要进行一定程度的改造，主要为读写分离操作方面；容灾距离依然受到非常大的限制，因此称其为“伪异地双活”。
异地双活
真正的异地双活可以接受两个机房之间的距离大于 1000km，RT 超过 10ms。为了解决此前两个机房中的性能差异，我们使用了单元化的解决方案。单元化指请求落到某单元后，所有请求操作都在单元内闭环处理，避免涉及跨机房操作。因而不管请求打到哪个机房都能保证基本一致的处理效率，也能保证良好的用户体验。为了实现单元化，要求各个机房之间数据双向同步。
优势为容灾能力非常强，几乎不受限制， RTO 为分钟级别。
劣势为部署复杂，因为涉及到数据的双向同步，不仅是数据库，还会涉及到比如 Redis 缓存、 Rocket MQ 、有状态中间件等；业务改造成本非常高，涉及到单元化和接入层等维度。
弹性计算在容灾上的实践
上图为同城双活最初的架构图。
用户访问域名时，请求会打到公网 SLB 上。SLB 在两个可用区之间有主备的容灾能力，会路由到某可用区内。可用区内的 SLB 再将请求转发到具体的业务服务器上，业务服务器会将所有数据操作打到主数据中心，主备之间的数据进行单向同步，底下系统操作所有地域的所有云产品。
此时的系统具备了跨可用区级别的容灾能力，RPO 小于 100 ms，RTO 小于 10 min。为了提升应用的性能，尽量避免发生跨机房的 RPC 调用，我们还设计了 RPC 调用同机房优先的策略。
此架构的不足之处在于，不具备地域级别的容灾能力；其次，系统会操作所有 region 的云产品，一旦系统出现问题，会影响所有地域的云产品操作，影响面非常大；海外用户访问时速度较慢，因为系统部署在国内，海外用户访问涉及到跨境问题，严重时甚至打不开页面。
为了解决上述版本的不足，我们引入了第二版架构，其核心为单元化。单元化指 region 的所有操作系统都部署在本 region 内， region A 服务不会涉及到 region B 的资源操作。region 内部为双可用区的容灾能力。
此架构与最初版本唯一区别在于，此版本在操作云产品时，只操作本 region 的云产品。万一出现问题，故障面较为可控，只会影响本 region，不会影响其他 region ，缩小了故障的爆炸半径。
此版本单元内部依然为跨可用区级别的容灾能力，RPO 小于 100 ms， RTO 小于 10 min，依然保留了 RPC 调用同机房优先的策略。
其不足之处为，容灾层面依然不具备地域级别的容灾能力；其次，用户体验非常差，比如在系统上操作云产品资源时，如果涉及到地域的切换，整个页面需要重新刷新；另外，跨境访问慢的问题依然存在。
为了解决上述不足，我们将架构演进至第三版，核心为全球化，本质上属于异地多活架构。单元化时每个单元都有域名对外提供服务；而全球化后，将所有域名都统一成一个域名对外提供服务，由最上层的 DNS 做智能就近解析。
Region 内部依然为可用区级别的容灾。虽然在全球部署了多个地域，但地域内也分为主地域和单元地域。所有数据的写操作都会打回到主中心，单元地域的写操作会回流到主地域。写操作打回中心之后，中心数据会单向同步到其单元地域。如果是双向同步，会导致同步的拓扑关系形成非常复杂的网状形式，因此采用单向同步模式。
此架构具备了地域级别的容灾能力，提供了智能的就近解析能力，用户体验更好，不需要在各个域名之间反复跳转。
而因为地域部署非常多，数据同步耗时较久，只能够确保 RPO 小于 10 s，RTO 小于10min。地域单元内部依然保留 RPC 同机房调用优先的策略。出现故障时，会就近请求路由到另一地域。
此架构部署复杂，涉及到数据同步问题，因此需要对系统做一定程度的改造，比如写操作要回流到中心，数据被改之后也会涉及到缓存的更新等；此外，所有写操作都要回流到中心，因此写操作依然为跨可用区容灾，没有真正做到跨 region 的容灾能力。
云上容灾建设
云上容灾的建设主要分为三个阶段，分别是分析阶段、设计阶段和实施阶段。
分析阶段需要考虑业务是否需要做容灾，需要做到什么程度。比如系统初始阶段更关注的是用户量，用户量做到一定程度之后，需要关心系统的稳定性，最后考虑容灾能力。此外，做容灾时需要将系统业务分开来梳理，是否为核心业务、能够接受的 RPO 是多少等。
设计阶段会基于分析阶段得出的数据进行设计。
实施阶段的落地过程涉及到团队协作、组织层面的资源投入，更重要的是要将真正遇到故障之后如何恢复的预案进行详细设计。此外，还需要做常态化的容灾演练，容灾系统的维护，包括人员的培训等，都是非常庞大的系统性工程。
阿里云提供了非常多云产品和服务帮助用户高效快捷地完成容灾方面的建设。
如果系统还未部署在云上，可以通过服务器迁移中心快速将整个系统迁移到云上。它能够支持多种平台、多种环境的迁移，也不依赖源服务器的底层环境，可支持不停机的迁移，在控制台上通过白屏化的配置即可完成所有操作。过程中数据传输有足够的安全保证，支持断点续传、增量迁移。
如果系统已经在云上，阿里云还提供了资源编排能力，确定好筛选条件后即可快速将系统复制到另外的地域/可用区。
服务部署完成后，可以使用数据传输服务 DTS 进行数据同步或数据备份。DTS 非常强大，支持同构或异构数据源之间的迁移，也支持不停服的迁移。在数据源之间支持单向同步和双向同步。
多活容灾 MSHA 能够对业务做改造，内部集成 DTS 等数据同步产品，可以非常快速地实现业务上整体容灾能力的建设，包括从单个地域到多个地域、从单个云到多云、从主备到多活容灾架构等。
另外，MSHA 积累了非常多实践经验，包括公有云、专有云、混合云等。它还提供了控制台，在控制台上能够完成容灾的管理和切换工作。
云解析 DNS 基于智能 DNS 解析做就近访问。目前主流的 DNS 解析服务都能够提供较为智能的解析线路，比如州级别、地域级别、国家级别等。
云数据库针对 RDS 的高可用版本和 Redis 的双可用区版本都提供了可用区级别的主备能力，用户无需自己进行处理。异地场景不同 region 之间的网络可以使用云企业网将多个基于不同 VPC 的网络连通。
Q&A
可用区的容灾和传统容灾最主要的区别是什么？
答：传统容灾指同城灾备，备数据中心服务平时不对外提供服务，主要提供备份的作用。优势为对业务改造非常小，部署简单；劣势为浪费资源，且由于平时不提供服务，关键时刻不敢切流。同城双活还有一种组合形态，比如两地三中心，指在某一城市有两个可用区级别的机房同时对外提供服务的，而另一城市主要做灾备，平时不提供服务，比较类似于同城双活和同城灾备在多个城市之间的组合。
异地多活如何保证数据同步？
答：数据库本身就有同步的能力，云上也提供了相关产品比如 DTS，能够帮助用户更简单地实现同步。针对中间件比如 Redis 、RocketMQ 等 ，DTS 也提供了同步的能力。当然，开源业界也有非常多解决方案，但需要涉及到运维工作。
异地多活和同城多活数据同步的区别是什么？
答：如果是同城多活，直接使用云上的 RDS 或 Redis ，由高可用版本和双可用区版本直接提供同城级别的容灾能力，用户无需自己做数据的同步建设；而异地多活、异地双活涉及到跨 region ，RDS 或 Redis 无法提供对应的能力，因此，用户需要借助比如数据传输服务 DTS 建立同步链路，或自己实现相关的数据同步组件。云产品提供了非常丰富的容灾能力，但主要聚焦在 region 内部。
在国际化的案例里，是异地接入的全部用户都回到原主中心，还是仅写 DB 回到原主中心？
答：写主要指 App 承载的数据读写，所有地域的写操作都会打到中心地域，中心地域写到数据库之后，再通过 DTS 的同步能力将数据同步到各个地域。同时，DTS 提供了 Binlog 的消息能力，各个单元订阅主数据中心的 DTS binlog 消息服务，从而得知何时需要废弃缓存或重新刷新。
什么样的系统需要改造？
答：有一些系统可以完成单元化改造，但是有一些系统比如库存服务，因为库存扣减要求全局强一致性，因此无法实现单元化部署。因此，在分析阶段我们需要判断系统能否接受单元化改造或系统 RTO、RPO 的要求。不同的业务系统、不同的场景选择的容灾架构都是不同的，需要结合实际的业务场景来选择。
