这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
完整系统
完整的异地容灾系统不是单个技术组件，而是一套覆盖目标、架构、数据、切换、演练和组织流程的体系。
业务分级 -> RTO/RPO -> 多机房架构 -> 数据同步
-> 健康检查 -> 故障切换 -> 数据校验 -> 回切与复盘最终架构
一个可落地的热备容灾架构可以这样设计：
- 主机房承载主要写流量。
- 备用机房长期部署同版本服务，并承载少量影子或只读流量。
- 数据库通过日志复制同步到备用机房。
- 对象存储开启跨区域复制。
- 消息系统保留幂等消费和重放能力。
- 全局流量调度根据健康状态切换入口。
- 监控系统持续观察主备延迟、服务健康和业务指标。
- 容灾预案通过定期演练验证。
这不是最高级的多活架构，但对很多业务来说，它比只画一个备用机房可靠得多。
关键决策
- RTO/RPO 先于技术选型：不知道恢复目标，就无法判断方案是否足够。
- 主备还是多活：主备简单可控，多活复杂昂贵；是否多活取决于业务写入模型和成本承受能力。
- 同步还是异步复制：同步复制降低 RPO，但增加延迟和可用性风险；异步复制要接受数据丢失窗口。
- 自动切换还是人工确认：机房级切换建议自动化执行、人工确认，避免误切。
- 切换后是否全功能可用：容灾优先保核心链路，非核心功能可以降级。
指标体系
容灾系统要持续监控：
- 主备复制延迟。
- 最近一次成功同步时间。
- 备用机房服务健康度。
- 全局流量调度状态。
- 核心业务成功率。
- RTO/RPO 演练达标率。
备用机房平时不出问题，不代表事故时可用。只有这些指标持续健康，团队才有切换信心。
上线检查清单
- 核心业务是否定义 RTO 和 RPO？
- 是否明确哪些系统必须容灾、哪些可以延迟恢复？
- 备用机房是否部署同版本服务和配置？
- 数据库、缓存、对象存储、消息是否都有同步或重建方案？
- 是否有一键或自动化切换脚本？
- 切换前后是否有核心链路验证清单？
- 是否定义降级策略和回切流程？
- 是否定期演练并复盘问题？
- 是否有对账和补偿机制处理数据差异？
课程总结
容灾设计的本质是业务连续性管理。它要求工程团队提前承认故障一定会发生，并把恢复目标、架构能力、数据策略和组织流程都准备好。
设计容灾系统时，始终回到四个问题：
- 这个业务能停多久？
- 最多能丢多少数据？
- 故障时谁来决策、如何切换？
- 我们是否演练过，并能证明它有效？
能回答并验证这些问题，系统才真正具备异地容灾能力。