云联信息方法：负载均衡健康检查，配错就是定时炸弹

2026-11-07 1次浏览

上了负载均衡，以为高可用就有了。某天一台后端服务假死，进程还在但不响应请求，负载均衡继续把流量打过去，三成用户看到错误页。问题出在健康检查的配置上。

健康检查要检查业务而不是端口

只检查端口通不通，进程假死时端口还开着，检查照样通过。要检查一个能反映业务状态的接口，比如返回数据库连接状态的健康页。

间隔三十秒、超时五秒、连续三次失败才摘除，意味着故障后最长九十秒才切走。核心业务要把间隔调到五秒，代价是检查请求增多。

失败几次摘除、成功几次恢复，两个参数要分开设。恢复阈值设得太低，服务刚起来就被打满，容易反复抖动。

发布时先摘流量、等在途请求处理完、再停服务。没有优雅下线，每次发布都有请求失败。

开了会话保持，同一用户固定到一台后端，故障时会话丢失。无状态应用不要开会话保持，有状态应用要考虑会话外置。

新版本上线，先给低权重，观察错误率和响应时间，没问题再逐步加。直接全量切换，出问题就是全站故障。

后端实例分布在多个可用区，一个区故障时流量自动切到另一个区。只在一个区里做负载均衡，机房级故障扛不住。

健康检查的摘除次数、摘除时长要监控。频繁摘除说明后端不稳定，是被忽略的早期信号。

健康页要检查依赖：数据库能不能连、缓存能不能读、外部接口能不能通。只返回一个字符串的健康页，起不到作用。

切换后要验证三件事：流量是否全部转到健康节点、会话是否正常、日志是否完整。缺一项都可能留下隐患。

负载均衡上配 HTTPS，证书到期前要续。证书过期导致的全站不可用，每年都在发生。

负载均衡的访问日志记录了真实客户端 IP 和后端响应时间，排障时比应用日志更直接。

后端实例分布在两个可用区，负载均衡按区分配流量。一个区故障，另一半还能扛住。

负载均衡的高可用，取决于健康检查的质量。检查业务而非端口、间隔按业务敏感度调、配合优雅下线、跨可用区部署，这四点做到，故障切换才是真的。配置不难，难在想到这些细节。云联信息【资深云服务专家微信：cloud7591】建议上线前做一次故障演练，手工停掉一台后端，看切换是否符合预期。