如何统计Spring Boot应用各节点的会话与请求负载？

完全可以实现，两个核心指标都不需要侵入业务逻辑，用容器和Spring生态自带的能力就能拿到精准值，具体实现分三块：

单节点指标采集 #

两个核心指标的采集逻辑都有成熟的实现路径，不需要从零写统计逻辑：

• 正在处理的请求数：优先用Spring Boot默认集成的Micrometer内置指标http.server.requests.active，这个指标是框架层在请求全生命周期埋点统计的，能覆盖同步请求、异步请求、异常请求的全场景，计数精度足够。如果需要自定义统计维度，也可以自己实现Servlet Filter（Servlet栈）或者WebFlux的WebFilter（响应式栈），用AtomicInteger做计数器：请求进入处理逻辑时执行incrementAndGet()，在请求结束的finally钩子（响应式栈用doFinally）里执行decrementAndGet()，注意不要漏了请求抛异常、被客户端断开连接的场景，避免计数器只增不减。
• 运行中会话数：如果是用Tomcat/Jetty等Servlet容器原生管理HttpSession，直接从Spring容器中拿到ServletWebServerApplicationContext，获取内嵌WebServer对应的会话管理器，就能直接读取容器实时统计的activeSessions值，这个值是容器在会话创建、过期、销毁时实时更新的，没有统计偏差。如果是自定义分布式会话（比如Redis存会话），直接按节点维度统计绑定到当前节点、且未过期的有效会话数量即可，注意要过滤掉已经超时过期的会话数据，避免数值虚高。

指标对接自研负载均衡器 #

采集到指标后，用最轻量的方式对接你的负载均衡控制器即可：

• 最省事的方案：给每个Spring Boot应用加一个内网专属的Actuator自定义端点，端点直接返回当前节点的两个核心指标数值，负载均衡控制器以1~2s的间隔轮询所有后端节点的这个端点拉取数据，这个方案的性能损耗不到单节点QPS的0.1%，完全可以忽略。
• 如果后续需要扩展CPU使用率、堆内存占用、接口平均响应时间等更多负载维度，直接开启Actuator的Prometheus端点，把Micrometer采集的全量节点指标暴露出来，负载均衡侧直接拉取Prometheus格式的指标即可，不需要重复开发采集逻辑。

负载判定的实操注意点 #

实际落地的时候要避开几个常见的坑，不然负载统计不准会导致转发策略失效：

• 不要单靠某一个指标判定节点负载，要结合业务场景做加权计算：比如无状态接口类服务可以给「正在处理的请求数」设0.8_{0.9的高权重，有状态会话类服务可以给「运行中会话数」设0.5}0.7的权重，算出每个节点的综合负载值后，优先转发给综合负载最低的节点。
• 要给指标拉取加故障剔除逻辑：如果某个节点连续3次拉取指标超时/失败，直接暂时把节点从可用负载池中摘除，等指标恢复正常后再重新加回池内，避免把请求转发到故障节点。
• 指标刷新间隔不要超过5s，流量突增场景下如果拿到的是5s前的旧负载数据，很容易出现单点被打满、其他节点空闲的负载不均问题。
• 如果服务用了异步请求（Callable、DeferredResult、WebFlux异步响应），一定要确认请求计数逻辑覆盖了异步处理的全周期，不要等Servlet容器线程释放就提前减计数，不然统计到的处理中请求数会远低于实际值。

内容的提问来源于stack exchange，提问作者Aws AbuObeid