健康检查是什么：负载均衡器判断后端可用性的工作原理

健康检查是指负载均衡器、反向代理或服务发现系统按照固定规则主动探测后端节点状态，并根据探测结果决定是否继续把请求分发给该节点的机制。它解决的是“某台服务器进程还在，但业务是否真的可用”的判断问题。没有健康检查时，负载均衡器通常只能按轮询、权重或连接数分发流量；一旦某个后端返回错误、依赖数据库失败或响应时间过长，用户请求仍可能被转发到故障节点。健康检查通过周期性探测、连续成功或失败阈值、状态摘除与恢复，帮助负载均衡层把流量尽量导向可处理请求的后端。

定义与基本作用

在虚拟主机和应用交付架构中，负载均衡器位于客户端与后端服务器之间。它既可以分配新连接，也可以在节点异常时停止转发流量。健康检查就是这一判断过程的输入来源：探测器按照设定的 interval、timeout、path、expected status code 等参数访问后端，再把结果转化为 healthy、unhealthy 或 draining 等状态。

一个典型例子是三台 Web 后端共同承载同一网站，负载均衡器每 5 秒访问一次 /healthz。若某台后端连续 3 次在 2 秒超时内没有返回 HTTP 200，负载均衡器会把它标记为不可用，并停止把新请求发给它。若该节点随后连续 2 次恢复正常响应，则重新加入转发池。这个过程与 服务器故障排查、性能优化 和 定时任务稳定性 都有关，因为应用可用性经常由多个组件共同决定。

健康检查不等同于简单的 Ping。Ping 只能说明网络层可能可达，不能证明 Web 进程、数据库连接、缓存依赖或业务配置正常。面向网站和 API 的健康检查通常更关注应用层，例如 HTTP 状态码、TLS（传输层安全协议）握手、指定路径返回内容、TCP 端口连接和响应延迟。

健康检查如何工作

健康检查一般由探测、判定、摘除、恢复四个动作组成。探测动作负责采集信号；判定规则负责避免一次偶发超时导致误摘除；摘除动作把异常节点从转发池中移出；恢复动作则在节点稳定后重新接收流量。为了避免抖动，生产环境通常不会使用“失败一次就下线、成功一次就上线”的规则，而是设置连续失败次数和连续成功次数。

常见检查方式可以分为以下几类：

• TCP 检查：尝试连接后端端口，例如 80、443 或 3306；优点是开销低，缺点是只能确认端口可连接。
• HTTP 检查：访问 `/health`、`/status` 或 `/ready`，要求返回 200、204 等状态码；适合 Web 服务和 API。
• HTTPS 检查：在 HTTP 检查基础上验证 SSL（安全套接层）或 TLS 握手，可发现证书过期、协议配置错误等问题。
• 应用级检查：由应用返回数据库、缓存、消息队列等依赖状态；适合微服务和交易系统，但要控制探测成本。
• 被动检查：根据真实用户请求中的 5xx、连接重置、超时等信号调整节点状态，通常与主动检查结合使用。

例如，某负载均衡器配置 interval=10s、timeout=3s、unhealthy_threshold=3、healthy_threshold=2。这表示每 10 秒探测一次，单次响应超过 3 秒视为失败；连续 3 次失败后下线，连续 2 次成功后恢复。最坏情况下，一个故障节点可能在约 30 秒后被摘除；恢复也至少需要约 20 秒。这些数字直接影响故障暴露时间和服务恢复速度。

关键参数与判定逻辑

健康检查的准确性取决于参数组合，而不是单个开关。过于激进的检查会把短暂抖动误判为宕机，过于宽松的检查又会让故障节点继续接收请求。配置时通常需要同时考虑业务响应时间、部署方式、依赖链长度和错误预算。

从技术架构上看，健康检查分为 liveness 与 readiness 两类思路。liveness 关注进程是否存活，常用于发现死锁、崩溃和不可恢复状态；readiness 关注服务是否准备好接收流量，常用于启动预热、依赖不可用或灰度发布期间的流量保护。把两者混在同一个接口里，容易出现“进程活着但不该接流量”或“临时依赖失败导致进程被错误重启”的问题。

在反向代理、容器编排和 负载均衡 场景中，健康检查还会影响 DNS（域名系统）故障切换、CDN（内容分发网络）回源选择和多机房容灾。例如当主机房的源站健康检查失败时，全球流量调度系统可能把部分访问切到备用区域。若检查路径只返回静态 200 页面，却没有检测数据库或对象存储，就可能在核心业务不可用时仍然显示“健康”。

应用场景

健康检查最常见的应用是多台后端服务器共同承载一个站点。对电商、内容站、控制面板和 API 服务来说，负载均衡器需要持续知道哪些后端能正常处理请求。一个由 4 台 Web 节点组成的站点，如果其中 1 台在发布新版本后启动失败，健康检查可以把流量限制在剩余 3 台节点上，避免约 25% 的请求持续报错。

第二类场景是滚动发布。新版本后端启动后，先通过 readiness 检查确认端口、配置、数据库迁移和缓存预热完成，再逐步接收流量。若检查失败，调度层可以暂停继续发布或回滚到旧版本。这比只观察进程 PID 更可靠，因为进程存在并不代表业务路径可用。

第三类场景是跨区域容灾。多个机房或云区域之间通常通过全局负载均衡、DNS（域名系统）解析或 Anycast 路由控制流量。健康检查结果会影响区域权重。当某区域连续失败达到阈值后，流量会被转移到其他区域；当区域恢复稳定后，再按权重逐步回切。这里的关键不是“切得越快越好”，而是避免网络抖动导致频繁切换。

常见误区与边界

健康检查能降低故障流量比例，但不能替代监控、日志和容量规划。它只回答“此刻是否应继续给某节点分发请求”，并不完整解释故障根因。运维人员仍需要结合错误率、延迟分位数、系统资源、应用日志和链路追踪定位问题。

• 误区一：只检查端口就足够。端口可连接只能说明网络栈和监听进程存在，不能证明登录、支付、查询等业务路径可用。
• 误区二：检查越频繁越安全。1 秒一次探测在大规模集群中可能形成额外负载，1000 个节点就可能产生每秒 1000 次探测。
• 误区三：返回 200 就代表健康。某些应用即使数据库连接池耗尽，也可能让 `/health` 静态返回 200。
• 误区四：失败立即摘除一定更好。短暂网络抖动、垃圾回收暂停或冷启动可能造成 1 次超时，连续阈值更适合生产环境。

较稳妥的做法是把健康接口设计为轻量、稳定、可解释。接口不宜执行昂贵 SQL、大文件读取或外部 API 调用；但至少应覆盖关键依赖是否可用、应用是否完成启动、当前节点是否处于维护模式。对于带宽（单位时间内可传输的数据量）压力较大的站点，还应区分“节点健康”和“容量充足”：节点健康并不意味着它能承受突发流量。

与监控告警的区别

健康检查和监控告警经常同时出现，但职责不同。健康检查直接参与流量决策，动作通常是摘除节点、恢复节点或改变权重；监控告警面向人和自动化运维系统，动作通常是通知、扩容、重启、回滚或创建事件记录。前者偏实时控制，后者偏诊断和治理。

因此，健康检查接口的结果应尽量明确。例如 /livez 表示进程是否应继续运行，/readyz 表示是否准备接收请求，/healthz 可以作为聚合状态入口。命名并非固定标准，但在团队和系统之间保持一致可以减少误操作。更多系统层面的排查方法可参考 Linux 服务器故障排查 相关内容。

参考资料与延伸阅读

• Kubernetes 文档：Liveness、Readiness 与 Startup Probes
• HAProxy 文档：Health checks
• 海外云主机常见故障及高效处理方法指南
• WordPress Redis 连接错误排查

总结

健康检查是负载均衡器判断后端可用性的基础机制。它通过周期性探测、超时控制、连续阈值和状态恢复，把不可用或尚未准备好的节点从流量路径中移出。合理的健康检查建议同时区分存活状态与就绪状态，使用能够代表真实业务路径的轻量接口，并结合监控告警追踪根因。如果系统对可用性要求较高，可以考虑为不同服务设置独立探测路径、灰度恢复权重和跨区域容灾规则，而不是只依赖一个静态 200 页面。