多地域多活架构的可靠性设计
概述 当你的业务从"服务一个城市"扩展到"服务全国"甚至"服务全球"时，单机房架构会遇到两个硬约束：距离带来的延迟和单点故障的风险。多地域多活架构是解决这两个问题的工程方案。 但多活架构是 SRE 领域最复杂的主题之一——它不是简单的"在两个机房部署服务"，而是涉及数据一致性、流量调度、故障切换、运维复杂度等一系列深层工程挑战。做对了，系统可用性从 99.9% 提升到 99.99%；做错了，多活架构本身就会成为最大的故障源。 从多活架构模式、数据一致性挑战、流量切换策略、容灾 RTO/RPO 设计、跨地域监控到故障切换演练，详细梳理多活架构的可靠性设计。 关于多活架构的深入讨论，可参考 Google SRE Book - Disaster Preparedness 和 AWS - Multi-Region Active-Active Architecture。 一、为什么需要多活架构 单机房架构的局限 单机房架构： ┌── App Server ×N 用户 ──→ DNS/CDN ──→ Load Balancer ─────┼── App Server ×N └── App Server ×N │ ┌─────────┴─────────┐ │ Database (主从) │ └───────────────────┘ 问题： 1. 如果机房断电/网络中断 → 全站不可用 2. 跨地域用户延迟高（北京到广州 ~30ms RTT） 3. 容量受限于单个机房 多活架构的驱动力 驱动力 说明 优先级 容灾 机房级故障时业务不中断 高 低延迟 就近服务用户，降低访问延迟 高 容量扩展 突破单机房容量上限 中 合规要求 数据必须在特定地域存储 视行业 容灾演练要求 监管要求具备跨机房容灾能力 视行业 容灾的关键指标 在设计多活架构之前，必须先明确两个容灾指标：...