高可用不是“把机器买两台”那么简单。真正的容灾设计要回答三个问题：故障的边界在哪里、切换需要多久、切换后容量还剩多少。很多架构在纸面上是双活，实际上切换一次就成了单点。
一、先搞清楚故障域的分层
云上的故障域从内到外大致是：单台虚机 / 容器 → 单个机架 → 单个可用区（AZ）→ 单个地域（Region）。设计时要逐层问：这一层挂了，业务会怎样？
- 单机故障：靠多副本 + 负载均衡解决，成本最低。
- 可用区故障：需要跨 AZ 部署，是生产系统的标配。
- 地域故障：需要跨地域容灾，成本高，只有核心业务才需要。
关键提醒：不是所有云产品都默认跨 AZ 高可用。云盘、数据库、负载均衡的高可用能力差异很大，选型时必须逐个确认，而不是假设“云就是高可用的”。
二、跨可用区部署的三种模式
| 模式 | 说明 | RTO | 适用场景 |
|---|---|---|---|
| 主备（Active-Standby） | 主机房承载全量，备机房热备 | 分钟级 | 数据库、有状态服务 |
| 双活（Active-Active） | 两侧同时承载流量 | 秒级 | 无状态应用、网关层 |
| 单元化（Cell） | 每个单元自带全链路能力，流量按用户维度拆分 | 秒级 | 超大流量、强隔离要求 |
双活听起来美，但它对数据层的要求很高：要么数据能双向同步且冲突可解，要么把有状态部分集中到主备架构。很多项目卡就卡在“应用双活了，数据库还是单点”。
三、容量：切换后能不能接住
这是最容易被忽略的一环。两个 AZ 各部署一半容量，平时各承担 50% 流量；一旦一个 AZ 挂掉，剩下的 AZ 要单独承担 100%。如果平时就是按 50% 设计的，切换瞬间必然雪崩。
务实的做法有两种：一是按 N+1 设计，即每个 AZ 都具备承担全量的能力，平时利用率只有一半；二是接受降级，提前定义好非核心功能可以先关掉，保证主链路可用。
无论哪种，都必须提前确认依赖的外部服务是否也具备同等冗余——比如认证中心、短信网关、第三方支付，这些往往是真实的短板。
四、故障演练：不演练就等于没有容灾
容灾方案最大的风险是“从没真正切换过”。建议按以下节奏推进：
- 桌面推演：团队对着架构图过一遍故障场景和处置步骤，成本最低，能暴露大部分流程问题。
- 单点演练：手动下线一个实例、一个 AZ，验证流量切换与告警是否正常。
- 混沌工程：在生产环境注入随机故障，持续验证。前提是已具备完善的监控和快速回滚能力。
演练必须记录两个指标：实际 RTO（从故障注入到业务恢复的真实耗时）和数据丢失量（RPO）。这两个数字才是有意义的容灾指标，而不是架构图上标的“秒级切换”。
五、监控是容灾的神经系统
没有监控的高可用等于自动驾驶没有传感器。至少需要三层监控：基础设施层（节点、网络）、应用层（错误率、延迟、饱和度）、业务层（下单成功率、支付转化率）。
更关键的是告警要有明确的人负责。没有值班表和升级路径的告警，本质上只是日志。
高可用是一项工程能力，而不是一次架构改造。能说清楚“我们能扛住什么、扛不住什么、多久能恢复”的团队，才算真正拥有了它。
