云联信息：负载均衡的健康检查，配错就是灾难

2026-11-04 4次浏览

一、检查路径要真实可用

健康检查访问的路径如果是一个静态文件，只能证明服务器活着，不能证明应用正常。指向一个会查数据库的接口，才能真正反映服务状态。这个接口要轻量，别做复杂查询。

接口正常响应两百毫秒，超时设两秒合理；接口本身要一秒，超时还设两秒，就会频繁误判。间隔太短会增加服务器负担，太长则故障发现慢。通常间隔五秒、超时三秒是稳妥起点。

连续失败三次判定不健康，连续成功三次恢复健康，是比较平衡的设置。阈值设成一，网络抖一下就摘除；设成十，故障十分钟才发现。

健康检查失败只是不再发新请求，已经建立的连接还在处理。真正的优雅下线需要应用配合：收到停止信号后先拒绝新请求，处理完存量再退出。两者要一起做。

健康检查通常只认两百，如果接口返回三零一或者二零四，会被判为失败。确认接口的返回码，必要时在检查路径上做特殊处理。

健康检查日志里应该能看到每台后端的检查结果。全部通过时看不出问题，一台一直失败就要查是不是配置不一致或者服务没起来。

调整健康检查参数后，观察十分钟的流量分布和后端状态。参数改动的影响是渐进的，短时间看不出问题不代表没问题。

开启会话保持后，同一用户的请求固定发到一台后端。这对有本地会话的应用是必要的，但会导致负载不均。更好的做法是把会话外置到缓存，后端保持无状态。

新版本上线时，先给新机器低权重，观察错误率和响应时间，正常再逐步加大。出问题把权重调回零，比回滚整批机器快得多。

排查问题时常常需要知道请求落到了哪台机器。访问日志里带上后端地址，分析时能快速定位是单机问题还是全局问题。

间隔十秒、连续三次失败才摘除，意味着最坏情况下三十秒才发现故障。对延迟敏感的业务，这个时间太长，需要缩短间隔或者减少重试次数。

新上线的机器先给低权重，观察稳定后再逐步提高。这种渐进方式比一次性全量接入安全，出问题影响面也小。

长连接场景下，摘除后端不会立即断开已有连接。需要应用层配合，定期重建连接，让流量重新分配。

负载均衡的监控里看各后端的请求分布，长期不均衡说明权重或者健康检查有问题。这个指标容易被忽略，但很能说明问题。

云联信息【资深云服务专家微信：cloud7591】的建议是上线前先压测再扩容，凭经验估容量十次有八次估偏。