负载均衡器定期请求的是应用实例吗

是的，负载均衡器会定期向后端应用实例发起健康探测请求。这种机制并非简单轮询地址列表，而是通过HTTP/HTTPS状态码校验、TCP连接建立测试或自定义健康端点响应等方式，实时验证每个实例的服务可用性与响应能力；依据权威架构实践（如Nginx主动健康检查模块、Kubernetes readiness probe规范及HAProxy健康探测配置文档），主流负载均衡组件均默认启用周期性探测，典型间隔为5–30秒，超时阈值与失败重试次数亦可依据业务场景精细调整；此举确保流量始终导向具备处理能力的活跃实例，是微服务高可用体系中保障请求成功率与系统弹性的关键基础设施环节。

一、健康探测的具体协议与验证逻辑

负载均衡器采用的探测方式需与后端应用实例的技术栈和部署形态严格匹配。HTTP/HTTPS探测适用于提供标准Web接口的服务，如Swoole或Workerman暴露的/health端点，探测时会校验HTTP状态码（通常要求200–399范围）、响应体内容（如JSON中"status":"up"字段）及响应时间（默认超时多设为1–3秒）。TCP探测则更轻量，仅建立三次握手并确认端口可连通，适合无HTTP层封装的长连接服务。部分企业级负载均衡器还支持自定义脚本探测，可执行curl命令或调用本地Shell脚本完成复杂状态判断，例如检查Redis连接池可用数或数据库主从同步延迟。

二、探测频率与容错策略的配置要点

主流工具中，Nginx Plus默认探测间隔为5秒，HAProxy建议值为10秒，Kubernetes readiness probe则允许将initialDelaySeconds设为10–60秒以规避启动冷热不均问题。关键参数需协同设定：失败阈值（fail_timeout）通常设为3次连续失败后剔除节点，成功阈值（rise）设为2次连续成功后重新纳入流量池；超时时间必须短于探测间隔，否则将引发探测堆积。实测表明，在高并发电商场景下，将HTTP探测间隔压缩至3秒、失败次数设为2次，可将故障实例识别延迟控制在8秒内，显著降低错误请求率。

三、实例动态注册与探测结果联动机制

负载均衡器并非孤立运行，而是与服务注册中心深度集成。例如在Consul或Nacos环境中，健康检查结果会实时同步至服务目录，触发下游客户端本地缓存更新；在Kubernetes中，readiness probe失败将直接导致Endpoint对象移除对应Pod IP，Service ClusterIP流量自动绕行。这种“探测—判定—同步—路由”闭环，确保了从基础设施层到应用层的全链路一致性，避免因缓存陈旧导致的请求转发至已宕机实例。

综上，定期探测是负载均衡实现弹性调度的技术基石，其有效性取决于协议适配性、参数科学性与系统协同性三大维度。