健康检查是故障恢复能力的触发开关，关键在于及时发现故障、不误判、不卡死且恢复动作可验证；需模拟超时、非200状态码、连接拒绝等真实失败模式，量化检测延迟、流量切换完成时间、自动回归时间，并结合上下游指标交叉验证及防误判机制压测。
健康检查本身不是目标，而是故障恢复能力的触发开关。在全链路压测中评估集群故障恢复能力，关键在于让健康检查真正“起作用”——能及时发现故障、不误判、不卡死、且恢复动作可验证。
用真实失败模式触发健康检查
压测中不能只靠“停服务”这种粗暴方式，它掩盖了网络抖动、慢响应、部分失败等更常见的生产问题：
- 模拟后端响应超时：在目标节点上临时注入延迟（如用 tc 加 2s 网络延迟），观察健康检查是否在 fall=2 次内剔除节点
- 返回非 200 健康状态码：修改 /health 接口返回 503 或 404，验证 check_http_expect_alive 是否按预期识别为失败
- 主动关闭连接：在节点上执行 iptables -A OUTPUT -p tcp --dport 80 -j REJECT，测试连接拒绝类故障的感知速度
把恢复时间量化到秒级
“快速恢复”必须可测量。重点盯三个时间点：
- 检测延迟：从后端异常开始，到 Nginx 日志出现 "upstream server temporarily disabled" 的时间差（应 ≤ 3 秒）
- 流量切换完成时间：用 curl -I 轮询请求，统计连续 5 次返回非故障节点 IP 的耗时（理想值 ≤ 1.5 秒）
- 自动回归时间：后端恢复正常后，到 Nginx 日志出现 "upstream server restored" 的间隔（需匹配 rise=2 和 interval=3000）
结合全链路指标交叉验证
单看 Nginx 日志不够，要和上下游数据对齐：
- 比对 Nginx stub_status 中该 upstream 的 Failed requests 上升曲线，与后端应用监控中的错误率突增是否同步
- 检查压测工具（如 wrk）报告的 error rate 是否在剔除后 2 秒内回落至 0.1% 以下
- 查看 Prometheus 中 nginx_upstream_check_fails_total 和 nginx_upstream_check_rises_total 的计数变化节奏
防误判机制必须参与压测
真实场景中，网络抖动、GC 暂停都可能引发瞬时失败。压测时要故意引入干扰，验证配置鲁棒性：
- 在压测过程中随机触发一次后端 JVM Full GC（约 1.2 秒 STW），确认不会导致节点被误踢
- 同时对多个节点轮换注入 300ms 延迟，观察是否出现“集体失联”或调度雪崩
- 禁用 proxy_next_upstream 后重跑，对比错误率增幅——若差异巨大，说明健康检查与重试策略未协同
