多可用区部署是什么
多可用区部署是把同一套业务同时放进同一个地域的两个及以上可用区：入口用负载均衡做健康检查和故障摘除，计算层每个可用区至少保有一份无状态实例，数据层依赖数据库的多可用区能力做跨 AZ 主备。它抵御的是单机房故障（断电、空调故障、机房网络割接），不抵御地域级灾难，后者要靠异地容灾。
基本信息
| 入口层 | 负载均衡开启主备可用区，后端服务器分布在两个 AZ |
|---|---|
| 计算层 | 无状态服务每个 AZ 至少一个实例，避免『表面双 AZ、实际单边承载』 |
| 数据层 | 云数据库高可用版/多可用区集群自动跨 AZ 同步主备并切换 |
| 自建数据库 | 需自行做主从、半同步与故障切换，切换后还要处理连接串变更 |
| 验证方式 | 定期做单 AZ 断网演练，验证切换耗时与剩余容量 |
落地步骤
- 先写清目标：RTO（允许多久不可用）与 RPO（允许丢多少数据）决定双 AZ 够不够，还是必须双地域
- 计算层按 AZ 均摊：实例数取偶数并分散到不同可用区，滚动发布时按 AZ 分批观察
- 数据层选对版本：购买时确认是多可用区/高可用版，单机版谈跨 AZ 没有意义
- 入口开双可用区：负载均衡自身的可用区属性决定它会不会变成新的单点
- 把切换写成可重复的操作手册，配合演练定期验证，而不是故障当天现查文档
典型双 AZ 拓扑（示意）
典型双 AZ 拓扑（示意）
LB（主 AZ-A / 备 AZ-B，健康检查摘除故障后端）
├─ ECS AZ-A 10.0.0.10
└─ ECS AZ-B 10.0.1.10
RDS 高可用版：主 AZ-A / 备 AZ-B（自动切换）
# 两个 AZ 的 ECS 必须属于同一个 VPC 才能内网互通收益与代价
| 维度 | 收益 | 代价 |
|---|---|---|
| 可用性 | 单机房故障业务不中断 | 实例基数至少翻倍 |
| 延迟 | 同 AZ 内网保持亚毫秒 | 跨 AZ 调用增加 1-3 毫秒 |
| 成本 | 减少一次故障带来的营收损失 | 跨 AZ 流量可能计费，实例数量上升 |
| 运维 | 可以做 AZ 级隔离的灰度发布 | 扩缩容要按 AZ 分池观察水位 |
核对 AZ 分布
核对 AZ 分布
aliyun ecs DescribeZones --RegionId cn-hangzhou # 确认可用区清单
aliyun ecs DescribeInstances --RegionId cn-hangzhou --ZoneId cn-hangzhou-i # 单 AZ 实例
aliyun slb DescribeLoadBalancers --RegionId cn-hangzhou # 看负载均衡主备可用区
# 演练前先核对备用 AZ 的实例与容量，切过去扛不住等于没容灾跨 AZ 内网互通的前提是资源在同一个 VPC 之内；跨账号、跨 VPC 的资源不能靠『选了同一个可用区』拼出高可用。
云数据库的高可用版本身跨 AZ 部署，开箱即用；自建 MySQL 要自己搭主从并处理故障切换与数据一致性，运维成本远高于直接买高可用版。
演练要验证什么
- 切换耗时是否符合 RTO：从注入故障到流量完全恢复的实际分钟数
- 剩余容量能否承载全量：把故障可用区的流量压到存活可用区，观察水位与错误率
- 数据是否一致：切换后核对主备差异、自增序列与唯一键冲突
- 外部依赖是否跟着切：缓存、消息队列、对象存储端点、第三方回调都要一起验证
- 回切路径是否可行：故障恢复后怎么把流量挪回去，同样要写进操作手册
同城双活与两地三中心的区别在故障范围：多可用区只能抵御单机房故障，真要抵御城市级灾难，还需要在另一个地域准备一套能够接管全量流量的环境，并验证数据复制方向与回切步骤。