2. Azure区域与可用性架构

Azure的全球基础设施并不是一张“云”的平面图，而是一套按物理边界逐层收敛的容错体系。理解这套体系的关键，是分清四个概念各自解决什么级别的故障：区域（Region）解决地理级隔离，可用性区域（Availability Zone）解决同一区域内单座数据中心级故障，可用性集（Availability Set）解决同一数据中心内机架与主机级故障，配对区域（Region Pair）解决跨地理的灾难级恢复。选错层级，冗余就会落在错误的故障域上。

一、区域：故障域与合规边界的第一层

区域是一组部署在特定地理范围内的数据中心集群，通过低延迟、高带宽的专用网络互联。每个区域独立拥有计算、存储、网络与身份控制平面，因此一个区域内的服务中断通常不会波及其他区域。区域同时是数据驻留与合规的边界：选择“中国北部”“西欧”还是“美国东部”，决定了数据落地的司法辖区、可用服务清单以及可选的配对区域。

区域内部署资源时，需要区分三类资源的作用范围：区域性资源（如虚拟机、虚拟网络、存储账户）部署在某个具体区域；区域冗余资源（如区域冗余存储 ZRS）在同一区域内的多个可用性区域间自动复制；全局资源（如 Azure Front Door、流量管理器、Microsoft Entra ID）跨区域存在，不绑定单一区域。业务连续性设计的第一步，就是识别哪些组件是区域性的单点。

二、可用性区域：同一区域内的物理隔离

可用性区域是区域内物理上独立的数据中心组，每个区域拥有独立的供电、冷却和网络。区域内的可用性区域之间通过高带宽、低延迟的光纤互联，往返延迟通常在个位数毫秒量级，因此可以支撑同步复制。可用性区域用逻辑编号 1、2、3 表示，但逻辑编号到物理数据中心的映射在每个订阅中并不相同——这是为了避免所有租户把主副本集中到同一座建筑。

可用性区域主要服务于两类场景：一是高可用，把同一应用的多个实例分散到不同区域，单座数据中心断电时业务仍可继续；二是同步数据复制，例如区域冗余存储 ZRS 在三个可用性区域间同步写入，或 Azure SQL 数据库的业务关键层使用可用性区域做同步副本。需要注意的是，并非所有区域都支持可用性区域，也并非所有服务都支持区域级部署，选型前必须核对目标区域的服务可用性矩阵。

三、可用性集：数据中心内部的机架级容错

可用性集是可用性区域出现之前的主力机制，至今仍在单区域、单数据中心场景中广泛使用。它通过两个维度约束虚拟机分布：故障域（Fault Domain）对应共享同一电源与网络交换机的物理机架，默认最多 3 个；更新域（Update Domain）对应可同时重启维护的一组主机，默认最多 5 个（最多可配置 20 个）。把虚拟机放入同一可用性集，Azure 会尽量把它们分散到不同故障域和更新域，从而在单机架故障或平台维护时保留至少部分实例在线。

可用性集的关键限制在于：它只提供数据中心内的容错，无法抵御整座数据中心失效；同时可用性集与可用性区域互斥，虚拟机不能同时属于两者。此外，可用性集内的虚拟机必须使用托管磁盘或同一存储账户下的非托管磁盘，且创建后无法把已有虚拟机加入可用性集——这要求部署前就完成架构决策。

四、配对区域：跨地理的灾难恢复单元

Azure 为大多数区域指定了固定的配对区域，例如“美国东部”与“美国西部”、“东南亚”与“东亚”、“中国北部”与“中国东部”。配对区域通常位于同一地理或地缘政治边界内，彼此相距数百公里，以降低同时受大规模灾害影响的概率。配对关系带来三项实际收益：平台更新分批进行，同一时刻只更新配对中的一个区域，降低双区域同时中断的风险；异地复制服务优先，如地理冗余存储 GRS 默认复制到配对区域；恢复优先级，发生大范围故障时，配对区域中的一方会被优先恢复。

配对区域并不等于自动灾备。它只是提供了物理与调度层面的基础，真正的恢复能力仍取决于数据复制方式（同步或异步）、恢复点目标（RPO）、恢复时间目标（RTO）以及应用是否具备跨区域切换能力。对于要求 RPO 接近零的核心交易系统，通常采用“区域内可用性区域同步 + 跨区域异步复制”的组合；对于可容忍分钟级数据丢失的分析类负载，跨区域异步复制即可满足。

五、不同架构对业务连续性的实际影响

把上述四层组合起来，可以形成几种典型架构，其容错能力与成本差异明显。以下参数为教学示例，用于说明量级关系，实际数值需以目标区域的服务等级协议和实测为准。

从表中可以看出，可用性集与可用性区域解决的是“可用性”，配对区域解决的是“灾难恢复”，两者不能互相替代。一个常见误区是：把三台虚拟机放进可用性集就认为已经具备灾备能力，实际上整座数据中心失效时三台虚拟机同时不可用。另一个误区是：只做跨区域异步复制，却忽略了区域内单点——如果主区域只有一个实例，区域内部一次机架故障就会触发跨区域切换，而跨区域切换的 RTO 通常远高于区域内切换。

六、架构选型的判断顺序

实际设计时，建议按以下顺序收敛决策，而不是先选服务再补冗余：

1. 先定业务连续性目标：明确每个业务系统的 RTO 与 RPO。RTO 在分钟级以内、RPO 接近零的系统，必须使用可用性区域同步复制；可容忍小时级中断的系统，跨区域异步复制即可。
2. 再定故障域层级：需要抵御机架故障用可用性集，需要抵御数据中心故障用可用性区域，需要抵御区域灾难用配对区域。层级一旦确定，资源类型随之确定。
3. 核对区域与服务可用性：确认目标区域是否支持可用性区域、是否支持所需的存储冗余类型（LRS/ZRS/GRS/GZRS），以及配对区域是否在合规允许的地理范围内。
4. 验证切换路径：灾备架构的价值在于切换是否真的可行。应定期演练跨区域故障转移，记录实际 RTO，并检查 DNS 解析、流量管理器优先级、数据库故障转移组、密钥与证书是否在目标区域可用。

总结来看，Azure 的区域与可用性架构本质上是一套按故障域分层的设计语言：区域定义地理与合规边界，可用性区域定义数据中心级隔离，可用性集定义机架级隔离，配对区域定义跨地理恢复单元。业务连续性的质量，取决于是否把冗余放在了与目标故障域一致的层级上，并通过演练验证切换路径真实可用。