跨可用区容灾不是简单地把服务器复制一份，而是要确保一个可用区发生故障时，业务、数据和流量都能转到另一个可用区。设计云端业务跨可用区容灾方案，先明确可接受的数据损失和恢复时间，再安排应用部署、数据复制与切换流程。
先定恢复目标，再选架构
先写清两个指标：RPO代表最多能接受丢失多少时间内的数据，RTO代表业务中断后希望多久恢复。目标越严格，通常越需要更及时的数据复制和自动化切换，但成本、链路要求及运维复杂度也会上升。没有适用于所有业务的统一数值，应结合交易频率、数据重要性和预算确定。
常见做法是主备架构：主实例在一个可用区处理请求，备用实例在另一个可用区同步或异步接收数据。以 PostgreSQL 为例，可使用流复制维护备用节点；同步复制更有利于减少已确认事务的数据损失，但可能增加写入等待，并受网络延迟影响。异步复制通常对主库写入影响较小，却可能在故障时损失尚未复制的数据。
云端业务跨可用区容灾方案还要区分单区故障与整区服务中断。跨可用区部署主要覆盖区域内单个可用区故障，并不等同于跨地域容灾；如果业务还需应对整个云区域不可用，应另行设计跨地域备份或复制。
按依赖关系搭建，而非只复制主机
应用节点、数据库、文件与任务处理组件都要纳入故障范围。将无状态应用部署到两个可用区，并配置负载均衡健康检查；数据库采用跨区主备；上传文件等持久数据使用具备相应冗余或复制能力的存储服务。还要检查消息队列、证书、密钥、配置和后台任务，避免它们仍依赖故障区内的单点资源。
实施步骤：先准备，再切换
- 画出依赖清单。列出入口、应用、数据库、存储、队列及外部服务，并标注所在可用区和故障后替代路径。
- 确定切换策略。选择自动或人工故障切换。自动切换恢复较快，但要防止短暂网络异常造成误判；人工切换更便于确认状态，响应速度则取决于值班流程。
- 配置备用资源。在另一个可用区准备应用容量、数据库副本和必要配置。备用容量要按故障后预计流量核算，不要只验证资源“存在”。
- 设定切换条件。结合健康检查、数据库复制状态和业务探测判断是否切换，并明确谁有权执行、如何确认主备角色，避免双主写入。
- 验证回切流程。故障恢复后先确认数据一致、复制正常，再按预案迁回或重建主备关系；不要把恢复原区等同于立即回切。
演练要测出真实恢复能力
云端业务跨可用区容灾方案应通过受控演练验证，而不是只看控制台显示的健康状态。可在维护窗口模拟应用节点不可用，检查流量是否转移；再测试数据库主备切换，核对应用能否重新连接、写入是否恢复、复制延迟是否符合预设RPO。演练前备份关键数据、通知相关人员并准备停止条件，避免把测试故障扩大为生产事故。
记录故障发现、批准切换、服务恢复和数据核验各自耗时。若实际RTO超出目标，优先检查告警是否及时、备用资源是否就绪、切换步骤是否依赖人工操作。演练结果、操作人和遗留问题都应留档，并在架构或业务变更后重新验证。
常见问题
跨可用区部署能做到零数据丢失吗？
不能一概而论。是否接近零丢失取决于数据库复制模式、确认机制、故障类型和业务写入路径，需通过配置评估和演练验证。
备用区需要始终运行全部应用吗？
不一定。常驻备用可缩短恢复时间但成本较高；按需扩容更节省资源，却会增加启动与扩容耗时，需与RTO目标匹配。
多久演练一次？
按业务风险和变更频率制定周期。架构、数据库版本或切换流程发生重要变化时，应安排复测，而不只依赖固定日历。
归根结底，云端业务跨可用区容灾方案要同时证明数据能接续、流量能切换、人员能执行。把目标写成可测指标，并持续演练，才能判断方案是否真正满足业务需要。