Dubbo 自适应负载均衡与限流

通过请求返回附带服务端负载，根据算法选择下次调用的合适服务

## 一、概述
- 核心功能：consumer端负载均衡 + provider端限流
- 原有问题
  - 负载均衡：侧重公平性，未充分考虑provider吞吐能力
  - 限流：仅支持静态配置，最大并发值难以合理设置
- 改进目标：提升系统整体性能，动态适配服务状态
- **核心原理**：以“动态感知服务实时状态”为核心，针对负载均衡的公平性局限，引入provider吞吐能力量化机制；针对限流的静态配置缺陷，基于实时硬件指标（CPU）与请求指标（延迟、QPS）动态调整并发上限，实现资源最优分配与过载风险防护
## 二、负载均衡
- 原有算法（5种）
  - Random：核心原理：随机从可用provider列表选择节点，保障基础调用公平性
  - RoundRobin：核心原理：按固定顺序轮询分配请求，确保各provider被均匀调用
  - ConsistentHash：核心原理：通过哈希算法将相同请求映射到同一provider，减少节点上下线时的请求抖动
  - ShortestResponse：核心原理：选择历史响应时间最短的provider，试图提升响应效率，但当各provider响应时长差异小时，易退化为随机选择
  - LeastActive：核心原理：选择当前并发处理任务最少的provider，认为低并发即低负载，但无法单独代表机器实际吞吐能力
- 新增算法
  - P2C算法
    - 核心原理：基于“Power of Two Choice”思想，每次随机选择2个provider，比较其“当前处理连接数”，选择连接数更少的节点，平衡选择效率与负载均衡效果
    - 实现逻辑：两次随机筛选→对比连接数→选择负载更低节点
  - Adaptive算法
    - 核心原理：动态采集provider端CPU负载（cpuLoad）、请求延迟（rt）、未完成请求数（inflight）等指标，通过公式计算provider的综合负载值，基于P2C框架选择负载值更低的节点，精准匹配机器吞吐能力
    - 相关指标：cpuLoad（CPU使用率）、rt（RPC调用耗时）、timeout（调用超时剩余时间）、weight（服务权重）、ewma（延迟平滑值）、inflight（未返回请求数）
    - 负载计算：load = CpuLoad*(sqrt(ewma)+1)*(inflight+1)/(((consumerSuccess/(consumerReq+1))*weight)+1)
    - 算法实现：基于P2C框架，替换“连接数”为“综合负载值”进行节点选择
- 总体效果
  - 实验场景：provider配置均衡、provider配置差距较大
  - 核心结论：Adaptive/P2C算法吞吐量显著优于原有Random、RoundRobin等算法
- 使用方法
  - 配置方式：consumer端设置“loadbalance”为“p2c”或“adaptive”
  - 实现方式：算法类继承LoadBalance接口，融入原有负载均衡框架
## 三、自适应限流
- 核心作用：动态调整provider最大并发值，避免短时间大量请求导致的请求积压或机器宕机
- 新增算法
  - HeuristicSmoothingFlowControl（启发式平滑）
    - 核心原理：基于CPU使用率动态调整“无负载延迟（noLoadLatency）”——CPU低负载时用minLatency替代，中负载时平滑更新，高负载时固定；结合时间窗口内的maxQPS与avgLatency，通过公式计算maxConcurrency，CPU超50%时校验并发量，实现“不过载前提下最大化请求处理”
    - 相关指标：alpha（可接受延时上升幅度，默认0.3）、minLatency（窗口内最小延迟）、noLoadLatency（无负载处理延时）、maxQPS（窗口内最大QPS）、avgLatency（窗口内平均延迟）
    - 最大并发计算：maxConcurrency = ceil(maxQPS*((2+alpha)*noLoadLatency - avgLatency))
    - 算法实现：CPU≤50%直接处理请求；CPU>50%时，若当前并发超maxConcurrency则拒绝请求
  - AutoConcurrencyLimier（基于窗口）
    - 核心原理：基于Little’s Law（稳定态下并发量=延迟×QPS），通过1000ms采样窗口采集QPS、延迟数据；引入exploreRatio（探索率）动态探索剩余容量（满足条件时提升探索率，反之降低）；定期重置窗口与noLoadLatency，避免noLoadLatency上涨导致的误判，实现并发上限自适应调整
    - 相关指标：MaxExploreRatio（默认0.3）、MinExploreRatio（默认0.06）、SampleWindowSizeMs（采样窗口时长，1000ms）、emaFactor（平滑参数，0.1）、noLoadLatency（无负载延迟）
    - 最大并发计算：nextMaxConcurrency（重测场景：ceil(maxQPS*noLoadLatency*0.9/1000000)；非重测场景：ceil(noLoadLatency*maxQPS*(1+exploreRatio)/1000000)）
    - 算法特性：窗口采样更新配置、探索率动态调整容量、定期重置适配状态变化
- 总体效果
  - 实验条件：provider配置差异大、单次请求复杂、超时时间大、开启消费端重试
  - 核心结论：自适应限流方案吞吐量优于不设置限流的场景
- 使用方法
  - 前置条件：服务端多节点部署 + 消费端开启重试策略（确保拒绝请求可重试到其他节点）
  - 配置方式：provider端设置“flowcontrol”为“autoConcurrencyLimier”或“heuristicSmoothingFlowControl”
- 代码结构
  - 核心接口：FlowControl（限流算法接口，基于Dubbo SPI实现）
  - 关键组件
    - FlowControlFilter：provider端过滤器，执行限流判断逻辑
    - CpuUsage：周期性采集CPU使用率指标
    - HardwareMetricsCollector：采集硬件相关指标
    - ServerMetricsCollector：基于滑动窗口采集QPS、延迟等限流所需指标
    - AutoConcurrencyLimier/HeuristicSmoothingFlowControl：两种自适应限流算法的具体实现类

一、概述

核心功能：consumer端负载均衡 + provider端限流
原有问题
- 负载均衡：侧重公平性，未充分考虑provider吞吐能力
- 限流：仅支持静态配置，最大并发值难以合理设置
改进目标：提升系统整体性能，动态适配服务状态
核心原理：以“动态感知服务实时状态”为核心，针对负载均衡的公平性局限，引入provider吞吐能力量化机制；针对限流的静态配置缺陷，基于实时硬件指标（CPU）与请求指标（延迟、QPS）动态调整并发上限，实现资源最优分配与过载风险防护

二、负载均衡

原有算法（5种）
- Random：核心原理：随机从可用provider列表选择节点，保障基础调用公平性
- RoundRobin：核心原理：按固定顺序轮询分配请求，确保各provider被均匀调用
- ConsistentHash：核心原理：通过哈希算法将相同请求映射到同一provider，减少节点上下线时的请求抖动
- ShortestResponse：核心原理：选择历史响应时间最短的provider，试图提升响应效率，但当各provider响应时长差异小时，易退化为随机选择
- LeastActive：核心原理：选择当前并发处理任务最少的provider，认为低并发即低负载，但无法单独代表机器实际吞吐能力
新增算法
- P2C算法
  - 核心原理：基于“Power of Two Choice”思想，每次随机选择2个provider，比较其“当前处理连接数”，选择连接数更少的节点，平衡选择效率与负载均衡效果
  - 实现逻辑：两次随机筛选→对比连接数→选择负载更低节点
- Adaptive算法
  - 核心原理：动态采集provider端CPU负载（cpuLoad）、请求延迟（rt）、未完成请求数（inflight）等指标，通过公式计算provider的综合负载值，基于P2C框架选择负载值更低的节点，精准匹配机器吞吐能力
  - 相关指标：cpuLoad（CPU使用率）、rt（RPC调用耗时）、timeout（调用超时剩余时间）、weight（服务权重）、ewma（延迟平滑值）、inflight（未返回请求数）
  - 负载计算：load = CpuLoad*(sqrt(ewma)+1)*(inflight+1)/(((consumerSuccess/(consumerReq+1))*weight)+1)
  - 算法实现：基于P2C框架，替换“连接数”为“综合负载值”进行节点选择
总体效果
- 实验场景：provider配置均衡、provider配置差距较大
- 核心结论：Adaptive/P2C算法吞吐量显著优于原有Random、RoundRobin等算法
使用方法
- 配置方式：consumer端设置“loadbalance”为“p2c”或“adaptive”
- 实现方式：算法类继承LoadBalance接口，融入原有负载均衡框架

三、自适应限流

核心作用：动态调整provider最大并发值，避免短时间大量请求导致的请求积压或机器宕机
新增算法
- HeuristicSmoothingFlowControl（启发式平滑）
  - 核心原理：基于CPU使用率动态调整“无负载延迟（noLoadLatency）”——CPU低负载时用minLatency替代，中负载时平滑更新，高负载时固定；结合时间窗口内的maxQPS与avgLatency，通过公式计算maxConcurrency，CPU超50%时校验并发量，实现“不过载前提下最大化请求处理”
  - 相关指标：alpha（可接受延时上升幅度，默认0.3）、minLatency（窗口内最小延迟）、noLoadLatency（无负载处理延时）、maxQPS（窗口内最大QPS）、avgLatency（窗口内平均延迟）
  - 最大并发计算：maxConcurrency = ceil(maxQPS*((2+alpha)*noLoadLatency - avgLatency))
  - 算法实现：CPU≤50%直接处理请求；CPU>50%时，若当前并发超maxConcurrency则拒绝请求
- AutoConcurrencyLimier（基于窗口）
  - 核心原理：基于Little’s Law（稳定态下并发量=延迟×QPS），通过1000ms采样窗口采集QPS、延迟数据；引入exploreRatio（探索率）动态探索剩余容量（满足条件时提升探索率，反之降低）；定期重置窗口与noLoadLatency，避免noLoadLatency上涨导致的误判，实现并发上限自适应调整
  - 相关指标：MaxExploreRatio（默认0.3）、MinExploreRatio（默认0.06）、SampleWindowSizeMs（采样窗口时长，1000ms）、emaFactor（平滑参数，0.1）、noLoadLatency（无负载延迟）
  - 最大并发计算：nextMaxConcurrency（重测场景：ceil(maxQPSnoLoadLatency0.9/1000000)；非重测场景：ceil(noLoadLatencymaxQPS(1+exploreRatio)/1000000)）
  - 算法特性：窗口采样更新配置、探索率动态调整容量、定期重置适配状态变化
总体效果
- 实验条件：provider配置差异大、单次请求复杂、超时时间大、开启消费端重试
- 核心结论：自适应限流方案吞吐量优于不设置限流的场景
使用方法
- 前置条件：服务端多节点部署 + 消费端开启重试策略（确保拒绝请求可重试到其他节点）
- 配置方式：provider端设置“flowcontrol”为“autoConcurrencyLimier”或“heuristicSmoothingFlowControl”
代码结构
- 核心接口：FlowControl（限流算法接口，基于Dubbo SPI实现）
- 关键组件
  - FlowControlFilter：provider端过滤器，执行限流判断逻辑
  - CpuUsage：周期性采集CPU使用率指标
  - HardwareMetricsCollector：采集硬件相关指标
  - ServerMetricsCollector：基于滑动窗口采集QPS、延迟等限流所需指标
  - AutoConcurrencyLimier/HeuristicSmoothingFlowControl：两种自适应限流算法的具体实现类