2. Azure 区域与可用性区域基础

在讨论多区域高可用与灾备之前，必须先厘清 Azure 中四个容易混淆但层级完全不同的概念：地理区域（Geography）、区域（Region）、可用性区域（Availability Zone）和区域对（Region Pair）。它们不是同义词，而是从大到小、从物理到逻辑的四层结构。选错层级，后续的 SLA 目标、复制策略和故障切换设计都会失去依据。

四层结构：从地理区域到可用性区域

地理区域是最高层级，通常对应一个政治或数据主权边界，例如“中国”“欧洲”“美国”。它的核心作用是界定数据驻留与合规范围：数据默认不会跨地理区域流动，除非你显式配置。一个地理区域内包含多个区域，区域是部署资源的基本单位，每个区域由一组独立的数据中心组成，拥有独立的电力、冷却和网络接入。例如“中国北部”“东亚”“西欧”都是区域。

区域之下是可用性区域。可用性区域是区域内物理隔离的数据中心组，每个区域通常有 3 个可用性区域（部分区域为 2 个或更多）。它们之间通过低延迟网络互联，但电力、冷却和网络入口相互独立。这意味着单个可用性区域故障（如断电、水浸、网络中断）不会影响同区域内的其他可用性区域。可用性区域是抵御数据中心级故障的最小单元。

最后是区域对。区域对是同一地理区域内两个区域之间的固定配对关系，例如“东亚—东南亚”“中国北部—中国东部”。区域对的价值在于：Azure 会优先在配对区域内进行平台更新和故障恢复，且部分服务（如异地冗余存储 GRS）默认将数据复制到配对区域。区域对不是可用性区域的替代，而是跨区域灾备的默认拓扑。

故障域与更新域：两种不同的隔离维度

理解可用性区域之后，还需要区分两个常被混用的概念：故障域（Fault Domain）和更新域（Update Domain）。它们描述的是同一物理资源上两种不同的隔离维度。

故障域解决的是“一起坏”的问题。同一故障域内的硬件共享相同的电源、网络交换机或机架，因此一个故障域内的故障可能同时影响其中所有资源。可用性区域本身就是最高层级的故障域划分：AZ1 和 AZ2 不会因为同一台交换机故障而同时离线。在单个可用性区域内部，Azure 还会进一步划分更细的故障域，用于虚拟机规模集等场景。

更新域解决的是“一起重启”的问题。Azure 平台在进行主机操作系统补丁、固件升级等维护操作时，会按更新域分批执行，同一时刻只重启一个更新域中的资源，从而保证服务不中断。默认情况下，一个可用性区域内通常有 5 个更新域（具体数量由平台决定，不应硬编码）。故障域是空间维度的隔离，更新域是时间维度的隔离，两者共同构成可用性区域内部的韧性基础。

如何为多区域架构选择合适区域

选择区域不是简单地“选两个离用户近的”，而需要同时权衡以下因素：

• 合规与数据驻留：确认业务数据是否允许离开当前地理区域。如果要求数据不出境，区域对必须选在同一地理区域内。
• 服务可用性：并非所有 Azure 服务都在所有区域提供。例如某些 GPU 机型、特定数据库层级或可用性区域支持可能只在部分区域可用。部署前应查阅目标区域的服务可用性列表。
• 延迟与用户分布：主区域应靠近主要用户群，配对区域用于灾备。跨区域复制延迟通常在几十毫秒到几百毫秒之间，具体取决于区域间距离和链路质量。
• 区域对关系：优先选择 Azure 定义的区域对，因为平台会优先保障配对区域间的恢复顺序，且 GRS 等服务的默认复制目标就是配对区域。
• 容量与配额：目标区域是否有足够的 vCPU 配额、公共 IP 配额和存储账户限制，需要在架构设计阶段确认。

以一个面向中国东部用户的 Web 应用为例：主区域选择“中国东部”，灾备区域选择其区域对“中国北部”。应用层部署在两个区域的各三个可用性区域中，数据层使用 GRS 存储账户自动复制到配对区域。这样，单个可用性区域故障时，同区域其他 AZ 继续服务；整个区域故障时，切换到配对区域。这个选择同时满足了合规（数据不出地理区域）、延迟（主区域靠近用户）和灾备（区域对自动复制）三个要求。

选择区域的检查清单