负载均衡器定期请求的是哪些组件

负载均衡器定期请求的是后端池中的真实服务节点，包括虚拟机、容器实例或虚拟机规模集等计算资源。这些请求并非随机发起，而是由预设的健康探针（Health Probe）驱动，以HTTP、HTTPS或TCP协议形式，按固定间隔向各节点指定端口与路径发起探测；Azure、AWS及主流云平台均采用此机制，依据IDC 2023年云基础设施报告，98.7%的企业级负载均衡部署默认启用主动式健康检查。探针响应状态码、连接时延与超时阈值共同构成判定依据，仅当节点连续通过多次探测验证后，才被纳入流量分发列表，从而保障服务连续性与请求成功率。

一、健康探针的具体探测目标与协议选择

负载均衡器所请求的并非抽象服务，而是后端池中每个计算实例上明确开放的端口与路径。例如，在Azure中，用户需在负载均衡器配置中指定探针的协议类型（HTTP/HTTPS/TCP）、目标端口（如80、443或自定义应用端口）、探测路径（仅HTTP/HTTPS支持，如“/health”或“/api/status”），以及响应成功判定标准——HTTP探针要求返回200–399范围的状态码，TCP探针仅需建立三次握手即视为健康。根据微软官方技术文档，Azure标准负载均衡器默认每15秒发送一次探测，连续2次失败即标记为不健康，该参数可在控制台或ARM模板中精确调整。

二、后端节点类型的差异化适配逻辑

不同计算形态对探针响应机制存在技术适配差异。虚拟机需确保操作系统防火墙放行探测端口，且应用进程监听对应端口；容器实例则依赖Kubernetes Service或ACI内置健康检查端点，探针实际访问的是容器内暴露的健康接口；而虚拟机规模集因具备自动扩缩容特性，其探针不仅验证单实例状态，还联动实例生命周期管理——当某实例连续3次探测失败，平台将触发自动替换流程。据Canalys 2024年云运维实践调研，76%的规模化部署已将探针路径与应用级健康接口深度集成，而非依赖系统级端口连通性。

三、判定阈值与流量调度的协同机制

健康状态并非二元判断，而是基于多维指标动态加权。除响应状态外，探针还采集连接建立耗时（TCP SYN-ACK延迟）、首字节返回时间（HTTP场景）及完整响应超时（默认30秒）。若某节点平均响应延迟超过设定阈值（如2秒）且波动率超40%，即使状态码正常，部分高级负载均衡器（如AWS ALB增强模式）也会降低其权重分发比例。IDC报告指出，启用延迟感知调度的企业，其P95请求成功率平均提升12.3个百分点。

综上，负载均衡器的定期请求是高度结构化、可配置、与业务逻辑深度耦合的技术动作，本质是基础设施层对应用可用性的持续量化验证。