一次云故障引发的架构反思

过去两年，多家主流云厂商相继发生大规模故障，一些「两地三中心」架构的企业同样未能幸免——原因很简单：两个「地」可能在同一朵云上。当业务连续性要求进入「分钟级」时代，企业开始重新审视一个尖锐问题：如果整个云厂商不可用，我的业务还能跑吗？多云多活因此从技术圈的话题上升为治理层的议题。

演进逻辑与代价

• 两地三中心（同云）：价值在于抵御机房级故障，架构成熟、实施经验丰富。局限在于无法抵御「云厂商级」故障，且传统的主备切换存在数据丢失窗口与切换演练不足的风险。
• 多云双活/多活：流量同时接入多家云，故障时自动切换，理论上可用性最高。但代价显著：应用需要抽象层屏蔽云差异、数据需要跨云同步（延迟与一致性成本）、运维复杂度翻倍、安全管控面扩大。
• 务实的分层多活：并非所有系统都需要多云——按业务重要性分层：核心交易系统采用多云双活（甚至三活），重要系统保持同城双活 + 异地灾备，一般系统维持单云 + 备份。把有限的复杂度预算花在刀刃上。

决策建议

启动多云多活评估前，先回答三个问题：业务连续性的真实目标（RTO/RPO 是多少分钟）？单云故障的历史损失有多大？团队是否有能力运维两套云环境？如果答案支持多云，建议从「数据层双写 + 读流量分流」开始渐进验证，而不是一开始就追求全链路双活——容灾架构的价值在故障时才显现，而它的代价每天都在支付。