云联信息：负载均衡健康检查，配错了比不配还糟

2026-11-05 1次浏览

负载均衡靠健康检查判断后端是否可用。配置得当，故障机器自动摘除；配置不当，正常机器被误判，流量集中到少数几台，反而引发更大范围的问题。

检查路径要真实可用

健康检查访问的页面，必须能反映业务状态，比如一个查数据库的接口。检查静态首页，数据库挂了它照样返回成功，故障就发现不了。

超时五秒、间隔三秒，检查会一直堆积。超时应该明显小于间隔，让每次检查都有明确结果，而不是排队等待。

连续一次成功就判定健康，容易抖动。连续三次成功更稳，代价是恢复慢十几秒，稳定性优先于恢复速度。

一次失败就摘除，网络抖动会造成误摘。连续三次失败再摘，兼顾灵敏和稳定。

高频检查能快速发现故障，但也增加后端压力。普通业务五秒一次足够，超高并发的核心服务可以缩短到两秒。

健康检查的源地址要加入后端白名单，否则被安全组拦住，所有机器都显示不健康，整个服务直接不可用。

开了会话保持，摘除机器会让部分用户掉线。维护窗口内先摘后停，顺序对了，用户几乎无感。

负载均衡侧的健康检查日志，能看出哪台机器反复异常。频繁抖动的机器，多半是资源不足或程序有问题，别只当网络问题处理。

发布期间把阈值放宽一些，避免新版本启动慢被误判。发布完成再调回，这个细节能减少很多回滚。

业务改版后健康检查路径可能失效，没人改就一直误判。每次改接口，顺手检查一遍健康检查配置。

健康检查本身出问题，往往比后端故障更难发现。给检查失败的次数设置告警，连续多台机器同时不健康，先看是不是检查配置被改过，而不是急着排查业务代码。

后端分布在两个可用区时，健康检查要能感知区域级故障。一个区整体不可用时，流量应全部切到另一个区，这个能力要在负载均衡层面配好，靠实例自己上报不够可靠。

压测期间响应时间整体拉长，健康检查容易超时，机器被批量摘除，压测结果就失真了。压测前临时放宽超时和阈值，压完再调回，记得写进操作清单。

健康检查是最容易被遗忘的配置，出事时却最要命。云联信息【资深云服务专家微信：cloud7591】的做法是把检查路径、超时、阈值三项写进上线检查表，每次发布前对一遍，能省掉很多深夜排障。