健康检查怎么工作
健康检查由负载均衡主动探测后端：按设定的间隔发起探测，连续失败达到「不健康阈值」后把该后端摘除、不再分配新流量；后端恢复并连续成功达到「健康阈值」后重新放量。它决定故障转移的速度与灵敏度，四个参数（间隔、超时、健康阈值、不健康阈值）必须与后端服务的真实响应特征匹配。
基本信息
| 探测方式 | TCP 连接探测、HTTP/HTTPS 状态码探测、UDP 探测（按监听类型与产品） |
|---|---|
| 核心参数 | 检查间隔、响应超时、健康阈值、不健康阈值 |
| 失败动作 | 达到不健康阈值后成员被摘除，不再接收新流量 |
| 恢复动作 | 连续成功达到健康阈值后重新接收流量 |
| 生效范围 | 通常配置在后端服务器组维度，组内成员共用一套参数 |
| 常见默认值 | 各厂商默认间隔与阈值不同，上线前以控制台显示为准并逐项确认 |
典型使用场景
- 服务发布期间判断新版本是否可用：先小权重接入，健康检查通过再逐步放量
- 进程假死检测：端口仍被占用但请求无响应时，HTTP 探测比 TCP 探测更快发现问题
- JVM 等启动预热较慢的应用：调大健康阈值，避免初始化阶段就被摘除
- 数据库代理等四层服务：用 TCP 探测确认端口可用性
- 多可用区部署时配合健康检查自动把流量集中到存活可用区
手工模拟一次健康检查
手工模拟一次健康检查
curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' \
http://10.0.1.10:8080/healthz # 观察状态码与耗时
systemctl is-active myapp # 确认进程状态
ss -lntp | grep 8080 # 确认监听地址不是 127.0.0.1参数调优方向
| 参数 | 调小的影响 | 调大的影响 |
|---|---|---|
| 检查间隔 | 发现故障更快，探测流量与后端压力上升 | 后端抖动不易触发摘除，故障切换变慢 |
| 响应超时 | 慢后端容易被判定不可用 | 异常后端被摘除的时间被拉长 |
| 不健康阈值 | 偶发抖动即摘除，容易误伤 | 故障后端较长时间仍接收流量 |
| 健康阈值 | 恢复后过快放量，可能反复抖动 | 后端恢复后流量回补偏慢 |
后端启动预热慢（如 JVM 应用）时适当调大健康阈值；同时配合应用的预热与优雅下线逻辑，避免发布窗口内出现集中 5xx。
健康检查失败时应修复根因，直接关闭健康检查会同时失去故障自动转移能力，故障会以 5xx 的形式直接暴露给用户。
参数调优经验
- 普通接口类后端：间隔 5 秒、超时 3 秒、不健康阈值 3 次是常见起点
- 慢接口：超时值要略大于正常响应时间，否则健康后端被反复摘除
- 启动预热慢的应用：调大健康阈值，或先摘流量再发布新版本
- 数据库代理类后端：确认探测产生的短连接不会堆积在慢日志与连接数统计里
- 参数变更纳入发布流程统一评审，避免线上随手改动导致节点反复抖动
查看后端健康状态
查看后端健康状态
aliyun slb DescribeHealthStatus --RegionId cn-hangzhou \
--LoadBalancerId lb-xxxxxxxx
# 输出重点：ListenerPort、ServerId、HealthStatus（normal / abnormal）
# 结合监控里的不健康成员数判断是否为整体性故障健康检查是「发现」机制而不是「修复」机制：它只能把异常后端移出流量，根因仍需在应用与依赖层面解决，否则只是把故障点从一个后端扩散到整组。