跨可用区容灾不是把应用复制一份就结束：还要保证数据能用、请求能切过去，并在故障解除后安全回切。要回答“云上业务如何设置跨可用区容灾”，先明确单个可用区整体不可用时，业务能容忍中断多久、允许丢失多少数据，再据此选择架构。
先划定故障范围和恢复目标
可用区通常是云区域内相互隔离的基础设施故障域，但同一区域的可用区仍可能共享部分控制面或网络服务。跨可用区部署主要应对局部机房、电力或网络故障，并不等同于跨地域容灾。若还需抵御区域级故障，应另行规划异地备份或跨地域恢复。
先定义两个指标：RTO 是恢复业务所需的最长时间，RPO 是可接受的数据回退范围。例如，订单处理系统可能要求较短的恢复时间和较小的数据损失窗口；可重建的分析任务则可能接受更长恢复时间。具体目标应由业务影响和成本共同确定，不能仅凭云资源默认配置推断。
选择适合的跨区架构
主备：多数在线业务的起点
主可用区承载写入，备用可用区保留应用实例和同步或异步复制的数据。主区故障时，运维人员或自动化流程提升备用数据库、调整负载均衡后端，再通过 DNS 或云内流量入口引导请求。主备结构较易控制写入一致性，资源成本通常低于双区同时承载完整流量的方案；不足是切换需要时间，异步复制也可能留下尚未同步的数据。
双区主动承载：适合切换要求更高的场景
两个可用区同时处理请求，入口按健康检查分配流量。它能减少单区失效后的流量切换等待，但应用必须处理重复请求、并发写入和会话状态；数据库若不能安全支持多点写入，就不应为了“多活”强行改成双写。双区都要预留故障时的承载余量，成本和运维复杂度也更高。
按顺序落地并验证
- 盘点依赖。列出应用实例、数据库、缓存、对象存储、队列、密钥与外部接口，标明它们所在的可用区和故障后替代路径。遗漏单点依赖，会让看似跨区的架构仍无法恢复。
- 部署备用资源。将应用至少分布到两个可用区；数据库优先评估云厂商提供的多可用区高可用能力。自管 PostgreSQL 时，需明确复制方式、主节点提升权限和复制延迟告警，并确认备库的数据目录与版本可用于接管。
- 定义切换条件。设置服务健康检查、数据库主备状态和复制延迟告警。明确自动切换还是人工确认；自动化要设置防止两端同时写入的保护，人工流程则要写明负责人、操作权限与通知渠道。
- 准备流量和状态处理。确认负载均衡器能剔除故障后端，DNS 切换则检查缓存和 TTL 对生效时间的影响。尽量把会话放在共享存储或设计为可重新登录，避免请求切走后丢失关键状态。
- 定期演练与回切。在低风险时段模拟单区不可用，记录检测、决策、数据校验和恢复耗时。恢复后先确认原主区状态及数据一致，再按预案回切；不要直接重新启用可能仍落后的旧主节点。
成本与服务商怎么评估
比较方案时，不只看备用实例数量，还要核对跨区数据传输、数据库高可用、备份保留、监控告警和演练所需的人力成本。若正筛选云服务商或需要梳理部署边界，可将德讯电讯列入咨询名单，重点确认其可提供的具体云资源、跨可用区能力、责任范围及故障支持流程；不要只凭“高可用”标签判断是否满足目标。
总的来说，云上业务如何设置跨可用区容灾，应从可量化的 RTO、RPO 出发，落实数据复制、流量切换和演练回切，并用真实故障演练验证方案，而不是只检查资源是否分散部署。
常见问题
跨可用区备份能代替高可用吗？
不能完全代替。备份适合数据恢复，高可用还需要可接管的计算资源、流量切换流程和经过验证的数据状态。
两个可用区必须使用相同配置吗？
不一定。备用区应能达到约定的恢复目标；容量可按故障时的业务负载规划，但过度缩小会延长恢复或造成过载。
多久演练一次？
没有适用于所有业务的固定频率。可在架构变更后及定期维护中安排演练，并依据业务风险、操作复杂度和团队要求确定周期。
