健康检查参数怎么调
健康检查的参数要同时照顾两件事：发现故障的速度，和对抖动容忍的程度。检查间隔与响应超时决定发现故障的效率，健康与不健康的连续次数阈值决定容忍抖动的能力。参数越灵敏，摘除故障后端越快，但正常的慢响应也更容易被误判成故障；参数越宽松，误摘除越少，故障后端却会继续承接流量。所以它不是「调优到最好」，而是按业务的可接受故障时间做取舍。
基本信息
| 检查间隔 | 两次探测的间隔；越短故障发现越快、探测开销越大 |
|---|---|
| 响应超时 | 单次探测的等待上限；后端偶发慢响应时适度放宽 |
| 健康与不健康阈值 | 连续成功或失败次数；越小越灵敏、越容易误判 |
| 换算关系 | 故障发现时间约为不健康阈值乘以检查间隔 |
典型使用场景
- 延迟敏感的交易类服务：缩短间隔，尽快摘除异常后端
- 高并发静态资源服务：适度放宽间隔，降低探测本身的开销
- 后端响应天然较慢（导出、批处理）：放宽响应超时，避免被误判
- 发布与重启窗口：配合先摘除再发布的流程，减少误报
按可接受故障时间反推参数
按可接受故障时间反推参数
间隔 5s 加不健康阈值 3 → 约 15s 判定摘除
间隔 30s 加不健康阈值 3 → 约 90s 判定摘除
先定业务可接受的故障发现时间，再反推间隔与阈值参数影响的取舍
| 参数 | 调小的影响 | 调大的影响 |
|---|---|---|
| 检查间隔 | 发现快，探测压力大 | 压力小，发现慢 |
| 响应超时 | 易把慢响应判为故障 | 故障发现变慢 |
| 不健康阈值 | 灵敏但易误摘 | 稳定但恢复慢 |
发布期间配合「先摘除、再发布、后加回」的流程，可避免健康检查在发布窗口产生误报。
检查方式也要匹配
参数之外，检查什么内容同样关键。TCP 检查只能确认端口可连，应用假死时依然会判定健康；HTTP 检查可以指定路径与期望状态码，更能反映业务真实可用性，但也要选一个足够轻量、不依赖数据库的探测路径，否则探测本身会放大后端压力。常见的做法是为健康检查单独提供一个只做进程与依赖连通性判断的接口，避免把业务链路的不稳定误判成主机故障。