华为云 ELB 弹性负载均衡实战：健康检查、会话保持与权重调优的避坑指南

前言

把业务放到华为云上之后，第一个绕不开的组件往往就是弹性负载均衡 ELB。它负责把访问流量分发到多台后端云服务器，同时借助健康检查把异常实例自动摘除，是实现高可用的基础。但很多“后端明明是好的，ELB 却显示异常”“用户一会儿登录一会儿掉线”的问题，并不是 ELB 本身有故障，而是健康检查、会话保持、权重这几项配置没有和业务特点对齐。本文结合常见的落地场景，梳理一套从规划、配置到排查的实操思路。文中涉及的具体默认值、配额和端口范围，请以华为云官方文档和控制台页面为准。

一、先理清 ELB 的基本结构

ELB 的配置可以拆成三层，理解它们之间的关系，后面排查会轻松很多：

• 负载均衡器：入口，绑定 VPC、子网，对外提供业务需要的弹性公网 IP 或仅内网地址。
• 监听器：定义“监听什么协议、什么端口”，例如 HTTP 80、HTTPS 443、TCP 3306 等。HTTPS 监听器还要关联证书。
• 后端服务器组：真正处理请求的一组服务器，分发算法、会话保持、健康检查都是配置在后端服务器组上的。

选型时先问清楚业务协议：如果是 Web 站点、需要按域名或路径转发，应选支持七层（HTTP/HTTPS）能力的规格；如果是数据库代理、游戏长连接等四层（TCP/UDP）场景，则选四层即可。不同规格的功能和限制并不完全一样，建上之前最好对照官方的规格对比表确认。

二、健康检查：最容易“配错”的地方

健康检查的核心是：ELB 定期向后端服务器发探测，连续失败达到阈值就把它标记为异常并停止转发，恢复后再自动加回来。常见可配置项有：检查协议、检查端口、检查路径（七层场景）、检查间隔、超时时间、最大重试次数。

1. 检查路径要专门做一个轻量接口

很多团队直接把首页 “/” 当作检查路径。首页往往要查数据库、渲染模板，一旦下游偶尔变慢，所有后端会同时被判异常，造成整体不可用。更好的做法是单独提供一个 /healthz 之类的接口：

• 只检查本进程是否能正常处理请求，必要时检查关键依赖（例如数据库连接池是否可用），但不要做耗时的查询。
• 返回明确的 200 状态码，响应体尽量小。
• 不要做鉴权、跳转，否则可能返回 301/302/401，被判为异常。

在后端服务器上可以先自测一下：

curl -i http://127.0.0.1:8080/healthz
# 期望看到 HTTP/1.1 200 OK
ss -lntp | grep 8080
# 确认进程确实监听在预期端口，且监听地址不是仅 127.0.0.1（否则 ELB 探测不到）

2. 间隔、超时、重试要组合着看

“从故障发生到被摘除”的时间，大致等于检查间隔乘以失败重试次数，再加上超时。间隔太长，故障实例会继续接收流量；间隔太短、重试次数太少，又容易因为一次网络抖动或 GC 停顿就误摘。一个比较稳妥的思路是：重试次数不要设为 1，超时时间小于检查间隔，并根据业务能容忍的故障摘除时间反推参数，而不是直接用默认值。

3. 安全组与网络 ACL 必须放行探测流量

这是“后端是好的却一直异常”的头号原因。健康检查的探测包是由 ELB 的后端地址发往后端服务器的，如果后端服务器的安全组入方向没有放行相应来源和端口，探测就会超时。不同类型的 ELB，探测流量的源地址范围不同，具体请查阅官方文档里“后端服务器安全组配置”的说明，并按文档放行。同时要检查子网的网络 ACL 有没有拦截，以及服务器本机的防火墙（如 firewalld、iptables）是否放行。

三、分发算法与权重

常见的分发算法有加权轮询、加权最少连接、源 IP 哈希等（具体可选项随监听协议和规格而异）：

• 加权轮询：适合请求处理时间比较均匀的无状态服务，是最常用的选择。
• 加权最少连接：适合请求耗时差异大、或者长连接较多的场景，新连接会优先分到当前连接数少的实例。
• 源 IP 哈希：同一个客户端 IP 倾向于固定到同一台后端，可以作为不方便做会话保持时的补充，但当客户端经过大量 NAT 出口时，可能造成负载不均。

权重的用途不止是“配置高的机器多分一点”。上线新版本时，可以先给新实例设置较小的权重做灰度观察；下线某台机器时，先把权重调到 0，等存量连接自然结束后再关机，避免直接停机导致用户请求失败。

四、会话保持：能不用就不用，必须用要选对

如果业务把登录状态存在单机内存里，那么请求被分到另一台后端就会“掉线”。最根本的解法是把会话放到 Redis 之类的共享存储里，让后端无状态化；这样 ELB 不需要任何会话保持，也最利于弹性伸缩。

确实需要会话保持时，常见方式有：

• 源 IP：四层、七层都可用，简单，但受 NAT 影响，可能让大量用户落到同一台机器。
• HTTP Cookie / 应用 Cookie：七层使用，按 Cookie 把同一用户固定到同一后端，粒度更细，通常比源 IP 更均衡。

需要注意的是，会话保持有超时时间，超时后可能重新分配后端；并且在后端被判异常摘除时，绑定到它的用户也会被迁移，业务层仍然要能容忍这种情况。

五、让后端拿到真实客户端 IP

请求经过 ELB 转发后，后端看到的源地址默认是 ELB 的地址，而不是用户。在七层场景下，可以让 ELB 通过 X-Forwarded-For 请求头带上客户端地址，应用或 Nginx 再从这个头里取值。以 Nginx 为例，可以结合 real_ip 模块，仅信任来自 ELB 地址段的请求头：

set_real_ip_from 10.0.0.0/8;     # 示例：替换为你的 ELB 所在子网
real_ip_header X-Forwarded-For;
real_ip_recursive on;

四层场景则要看 ELB 提供的“获取客户端 IP”相关能力，具体开启方式和后端读取方式以官方文档为准。切记不要无条件信任 X-Forwarded-For，否则客户端可以伪造该请求头来绕过基于 IP 的限制。

六、常见问题排查清单

遇到 ELB 访问异常，建议按下面的顺序从外到内逐层确认，而不是一上来就怀疑平台：

1. 入口是否通：监听器端口是否对应业务端口；如果需要公网访问，弹性公网 IP 是否已绑定，带宽是否正常；客户端侧防火墙或运营商网络是否有影响。
2. 监听器与后端服务器组是否关联正确：协议是否匹配，例如 HTTPS 监听器后端用 HTTP 还是 HTTPS 是否与服务实际一致。
3. 后端健康状态：在控制台查看后端服务器的健康检查结果。如果全部异常，优先排查检查路径、端口、安全组和网络 ACL；如果只有部分异常，则看这些实例本机的服务状态与负载。
4. 后端本机：确认进程监听地址和端口（ss -lntp），确认本机防火墙，必要时在后端抓包，观察是否收到来自 ELB 的探测请求：

   tcpdump -nn -i eth0 port 8080

   如果能看到探测请求但没有响应，问题在应用；如果根本看不到请求，问题在网络路径或安全策略。
5. 502/504 类错误：通常意味着后端响应异常或超时。可以对比 ELB 的超时设置与应用的实际处理时间，检查后端日志是否有慢请求、连接数是否被打满。
6. 偶发掉线：回头看会话保持方式、会话是否存放在本机内存，以及是否有实例被反复摘除又加回（健康检查参数过于敏感）。

七、上线前的检查小结

• 后端提供独立、轻量的健康检查接口，并确认它返回 200。
• 安全组、网络 ACL、本机防火墙都已放行 ELB 的探测与业务流量。
• 优先让服务无状态化；确需会话保持再选择合适的方式，并评估 NAT 带来的不均衡。
• 变更和下线时利用权重做灰度和平滑摘除。
• 在监控里关注后端健康状态变化和 4xx/5xx 趋势，并为“异常后端数量”设置告警。

结语

ELB 本身的配置项并不多，真正的难点在于让这些配置与业务特性对齐：健康检查要反映“能不能正常服务”，而不是“端口开没开”；会话保持是对架构的补丁，而不是第一选择；权重则是发布和运维的杠杆。把这些细节处理好，ELB 才能真正成为高可用架构里稳定的一环。希望这篇文章能帮你少走一些弯路，欢迎一起交流。8.137.82.99