1. 课程导入与架构全景

在开始设计任何跨区域架构之前，必须先回答一个根本问题：我们究竟在防什么、要保什么、能容忍多大的损失？Azure 的多区域高可用与灾备（Disaster Recovery，DR）并不是简单地"把资源复制到另一个区域"，而是一套围绕业务连续性目标、由全球基础设施能力支撑、通过明确设计原则约束的系统工程。本节先建立三个基础认知：业务目标如何量化、Azure 全球基础设施提供哪些可用的"积木"、以及整体架构应遵循哪些原则。

一、从业务目标出发：SLA、RTO 与 RPO

高可用与灾备的讨论必须从可量化的目标开始，否则架构选型会失去判断依据。三个最核心的指标是 SLA、RTO 和 RPO，它们回答的是不同层面的问题。

SLA（Service Level Agreement，服务级别协议）是 Azure 对单项服务可用性的承诺，通常以"每月可用性百分比"表示。例如某服务的 SLA 为 99.9%，意味着每月允许的不可用时间约为 43.2 分钟；99.95% 约为 21.6 分钟；99.99% 约为 4.32 分钟。需要特别注意的是，SLA 是服务商承诺，不是业务目标。业务的实际可用性由架构决定，而复合 SLA 会随依赖链拉长而下降——如果应用同时依赖计算、数据库和存储三项 99.9% 的服务，且任一故障都会导致整体不可用，那么理论复合可用性约为 99.7%，而不是 99.9%。这正是需要多区域冗余的数学原因。

RTO（Recovery Time Objective，恢复时间目标）回答"业务能容忍中断多久"，即从故障发生到服务恢复可用的最长时间。RTO 决定了恢复方式是自动故障转移（秒级到分钟级）、手动切换（分钟到小时级）还是从备份重建（小时到天级）。

RPO（Recovery Point Objective，恢复点目标）回答"业务能容忍丢失多少数据"，即故障发生时允许丢失的数据时间窗口。RPO 决定了数据复制方式：同步复制 RPO 接近 0，但受网络延迟约束；异步复制 RPO 通常为秒级到分钟级，取决于复制频率和网络状况。

三者之间存在成本与复杂度的权衡关系：RTO 和 RPO 越接近 0，所需的热备资源、同步复制链路和自动化程度越高，成本也越高。因此架构设计的第一步不是选技术，而是与业务方共同确定这三个数值，并明确哪些系统属于关键路径、哪些可以降级运行。

二、Azure 全球基础设施：区域、可用性区域与配对区域

Azure 的全球基础设施为高可用与灾备提供了三个层级的容错单元，理解它们的物理含义和故障边界是架构设计的前提。

区域（Region）是 Azure 部署的基本地理单元，每个区域包含一组数据中心，通过低延迟网络互联。区域之间通常相隔数百公里以上，用于抵御区域性灾难（如地震、大规模停电、区域级网络中断）。选择区域时需考虑：目标用户的地理位置、数据驻留与合规要求、区域内可用服务清单（并非所有服务在所有区域都可用）、以及区域间的网络延迟。

可用性区域（Availability Zone）是区域内的物理隔离单元，每个可用性区域拥有独立的供电、冷却和网络。同一区域内的多个可用性区域之间延迟通常低于 2 毫秒，适合部署同步复制的冗余。可用性区域主要防御的是单数据中心级别的故障，例如机房断电、制冷失效或局部网络问题。需要注意的是，并非所有区域都支持可用性区域，部署前必须确认目标区域的能力。

配对区域（Region Pair）是 Azure 为同一地理区域（如"东亚"与"东南亚"、"美国东部"与"美国西部"）内两个区域建立的固定配对关系。配对区域之间具有若干重要特性：更新采用分阶段推出，避免同一时间两个区域同时接受平台更新；在发生大规模灾难时，配对区域中的一方会被优先恢复；部分服务（如 Azure 地理冗余存储 GRS）的跨区域复制默认以配对区域为目标。配对区域为跨区域灾备提供了一个"默认推荐"的部署方向，但它不是唯一选择，业务仍可根据延迟和合规要求选择非配对区域。

下面这张图展示了从业务目标到基础设施容错层级的整体关系，以及各层级对应的典型故障范围和恢复手段。

三、整体架构设计原则

有了目标和基础设施认知之后，架构设计需要遵循若干原则，避免常见误区。

第一，目标驱动而非技术驱动。先确定每个业务系统的 RTO/RPO 和可用性目标，再选择部署拓扑。一个 RTO 为 4 小时、RPO 为 15 分钟的内部报表系统，不需要跨区域同步复制和自动故障转移；而一个 RTO 为 1 分钟、RPO 接近 0 的支付系统，则必须考虑多区域主动-主动或热备架构。

第二，分层冗余，逐级防御。可用性区域解决单机房故障，配对区域解决区域级灾难，二者是互补而非替代关系。一个稳健的架构通常先在区域内跨可用性区域部署，再在配对区域建立灾备。跳过可用性区域直接做跨区域，会导致区域内单点故障仍然存在，且跨区域切换成本更高。

第三，故障隔离与爆炸半径控制。通过将组件部署在独立的故障域中，限制单个故障的影响范围。例如将前端、应用层和数据层分别跨可用性区域部署，避免一个区域的故障同时影响所有层。同时要识别共享依赖——如果两个"冗余"区域共用同一个身份验证服务或 DNS 解析路径，那么该共享依赖就是实际的单点。

第四，自动化切换与人工决策的边界。RTO 越短，越依赖自动化故障转移。但自动化也带来风险：误判导致的"脑裂"或非必要切换可能造成更大损失。实践中通常采用"自动检测 + 分级响应"：区域内部故障自动转移，跨区域切换设置明确的触发条件和人工确认环节（除非 RTO 要求必须全自动）。

第五，持续验证。灾备方案不经过演练就无法确认其有效性。建议定期执行故障注入测试（如模拟可用性区域不可用、强制切换数据库主副本），记录实际 RTO 和 RPO，与目标对比并修正架构。未经验证的 DR 方案在真实故障中往往表现远低于预期。

四、一个可参考的目标定义示例

下面给出一个示例性的目标定义表，用于说明如何把业务语言转化为架构约束。表中数值为教学示例，实际项目需根据业务调研确定。