Two zones or three? A design framework for zone-resilient Azure workloads

要点: 区域弹性并不是一个可以应用于整个工作负载的单一数字。真正需要思考的问题不是“多少个区域？”，而是“每个组件需要多少个区域才能在损失一个区域时依然存活？”应逐个组件决定区域模式，在适用场景使用服务管理的区域冗余，并将三区域设计保留给确实需要第三个故障域的组件。如需深入了解如何为特定工作负载在两区域和三区域模式之间做出决策，可参见配套文章为区域弹性Azure工作负载选择两区域和三区域模式。

如果询问一群架构师生产工作负载需要多少个微软Azure可用性区域，大多数人会回答“三个”。这种直觉是合理的，但“每个地方都用三个区域”只是代替深入思考的默认规则。将这种默认规则视为标准，会悄无声息地消耗你本不需要的容量、金钱和运营复杂度，同时偶尔还会提供比你预期更少的保护。

区域弹性不是你为整个工作负载开启的属性，而是你逐个组件做出的一系列决策。某些组件在两个区域间完全受保护，某些确实需要第三个区域。对于越来越多的组件，Azure会为你管理区域冗余，此时最佳决策就是放手让Azure处理。本文将探讨如何区分这些情况。

可用性区域的保护范围（以及不保护的范围）

支持可用性区域的Azure区域由多个独立的数据中心组构成，每个组都有独立的供电、冷却和网络。区域弹性保护你免受单个区域丢失的影响，但无法保护你免受整个区域丢失的影响。如果你的工作负载是关键任务型或具有严格的灾难恢复要求，区域是必要的但不充分的：你还需要进行多区域规划，而这属于独立的设计工作。

明确“使用区域”具体含义非常重要，因为Azure服务通过两种不同方式暴露这一特性：

• 区域冗余资源 由Azure自身跨区域分布或复制。Azure负责复制、请求分发和故障转移。当服务提供区域冗余且满足你的需求时，这通常应作为起点，尤其是生产工作负载。
• 区域资源 被固定到单个区域。区域资源与其他区域的故障隔离，但不会自动抵御自身区域的故障。要使区域设计具备弹性，你需要自行跨区域部署实例，并自行管理路由、复制、故障检测和恢复。

这一区别至关重要，因为Azure上的可靠性是共享责任。区域冗余服务的弹性是微软需要交付的责任；你自己组装的区域设计的弹性则主要需要你自行配置和验证。没有任何一层可以弥补其他层的缺失。

在组件层级做决策，而非工作负载层级

“每个地方都使用三个区域”可能并非最佳起点，原因在于一个工作负载并非单一事物。它包含无状态前端、应用层、队列、缓存、关系型数据库、对象存储，通常还包含一个或两个基于多数派的系统，且这些组件具有不同的故障行为。将相同的区域数量套用在所有组件上，实际上无法优化任何组件的性能。

将工作负载按关键流程拆分，再按组件进行细分，对每个组件提出以下三个问题：

• 资源可用性：如果一个区域发生故障，剩余的区域是否能够承载你所需的运行状态？对于单区域故障，两个区域和三个区域都能满足目标。但第三个区域本身并不能使组件在同区域发生多个区域故障时具备更高的容错能力。
• 数据一致性和持久性：组件的正确性是否依赖于第三个故障域？多数派机制、共识算法、领导者选举、脑裂预防以及最高持久性目标通常会依赖于此。
• 成本和容量：在相同故障后性能目标下，两个区域和三个区域的恢复能力分布不同。应首先确定容错目标，再优化成本，而非反过来。

一个值得注意的细节：当同一区域中多个区域同时不可用时，问题通常已不再属于工作负载层面，而是演变为区域层面的问题：基础区域服务本身依赖于能够存活的区域。设计时超越单区域故障的场景，已进入灾难恢复领域，这需要不同的讨论。

初始参考：常见组件的典型选择

大多数组件通常属于几个类别之一。请将以下内容视为初步参考，而非支持矩阵。区域行为会因服务、SKU、层级、区域和配置而异，因此始终应根据服务自身的可靠性指南进行验证。

| 组件类型 | 典型区域决策 | | --- | --- | | 无状态计算、应用或网络组件（无持久化数据） | 根据剩余容量、路由、延迟和运维需求选择两个或三个区域。两者均可满足单区域故障目标。 | | 使用多数派、共识或领导者选举的状态系统 | 三个区域、第三个故障域，或特定产品见证模式，以避免脑裂和多数派丢失。 | | 需要最高持久性目标的三副本关键数据存储 | 通常需要三区域复制以达到预期的持久性级别。请验证服务的具体声明。 | | 其他状态资源 | 根据恢复时间目标（RTO）、恢复点目标（RPO）、持久性和故障转移行为，选择两区域、三区域或服务托管方案。 | | Azure 可为你实现区域冗余的任何组件 | 当服务托管的区域冗余满足需求时，请使用该方案。 |

何时两个区域就足够

两个区域并非妥协，而是对许多组件而言的正确选择：在完全满足单区域故障目标的同时，部署、测试和运维更为简单。当以下情况成立时，两个区域通常就足够：

• 该组件是无状态的或易于替换的，流量可以转移到存活区域。
• 主动-主动或主动-被动配对更易于理解和操作。
• 对延迟敏感的同步路径在经过测试的区域对中可以满足预算要求。
• 客户管理的区域设计已验证容量、故障转移、监控、恢复和故障回退。
• 在失去一个区域后，组件可以运行在经过批准的降级状态中。

无论选择哪种方案，都必须明确定义当某个区域失效时的具体应对措施：剩余容量、可接受的降级程度、数据一致性、故障转移行为、恢复步骤、可观测性，以及每个环节的责任归属。

三个区域为何必要

当两个区域无法在单区域故障期间或之后满足组件需求时，就需要三个区域。实际情况通常包括以下情况：

• 两区域设计中剩余区域无法维持故障后的运行状态
• 需要跨三个区域部署的持久性或复制机制：针对最高持久性目标的三副本部署
• 需要第三个故障域或见证节点的多数投票、共识或主节点选举设计，以避免丢失多数投票或发生脑裂

一个常被忽视的警告：即使是有经验的团队也容易犯错——三个副本不等于三个故障域。如果仅在两个区域部署多数投票系统的副本，当持有多数投票的区域失效时仍可能丢失多数投票。副本数量不等于副本分布策略。

对于中间类别也要坦诚面对：有些组件虽然不需要第三个区域，但通过增加区域可以提升容量分布、维护灵活性或运营冗余度。这是选择三个区域的合理理由。这与"否则系统将失效"的动机不同，需要明确记录具体适用的场景。

成本考量应放在最后

成本和运营复杂性确实存在，但它们应该在决策流程的最后阶段考虑，而非最初。不要因为成本因素放弃符合需求的双区域设计，也不要让成本成为不达标双区域设计的借口。反直觉的是，对于相同的故障后容量目标，三区域设计可能比双区域设计需要更少的总体容量，因为恢复冗余度被分散到更多区域。在优化前要建模这种权衡关系，对于可预测使用场景，可采用基于承诺的折扣方案如Azure savings plans或Azure Reservations，并确保所选方案确实具备可操作性：能够部署、监控、测试、故障转移、恢复和复盘。

• 每个关键流程都会被分解为支持它的组件。
• 每个组件都会评估资源可用性、数据一致性及持久性，以及对成本或容量的影响。
• 每个组件会被归类为服务托管的区域冗余、客户托管的双区域或必须的三区域组件。
• 在需要三个区域的场景中，驱动该决策的具体需求会被明确记录。
• 每个服务的区域支持情况会根据您实际使用的SKU、层级、区域和配置进行验证。
• 客户托管的区域资源具有经过验证的路由、负载均衡、复制、故障转移、监控、恢复和故障回退机制。
• 单个区域失效后剩余的容量和可接受的性能降级情况会被记录。
• 基于多数表决的组件会验证副本放置策略、见证节点或仲裁机制行为、领导者选举以及防止脑裂的措施。
• 对延迟敏感的路径会在实际部署的区域布局上进行测试。
• 安全性、身份验证、监控和数据保护要求会在整个设计中得到保持。
• 测试、事件响应、故障转移、故障回退和定期重新评估的职责会被明确分配。

细节之处体现专业性

区域冗余性不是一个可以为整个工作负载一次性设置的滑块，也不是可以照搬他人架构的数字。它是对系统每个部分需要承受多少故障的一系列有意识的组件级决策。专业性体现在有目的地做出每个决策、记录原因，并验证当区域实际失效时设计表现是否符合预期。

如果正确理解这一点，"双区域还是三区域？"就不再是争论的焦点。它会成为它本应是的样子：一个可以逐个组件进行辩护的答案。

• 支持可用性区域的 Azure 服务
• 为 Azure 工作负载启用区域冗余
• 区域资源与区域冗余
• 什么是 Azure 可用性区域
• 可用性区域和区域的架构策略