又双叒叕崩了！如何破解分布式系统无法逃避的“降维打击”？

11月27日，某云多个地区云控制台及openAPI访问出现异常，影响Redis等多个数据库产品，所幸未对实例运行出现故障。这已是该云厂商11月内第二次出现故障——上一次故障几乎影响全线数据库产品，并波及业务运行。

无独有偶，27日晚，另一互联网厂商云平台又爆出超大规模故障，几乎所有上线业务均受到不同程度影响，故障时间长达8小时……

云平台接连出现事故，背后原因众说纷纭，但总让人们不得不再次思索这个话题：是否真的有一种面向分布式系统的“降维打击”，让身经百战的云厂商也防不胜防？我们又能否规避这一问题呢？

“降维打击”来了！分布式系统如何招架？

狭义的分布式系统指的是由多个通过网络互联、执行相同工作的计算机节点组成的系统，进而可以通过分治的手段完成工作量巨大的任务；而广义上的分布式系统中，不同计算机可以完成不同工作，最终通过协同的方式实现具体的业务功能。近年来及其流行的分布式数据库、分布式存储可视为狭义的分布式系统；云则可视为一个超大型的广义分布式系统。

虽然分布式系统中节点众多，但并非“群龙无首”，有一只无形的手在指挥调度着所有节点的运行。操纵这只手的就是常说的“调度节点”或者“管理节点”。对于狭义分布式系统来说，管理节点的主要工作是监控各个节点的正常工作状态，并时刻保持系统响应请求、或时刻保持所有节点持有数据的一致性；而对于广义分布式系统，管理节点还会处理请求分发、负载均衡等工作。不论哪种系统，管理节点的重要性都不言而喻，因此分布式系统“三军亦不可夺帅也”！

然而，分布式系统依靠管理节点实现正常运转的机制，导致其不得不面临一个无力抵挡的“降维打击”——管理节点故障！正如一只强大的部队会因为指挥系统混乱而崩溃，再牛的分布式系统，如果管理节点故障了、Bug了，也会停止运行或运行混乱。有人问，如果对管理节点做冗余保护，或者多个管理节点共同决策，是否可以应对该情况？很遗憾，这依然不是完美答案。以业界分布式系统最常用的类Paxos算法举例：

• 对于Multi-Paxos或者Raft等算法来说，Leader节点就是系统的管理节点；如果Leader故障了，此时分布式系统处于群龙无首阶段，必须停止业务运行，重新选择一个Leader。然而，选择Leader也会出现难题：如果遵从多数投票机制，当系统因为网络问题分裂成多个部分，或者可能所有节点都无法获得过半投票，导致选不出来Leader，系统一直宕机；如果不遵从多数投票机制，系统有可能选出多个Leader，导致“脑裂”出现，系统运行混乱。
• 对于Basic-Paxos算法来说，虽然有多个Leader共同决策，但他们可能因为网络延迟原因始终无法达成一致，导致不断重复投票，对外表现为业务宕机，实际表现甚至远不如Multi-Paxos。

上述故障只是分布式一致性算法中BUG现象的冰山一角，在实际运行过程中，还有更多软、硬件BUG和升级失败、人为误操作等“黑天鹅”事件发生，导致原本正常运行的分布式系统突然宕机，即使系统跨多个站点容灾也无法防御，堪称真正的“降维打击”！

事实上，对于广义分布式系统而言，除了管理节点外，一些业务汇聚点也容易带来“降维打击”。在云服务提供商官方公布的“11.12”故障原因中提到，此次故障是由于其访问密钥服务(AK)出现白名单读取异常，导致大量有效请求访问失败，服务无法正常运行。

AK服务作为云系统的鉴权单元，是所有外部访问的门户，一旦故障将导致整个云系统停止服务。类似于AK服务这样的业务汇聚点还包括DNS、消息队列等等，由于这些服务往往也是一个个小的分布式系统，也会出现BUG或者故障，最后导致整个云系统遭到“降维打击”停止运行。

总之，不论是管理节点故障还是业务汇聚点故障，对于分布式系统而言，“降维打击”始终存在，且防不胜防，让运维人员苦恼不已！

双集群容灾，应对“降维打击”的有效出路？

分布式系统面临“降维打击”，我们是否就要因此抛弃它呢？这显然是一个既不合理、也不现实的事情，因为广义的分布式系统涵盖了几乎所有现代IT系统，这是我们无法逃避的。那是否存在一种方法，能够帮助分布式系统尽可能降低“降维打击”带来的损失呢？或许双集群容灾是一条行之有效的出路。

“降维打击”虽然可怕，但仍有其局限性：一是只能对单个分布式系统（或分布式集群）造成影响，而不会主动传染到其他系统；二是一般只会导致业务宕机，不会造成毁灭性破坏（比如数据全部被销毁），运维介入后可以恢复，但耗时较长；三是往往由于一些偶发原因导致，并不是每次运行都会触发。既然分布式系统内的节点可以冗余，分布式系统整体是否可以冗余呢？这就引出了双集群容灾方案。

双集群容灾，顾名思义，是一个系统由两个分布式集群承载，两个集群互为冗余的一种容灾方式。当工作中的集群遭遇“降维打击”时，灾备集群可以快速接替其工作，保证周边系统可以继续正常访问，业务可以正常运行，也留出充裕的时间让运维人员恢复故障集群。

在双集群容灾中，有两件事情至关重要：一是生产集群和灾备集群要完全隔离，故障不能传染；二是切换要平滑，这就意味着两个集群的数据和对外接口要保持一致。以上两点可以推导出双集群容灾的理想架构：两个集群间必须通过一个不受管理节点控制、足够可靠的管道连接，并持续传输数据和管理信息，保持数据的一致性，以及在生产集群故障后主动将业务流切换到备用集群。

双集群容灾方案架构示意图

那么，在现实中如何实现“双集群容灾”的方案呢？这一问题没有标准答案，但我们或许可以从一些案例中窥视到些许端倪：

• 2023年公布的工商银行核心系统数据库双集群容灾方案中，在生产和灾备数据中心各部署一套分布式数据库集群，两个集群间完全隔离，而数据同步依靠两套存放数据的高端存储间进行复制完成。由于高端存储的复制独立于数据库集群之外，且稳定性较强，进而实现了理想架构中“管道”的效果。
• 业界主流容器应用双集群容灾方案，主要是通过将Kubernetes集群中容器的元数据、镜像数据和业务数据，通过专业存储或云存储的方式复制到容灾站点，进而可以在容灾站点的另一套Kubernetes集群上将所有应用重新恢复，达到双集群容灾的效果。
• 近年来企业多云建设开始流行，其中一个重要原因是通过不同云互相容灾来保障关键业务运行。业界主流的多云间数据互通方案是通过将数据放到一个足够可靠的本地存储环境，并提供给多云访问；多云间业务切换则主要通过Kubernetes提供一个屏蔽底层差异的运行环境，并确保应用恢复后的一致性。

……

通过双集群容灾，业务可以有效避免因分布式集群系统级BUG导致长时间宕机问题；甚至在遇到IT系统升级造成计划内停机时，也可以通过集群切换来实现灰度升级功能，保障升级期间业务正常运行。

在分布式系统越来越多用于关键业务的今天，双集群容灾应当逐步成为一种建设标准，所有的架构师都应思考如何设计所负责系统的双集群容灾方案，以防止分布式系统“降维打击”这样的黑天鹅事件给企业和社会带来巨大损失，让云系统宕机数个小时这样的事情不再发生。