选择跨可用区和区域的可用性方案

从用户操作开始

高可用性（HA）旨在让服务在组件故障时仍可使用。选择架构前先定义“可使用”。如果预订页面能加载，但所有预订请求都失败，这就不是可用的预订服务。

为重要操作设置服务级别目标（SLO）。定义哪些请求计入、怎样算成功，以及测量周期。云服务 SLA 描述的是提供方的承诺，不能证明应用实测的可用性。

例如，在一个 30 天的月份中，按时间计算的 99.9% 可用性允许 43.2 分钟不可用。按请求计算的 SLO 使用不同分母。两种指标都不能说明允许丢失多少数据，也不能保证单次故障的最长持续时间。

AWS 可用区（Availability Zone，AZ）是区域（Region）内隔离的基础设施位置。一个区域包含多个可用区。多区域设计将工作负载组件分布到不同区域。其他提供方有自己的边界和服务行为，应检查所选服务。

这些是设计可能性，不是可用性保证。标签不能证明每个必需组件都遵守预期边界。

考虑一个虚构预订服务。Web 副本运行在两个可用区，都使用可用区 A 中的同一个数据库和同一个出站网关。调用付款提供方必须经过该网关。

如果可用区 A 故障，可用区 B 中的 Web 副本可能仍然健康，但预订仍会失败。团队必须评估数据库、网络路径、身份提供方、付款依赖和路由。检查托管数据库的实际模式：复制、故障转移和读取行为会因产品与配置而不同。

也要检查容量。存活资源必须能够处理所需负载。如果设计依赖在事件期间创建容量，就会受到配额、可用资源和控制平面操作的影响。

开展受控演练，明确边界、停止条件和负责人。验证完整预订，包括付款对账。记录失败请求，以及恢复有效业务操作所需的时间。

多区域运行会增加数据传输、重复资源、部署协调和运维工作。主备模式让一个环境随时准备接收流量。多活模式则在多个环境中同时处理流量。两种模式要求的准备程度和数据行为不同。

对于预订服务，并发写入带来一个问题：两个区域能否售出同一个座位？明确预订的决定权，以及复制中断时的行为。“复制数据库”不是完整答案。

检查允许的数据位置、加密密钥、证书、DNS、秘密信息和外部服务。共同依赖的身份服务故障，或一次错误发布，都可能影响多个区域。更多位置不能消除每一种共同原因。

HA 应对运行期间指定的故障。灾难恢复则在业务受扰事件后，恢复可用服务及其数据。多区域服务仍需要针对误删或数据损坏的恢复计划。

记录选定的故障场景，以及业务方接受的其他场景。应用变化时，让测试和基础设施定义保持一致。继续学习 RTO、RPO 与灾难恢复。