网站别只放一台机器上：ELB 与多可用区入门

网站跑得好好的，直到某天机器重启、系统更新、或者机房出了点状况，页面就打不开了。你登上控制台看，ECS 还在，服务进程也没报错，可用户那边就是一直转圈。做活动时更明显：流量一上来，单台机器响应越来越慢，最后连后台都登不进去。这类问题反复出现，调配置、加内存都只能缓解一阵子，因为瓶颈根本不在单台机器的性能上。问题不是配置没调好，是所有请求都压在一台机器上，它一停就没有任何东西能接住。

一、什么叫「单点」，先能判断

单点就是：整个服务只有一份，它一停，全站就停。

哪怕这台机器配置再高、代码写得再好，只要它是唯一的，重启、宕机、磁盘满、被误删，都会变成全站不可用。判断方法很简单——问自己一句：把这台机器关掉，用户还能访问吗？ 答案是否，就是单点。

改造前                              改造后
                                    
用户 ──▶ ECS（唯一一台）            用户 ──▶ 弹性负载均衡 ELB
         └─ 挂了 = 全站挂                    ├─▶ ECS-1（可用区 1）
                                            └─▶ ECS-2（可用区 2）
                                                 └─ 挂一台，另一台继续服务

几个词各解释一句：

ELB 本身由云平台托管，不需要你自己再装一台 Nginx 去转发——这也是它比自建转发更省事的地方。自建方案还得考虑「转发用的那台机器自己挂了怎么办」，等于又引入一个新的单点；托管型负载均衡把这层责任交给了平台。

另外要区分两个容易混的东西：负载均衡分发的是请求，不是数据。它不会帮你同步两台机器上的文件、也不会同步数据库。两台 ECS 上的代码和静态资源必须一致，通常靠同一份镜像或部署脚本保证，这一点在下一篇讲流水线之前先手工保持一致即可。

二、动手前的准备

2.1 确认网络已经按第 12 篇建好

这一篇不重复建 VPC 和子网的步骤。你只需要确认两件事：

• 有一个 VPC，里面有两个挂在不同可用区的子网
• 两个子网在同一个 VPC 内，默认路由表能互通（第 12 篇讲过，系统已自动配好）

如果还没建，先回到第 12 篇把地基打好。网段一错，后面加几台机器都白搭。

2.2 准备两台 ECS

在两个子网各起一台，装同一份服务。为了待会儿能看出请求到底落到哪台，让两台返回可区分的内容：

# 在 ECS-1 上执行
echo "this is ECS-1" > /var/www/html/index.html

# 在 ECS-2 上执行
echo "this is ECS-2" > /var/www/html/index.html

准备清单：

最后一行值得多说一句：后端 ECS 不绑公网 IP 是更合理的做法，用户只通过 ELB 进来，攻击面小一圈，也省了几个 EIP 的费用。

三、在控制台建一个负载均衡

路径同样按「大致位置 + 关键字段名」描述，菜单名以控制台当前显示为准。

3.1 创建 ELB

进入弹性负载均衡控制台 → 「购买/创建负载均衡」，关注这几个字段：

提交后状态变成「运行中」，并分配到一个访问地址（公网型是 IP 或域名），这一步就算成功。顺带提一句费用：公网型负载均衡一般按实例时长与流量计费，规格和价格以购买页当前显示为准。测试阶段选最小档就够，验证完把不用的实例释放掉，别让它一直空跑。

3.2 添加监听器

点进 ELB 详情 → 「监听器」→ 「添加监听器」：

如果站点已经配了 HTTPS（见第 10 篇），前端要选 HTTPS 并绑定证书，后端仍可以走 80。证书放在 ELB 上，后端两台就不用各配一份了，这是顺带的一个好处。

3.3 添加后端服务器组

在同一个页面把两台 ECS 加进后端组：

权重相同意味着两台各分到一半流量。等以后某台配置更高，再调它的权重，现在不用管。

3.4 配健康检查

这是整套结构里最关键的一步。健康检查决定 ELB 怎么判断「哪台还能用」：

检查不通过时，ELB 会自动把这台从转发列表里摘掉，用户不会看到报错。等它恢复了，又会自动加回来。这个「自动摘挂」的能力，是高可用的核心。

3.5 验证一下

连续请求 ELB 的地址，看内容是不是在两台之间切换：

# 换成你自己的 ELB 地址
for i in $(seq 1 6); do curl -s http://你的ELB地址/; done

输出里 this is ECS-1 和 this is ECS-2 交替出现，说明分发生效了。只出现一台，回头检查后端组是不是只加了一台、或者另一台健康检查没通过。

四、怎么确认「真的高可用了」

配置全绿不代表高可用，得实际关一台试试。

4.1 手动停一台

# 在 ECS-1 上执行
systemctl stop nginx

# 回到本地，继续请求 ELB
for i in $(seq 1 6); do curl -s http://你的ELB地址/; done

看到全部返回 this is ECS-2、没有任何一次失败，才算真的做成了。 这是最直接的「看到什么算成功」——比控制台上的绿色状态可靠得多。

同时去 ELB 详情里看健康检查，ECS-1 应该显示为「不健康」或已被摘除。

4.2 健康检查失败的常见信号

如果端口本身就不通，问题已经不在 ELB 配置上——回到第 09 篇，按安全组 → 系统防火墙 → 服务监听地址三层排查，本篇不重复那些命令。

4.3 别忘了一个前提

去掉了「机器单点」，但数据库如果还只有一台，它仍然是单点。这一篇解决的是Web 层，数据库、缓存的高可用需要各自产品自己的能力，不是加个 ELB 就全解决了。判断一个系统是否真的没有单点，要把链路上每个环节都问一遍「它挂了会怎样」。

4.4 多台之后，登录状态怎么办

加第二台机器后，很多人会遇到一个奇怪现象：用户明明登录成功了，刷新几次又变回未登录。

原因通常是登录状态存在了单台机器的内存或本地文件里。第一次请求落到 ECS-1，第二次被分到 ECS-2，而 ECS-2 上根本没有这份会话，就当成没登录处理。

会话保持只是把问题藏起来，真正稳妥的是把会话放到两台都能读到的共享存储里。做完高可用一定要顺手验这一项：登录、刷新几次、再停掉一台，看会不会掉登录。功能测试时只在一台机器上跑，是发现不了这个问题的。

五、五个常见错误

六、小结

高可用听起来是个大词，落到最小可验证的结构上就三件事：两台不同可用区的 ECS、一个 ELB、一条健康检查。做完之后别忘了真的停一台试试，没验证过的切换等于没做。

顺序上也有讲究：先按第 12 篇把网络和子网规划好，再加这一层，才不会遇到「两台机器网段不通」的返工。

后端有多台之后，新问题会变成：接口越来越多，地址该怎么统一给出去。下一篇讲 API 网关。