用弹性负载均衡 ELB 给 Web 服务分发流量的实践笔记

一、单机 Web 服务的两个坎

业务早期一台云服务器跑 Web 服务很省事，但很快会撞上两个坎：一是流量上来后单机 CPU 和带宽吃紧，页面开始变慢；二是这台机器一旦故障或升级重启，服务直接中断。弹性负载均衡 ELB（Elastic Load Balance）就是为此而生：它把访问流量按策略分发到多台后端服务器，既摊薄压力，又能在一台后端出故障时自动把流量切到健康的机器上，做到用户无感。

二、四个核心概念

1. 负载均衡器：对外的统一入口，绑定弹性公网 IP 承接用户请求。分共享型和独享型，独享型性能与隔离性更好，生产环境建议独享型。
2. 监听器：定义入口协议和端口。四层（TCP/UDP）转发快、七层（HTTP/HTTPS）能按域名和路径做精细转发，还能在监听器上卸载 HTTPS 证书，后端只跑 HTTP，省 CPU。
3. 后端服务器组：真正干活的 ECS 集合，配合调度算法分发请求，常用加权轮询；有状态服务可用源 IP 算法或开启会话保持。
4. 健康检查：ELB 定期探活后端，连续失败达到阈值就自动摘除，恢复后再自动加回——这是「故障无感切换」的关键。

三、我的实操步骤

1. 创建独享型 ELB，选与后端 ECS 相同的 VPC 和子网，绑定弹性公网 IP。
2. 准备两台 ECS，各装 Nginx 并放一个内容不同的测试首页（方便肉眼验证流量在两台之间轮换）。
3. 建后端服务器组，调度算法选加权轮询，把两台 ECS 以相同权重加入，业务端口 80。
4. 加 HTTP 监听器（80 端口）指向该后端组；健康检查用 HTTP 方式探 / 路径，间隔 5 秒、不健康阈值 3 次。
5. 域名 A 记录解析到 ELB 的公网 IP，反复刷新页面确认两台首页交替出现。
6. 做一次故障演练：停掉其中一台的 Nginx，观察健康检查把它摘除后请求全部落到另一台，页面不中断；再把服务拉起来，确认自动回池。

四、上线前容易漏的配置

• 会话保持：带登录态的应用如果没开会话保持，请求轮换到另一台机器时用户会被踢下线，要么开会话保持，要么把会话集中存到 Redis 这类外部存储，后者更推荐。
• 证书管理：HTTPS 证书配在监听器上统一卸载和更新，别在每台后端各配一份，续期时会漏。
• 日志与监控：打开访问日志，配合云监控看每台后端的请求量和响应时间，分发是否均匀一眼便知。

五、常见坑

1. 后端安全组没放行 ELB 所在网段，健康检查全部失败，后端被误摘，表面看是 ELB 故障，其实是安全组问题。
2. 健康检查路径指向一个会跳转或返回非 200 的页面，后端反复被摘除又加回，流量抖动。
3. 只测了正常分发，没做故障演练，等真出故障才发现摘除阈值设得太宽、切换要等好几分钟。
4. 后端之间版本不一致，轮换访问时用户看到两个版本的页面，发布时要用同一镜像或同一部署流程。

六、小结

ELB 的价值不只是「分流量」，更是给 Web 服务买了一份可用性保险：入口统一、后端可弹性增减、故障自动切换。把健康检查参数调稳、故障演练做扎实，再处理好会话与证书这两件配套事，一套能扛事的 Web 入口就算立住了。