探索容灾架构演进之路 - 从单点到异地多活

1. 挑战与变革

在公司发展初期，业务发展和用户增长是首要关注的焦点。然而，随着业务规模不断扩大，用户数量逐渐攀升，应用稳定性的重要性也变得愈发凸显。在这个演进过程中，传统架构下的应用部署模式开始显露出多方面的稳定性风险，其中最为显著的问题之一就是机房单点故障。当机房发生故障时，业务无法迅速恢复，这可能导致巨大的损失。

以近两年实际案例为例，我们可以看到，无论是云上机房还是自建机房，都存在机房故障的潜在风险。例如：

• 2022 年 12 月 18 日，阿里云香港 Region 可用区 C 遭遇机房冷却系统异常，导致大规模服务中断，故障长达近 12 个小时。

• 2023 年 3 月 29 日，唯品会南沙机房冷却系统故障，导致线上商城停止服务，故障时间超过 12 个小时，损失超过亿元。

• 2023 年 4 月 10 日，腾讯云广州电信机房冷却系统故障，导致大规模服务异常。

这些事件凸显了无论是云服务提供商还是自建数据中心在面对机房故障时的脆弱性，所以在部署架构上要尽可能的做到高可用，来应对潜在的机房故障风险。这种改革是为了确保业务的持续稳定运行，减少因故障而导致的经济损失。

2. 理解传统部署架构的局限性

在业务发展初期应用部署架构相对简单，但没有任何灾备能力，当存储或应用故障时整个业务将会中断。 

为了提高可用性架构会演进成将存储进行主从部署，当存储故障时可由从库快速切换为主库继续提供服务，同时也开始将业务应用和接入层多实例部署，进一步提高可用性。

随着业务进一步发展，业务应用也开始由单体应用向微服务演进，随着新应用的加入整体架构如下。

到目前为止从接入层、应用层、存储层均已经具备一定的高可用能力，但还是那个核心问题整个架构部署依然是在单个机房完成的。如果遇到机房级别的故障，这套部署架构还是无能为力，这就是传统部署架构的局限性

3. 容灾架构的类型

针对传统架构的容灾设计业界常见的方案有异地冷备、同城双活、两地三中心、异地多活

异地冷备

异地冷备部署架构是由两个机房组成的，主机房负责对外提供服务，而备机房则专注于存储数据备份。在主机房发生故障时，应用部署需要在备机房进行全面展开，包括接入层和业务服务。接下来的流程包括将备机房的存储切换为主库，最终将流量切换到备机房的接入层。这一故障恢复的过程相对较长，需要大量人工干预，因而准确性和实效性难以得到充分保障，从而显著延长了服务不可用的时间。即使在所有故障恢复动作完成后，由于备机房未经验证，也难以确保备用机房能够直接提供对外服务。

• 优点：成本低，硬件以及网络等资源投入少

• 缺点：可用性差，故障恢复时间长甚至无法恢复

• 适用场景：对恢复时间要求较低的应用，成本敏感的业务，非关键业务或支持性业务，较小规模的企业（有一定规模的公司几乎很少使用此方案）

同城双活

同城双活部署架构同样需要两个机房，异地冷备架构中备用机房可用性无法得到保证，那么同城双活部署架构的思路就是让备用机房和主机房一样，实时对外提供服务达到“热备”的效果。机房 A 和机房 B 是部署在同一个城市，两个机房间使用同城专线交互，延迟相对较低。理想状态下当机房 A 出现故障时可以直接将流量切换到机房 B，而无需担心机房 B 的服务不可用

• 优点：机房故障隔离，双机房流量负载均衡，机房间通信相对较低的网络延迟，高可用

• 缺点：部署架构相对复杂，运维 &研发成本增加，无法应对城市级别故障

• 适用场景：同城双活适用于那些对系统可用性要求极高，不能容忍长时间的停机和服务中断的业务场景（通常作为异地多活的一个过渡阶段）

两地三中心

两地三中心的部署架构是同城双活+异地冷备的组合模式，在同城双活的基础上另外建设异地机房，在异地机房中备份存储数据，当发生城市级别的故障时（例如地震，海啸）可以在异地机房中部署接入层，全量服务来对外提供服务。不过这个和异地冷备一样，当真正需要异地的冷备机房启用时很难保证它能正常工作。

• 优点：机房故障隔离，城市故障有灾备能力，双机房负载均衡，机房间通信相对较低的网络延迟，高可用

• 缺点：运维 &研发成本增加，异地冷备的数据中心可用性很难保障

异地多活

异地多活是最理想态的容灾部署方案，部署多个数据中心，数据中心可以无限水平扩展，多个数据中心同时对外提供服务，任意数据中心故障时可以将流量切换到其他数据中心。不过异地多活的挑战也是最多的，要在同城双活的基础上实现单元化，不同数据中心之间的数据同步以及管控系统的多活等等，每一个挑战都是困难且复杂的。

小结

通过上面的介绍不难看出，这几种容灾架构的对应的可用性是逐步提高的，事情都是具有两面性的，在可用性逐步提供的同时整个部署架构的复杂性和成本也是再升高的。

4. 容灾架构选择的关键因素

在容灾架构中，核心思想是通过冗余部署，将可能出现问题的单点服务、接入层和存储，在一个或多个数据中心中进行冗余部署，以应对潜在的故障。然而，冗余带来的问题主要体现在成本方面。在我看来，选择适合的容灾架构是一个涉及可用性需求和成本（运维和研发成本）的博弈过程。

在软件行业中，大家通常都听说过一句话：“世上没有最好的架构，只有最合适的架构” 异地多活被认为是最理想的容灾方案，但并不适用于所有公司的所有阶段。在选择容灾架构时，需要综合考虑容灾需求和成本，选择当前最适合的架构。这是一个动态的过程，随着业务的发展逐渐演进。

因此，在选择容灾架构时，公司需要明智地权衡可用性需求和维护这种冗余结构所需的资源投入。这种平衡是一个关键的战略决策，影响着企业的业务连续性和整体稳定性。

5. 总结

本文简要介绍了几种容灾架构的类型和它们各自的优缺点。容灾架构的选择在于平衡可用性需求和成本之间的关系,并不存在一种完美的架构，而是应该根据业务发展的阶段逐步演进容灾架构，避免陷入过度设计和资源浪费的困境。理性地选择最适合当前业务阶段的架构，并在业务发展中不断进行迭代，是建立强健容灾体系的关键。

接下来的问题是如何根据当前架构进行变革和实施。这个过程充满了挑战和困难，需要认真应对。在下一篇文章中，我们将深入探讨同城双活容灾架构在实际落地中所面临的困难和挑战，并提供相应的解决方案。

6. 作者介绍

张斌斌（Github 账号：binbin0325，公众号:柠檬汁 Code）Sentinel-Golang Committer 、ChaosBlade Committer 、 Nacos PMC 、Apache Dubbo-Go Committer。目前主要关注于混沌工程、中间件以及云原生方向。