负载均衡器定期请求的是API网关吗

负载均衡器本身并不定期主动请求API网关，而是作为前置流量分发节点，将客户端发来的请求按策略调度至后端的API网关实例集群。根据IDC与Spring Cloud官方架构文档的实践共识，现代高可用系统通常采用分层网关设计：四层负载均衡器（如Nginx Plus、F5或云厂商SLB）部署于最外层，负责TCP/UDP级健康探测与连接分发；其后才是七层API网关（如Spring Cloud Gateway、Kong或Apigee），承担路由、鉴权、限流等精细化治理任务。负载均衡器对API网关的“探测”仅限于心跳检查与状态同步，并非业务级API调用；真正的请求流转方向始终是“客户端→负载均衡器→API网关→微服务”，这一链路已在CNCF微服务白皮书及主流云平台架构指南中被明确规范。

一、负载均衡器与API网关的职责边界必须厘清

负载均衡器的核心职能是传输层（L4）的连接分发与健康状态感知，其定期执行的“请求”实为轻量级TCP连接探测或HTTP GET探针（如向API网关管理端口发送/health路径请求），用以判断实例是否存活、响应是否超时。这类探测不携带业务参数，不触发鉴权逻辑，也不经过API网关的路由引擎；它仅反馈“可达性”与“基础响应能力”，由负载均衡器内部算法决定是否将后续客户端流量剔除或重新纳入调度池。根据F5官方技术白皮书与Nginx Plus健康检查文档，典型探测间隔为5–30秒，超时阈值通常设为1–3秒，远低于真实业务请求的处理耗时。

二、API网关才是主动发起后端调用的主体

当客户端请求经负载均衡器转发至某API网关实例后，该网关才真正承担起应用层（L7）的主动行为：解析请求头中的API路径与版本标识，查询服务注册中心（如Eureka或Nacos）获取目标微服务的实时实例列表，再依据预设策略（如加权轮询、最小活跃数）选择具体节点，并构造完整HTTP请求向下游微服务发起调用。此过程包含JWT校验、请求体转换、熔断器状态判断等环节，属于典型的业务驱动型交互，与负载均衡器的被动探测存在本质差异。

三、动态服务发现机制强化了二者协同逻辑

在集成Consul或ZooKeeper的服务治理体系中，API网关会主动订阅服务变更事件，而负载均衡器则通过拉取或监听方式同步API网关集群的注册信息。此时，负载均衡器的“定期请求”对象实为服务注册中心的健康端点，而非API网关的业务接口。Spring Cloud Gateway 3.1.x版本已支持与Ribbon或LoadBalancer自动适配，使网关自身具备客户端侧负载均衡能力，进一步降低对外部L4设备的依赖强度。

四、实际部署中需规避常见配置误区

部分运维人员误将API网关的/metrics或/actuator端点暴露于负载均衡探测路径，导致监控接口被高频轮询，引发不必要的GC压力。正确做法是：为负载均衡器单独配置专用健康检查路径（如/api-gw/ready），该路径仅返回200且不加载业务Bean；同时确保API网关的业务路由规则与健康探针路由完全隔离，避免中间件拦截器干扰探测结果准确性。

综上，负载均衡器与API网关构成的是职责分明、层次清晰的协作关系，而非主从调用关系。