健康检查决定摘除是否可靠
负载均衡把请求分发到后端服务器，靠健康检查判断后端是否还能服务。探测方式从简单到复杂分为三层：只探 TCP 端口能否连接、探测 HTTP 状态码、以及访问业务自定义的健康地址。层次越深越贴近真实可用性，但开销也越大。后端异常时能否及时摘除、恢复后能否自动上线，全靠这几个参数。
基本信息
| 适用平台 | 华为 USG、H3C SecPath、深信服 AF 等具备负载均衡能力的设备 |
|---|---|
| 探测方式 | TCP 端口连接、HTTP 状态码、自定义 URL 或脚本 |
| 关键参数 | 探测间隔、超时时间、失败阈值、恢复阈值 |
| 观测手段 | 设备上查看成员状态与探测结果，结合后端访问日志 |
典型使用场景
- 多后端发布：任何一台后端异常都要自动摘除，用户感知不到
- 应用发布与重启：滚动重启时靠健康检查把重启中的节点摘掉
- 半死状态处理：进程存活但业务异常，只探端口无法发现问题
- 容量评估：通过成员在线比例判断后端承载是否符合预期
- 灰度验证：新后端接入后先观察检查结果，确认稳定再放开流量
参数示例与验证
参数示例与验证
# 参数示例（按业务实际调整，不宜照搬）
探测间隔：5 秒 超时：3 秒
连续失败 3 次摘除 连续成功 3 次恢复
探测地址：/healthz（正常返回 200）
# 验证方法：手动停掉一台后端进程，观察设备成员状态是否被摘除
# 再启动该后端，确认其能自动恢复上线检查方式对比
| 方式 | 能发现的问题 | 局限 |
|---|---|---|
| TCP 端口探测 | 进程或主机整体不可用 | 业务半死状态检测不到 |
| HTTP 状态码 | 应用层异常但仍返回非 200 | 慢响应不一定能被判为失败 |
| 业务健康接口 | 依赖的数据库与下游是否可用 | 接口设计不当会误判 |
| 真实业务请求 | 最贴近用户体验 | 对后端有压力，不宜高频 |
探测地址使用独立的健康检查接口，避免把真实业务链路当作探测对象，既减轻后端压力也减少误判。