负载均衡器定期请求的是健康检查端点吗

是的，负载均衡器确实会定期请求预设的健康检查端点（如 `/health` 或 `/healthz`）来实时评估后端服务实例的可用性。这一机制并非简单轮询，而是依据可配置的时间间隔（常见为5–30秒）、超时阈值、失败重试次数及响应状态码（如HTTP 200/204）进行结构化探测，其结果直接驱动流量分发决策——仅将请求路由至通过连续多次健康校验的实例。该实践已被主流云平台（AWS ALB、Azure Load Balancer、阿里云SLB）及开源方案（Nginx Plus、HAProxy）广泛采用，并在CNCF官方文档与Kubernetes生产部署指南中明确规范，成为现代分布式系统高可用架构的核心支撑环节。

一、健康检查端点的配置与标准化路径

负载均衡器所请求的健康检查端点需由后端服务主动暴露，常见路径包括 `/health`、`/healthz`、`/actuator/health`（Spring Boot）或 `/readyz`（Kubernetes readiness probe）。这些路径必须返回结构化响应体（如JSON格式），明确包含 `status: "UP"` 或 `status: "DOWN"` 字段，并确保HTTP状态码为200（成功）或503（服务不可用）。开发阶段需在应用启动时启用对应健康检查中间件，例如ASP.NET Core中通过 `AddHealthChecks()` 注册，Spring Boot中通过 `spring-boot-starter-actuator` 启用。路径不可随意变更，否则将导致负载均衡器持续判定实例不健康。

二、探测参数的精细化调优方法

实际部署中需根据业务特性调整探测频率与容错策略：常规Web服务建议设为每10秒探测一次，超时时间不超过3秒，连续2次失败即标记为不健康，连续3次成功才恢复流量；对于资源密集型AI推理服务，可延长至每30秒探测，避免高频请求引发额外负载。所有参数均支持在负载均衡器控制台或配置文件中修改，如AWS ALB通过Target Group的Health Check Settings配置，Nginx Plus则在upstream块中设置 `health_check interval=10 fails=2 passes=3`。

三、状态判定逻辑与流量调度联动机制

负载均衡器并非仅依赖单次响应结果，而是维护每个实例的健康状态机：初始状态为“未知”，经首次成功响应转为“健康”，连续失败达阈值后进入“不健康”并立即从转发列表移除；恢复过程需连续通过指定次数探测，确认稳定后才重新纳入轮询池。此状态变化实时同步至路由表，整个过程无需人工干预，平均故障隔离时间控制在30秒内，符合SLA 99.95%可用性要求。

四、验证与监控的落地操作步骤

运维人员应每日通过命令行验证端点可用性：执行 `curl -I http:///health` 检查状态码与响应头；同时接入Prometheus采集负载均衡器上报的 `target_health_status` 指标，结合Grafana看板监控异常实例数量趋势；当发现某集群健康失败率突增时，须立即排查后端日志中是否出现数据库连接超时或内存OOM等根因。

综上，健康检查端点是负载均衡实现自动故障隔离的技术锚点，其配置规范性、参数合理性与监控闭环性共同决定了系统弹性水位。