Spring Cloud LoadBalancer 与服务实例筛选策略：从随机到权重的负载均衡
一、微服务负载均衡的选型困境：Ribbon 退役后的新选择
Spring Cloud 2020 版本正式移除了 Netflix Ribbon，Spring Cloud LoadBalancer（以下简称 SCLB）成为官方推荐的负载均衡方案。与 Ribbon 相比，SCLB 的核心变化在于：基于 Reactor 的非阻塞架构、更简洁的 SPI 扩展机制、以及与 Spring Cloud 生态的深度集成。但 SCLB 默认仅提供轮询和随机两种策略，缺少 Ribbon 中的权重路由、区域亲和、熔断联动等生产级策略。
在实际微服务部署中，服务实例的硬件配置、当前负载、网络延迟各不相同，简单的轮询策略无法实现真正的负载均衡。例如，一台 8 核 16G 的实例与一台 2 核 4G 的实例承担相同的流量比例，显然不合理。理解 SCLB 的扩展机制并实现自定义筛选策略，是生产落地的关键。
二、SCLB 的核心架构与请求路由机制
SCLB 的请求路由流程围绕ReactorLoadBalancer接口展开，核心组件包括ServiceInstanceListSupplier（实例供应器）和ReactorServiceInstanceLoadBalancer（负载均衡器）。
flowchart TD A[HTTP 请求到达] --> B[ReactorLoadBalancerClientFilter] B --> C[ServiceInstanceListSupplier 获取实例列表] C --> D[实例列表过滤: 健康检查/区域亲和] D --> E[ReactorServiceInstanceLoadBalancer 选择实例] E --> F{负载均衡策略} F -->|RoundRobin| G[轮询选择] F -->|Random| H[随机选择] F -->|Weighted| I[权重选择] G & H & I --> J[返回选中的 ServiceInstance] J --> K[LoadBalancerClient 执行请求] K --> L[记录请求指标: 延迟/错误率] L --> M[反馈到权重计算]ServiceInstanceListSupplier是实例列表的来源，支持多层装饰器叠加：基础供应器 → 健康检查过滤 → 区域亲和过滤 → 权重排序。这种装饰器模式使得策略组合非常灵活。
三、生产级权重负载均衡策略的实现
3.1 基于响应时间的动态权重策略
/** * 基于响应时间的动态权重负载均衡器 * 响应时间越短的实例权重越高，实现"快者多劳"的流量分配 */ public class ResponseTimeWeightedLoadBalancer implements ReactorServiceInstanceLoadBalancer { private final String serviceId; private final ServiceInstanceListSupplier serviceInstanceListSupplier; private final InstanceStatsCollector statsCollector; /** * 核心选择逻辑：根据动态权重选择实例 * 权重 = 基础权重 × 响应时间因子 × 错误率因子 */ @Override public Mono<Response<ServiceInstance>> choose(Request request) { return serviceInstanceListSupplier.get() .next() .map(instances -> selectInstance(instances, request)); } private Response<ServiceInstance> selectInstance( List<ServiceInstance> instances, Request request) { if (instances.isEmpty()) { return new EmptyResponse(); } // 1. 计算每个实例的动态权重 List<WeightedInstance> weighted = instances.stream() .map(inst -> { InstanceStats stats = statsCollector.getStats(serviceId, inst.getInstanceId()); double weight = computeDynamicWeight(inst, stats); return new WeightedInstance(inst, weight); }) .collect(Collectors.toList()); // 2. 加权随机选择：权重越高的实例被选中概率越大 double totalWeight = weighted.stream() .mapToDouble(WeightedInstance::getWeight).sum(); double random = ThreadLocalRandom.current().nextDouble(totalWeight); double cumulative = 0.0; for (WeightedInstance wi : weighted) { cumulative += wi.getWeight(); if (random <= cumulative) { return new DefaultResponse(wi.getInstance()); } } // 降级：返回第一个实例 return new DefaultResponse(instances.get(0)); } /** * 动态权重计算：综合考虑响应时间和错误率 * 响应时间因子: avgResponseTime 越低，因子越高 * 错误率因子: errorRate 越高，因子越低 */ private double computeDynamicWeight(ServiceInstance inst, InstanceStats stats) { // 基础权重：从元数据读取，默认 1.0 double baseWeight = Double.parseDouble( inst.getMetadata().getOrDefault("weight", "1.0") ); // 响应时间因子：使用指数衰减，避免慢实例权重过低导致流量集中 double avgResponseTime = stats.getAvgResponseTimeMs(); double responseTimeFactor = Math.exp(-avgResponseTime / 1000.0); // 错误率因子：错误率超过 50% 时权重趋近于 0 double errorRate = stats.getErrorRate(); double errorFactor = Math.max(0.01, 1.0 - errorRate * 2); return baseWeight * responseTimeFactor * errorFactor; } }3.2 实例指标收集器
/** * 实例指标收集器：基于滑动窗口统计响应时间和错误率 * 使用 ConcurrentHashMap 保证线程安全 */ @Component public class InstanceStatsCollector { private final ConcurrentMap<String, SlidingWindowStats> statsMap = new ConcurrentHashMap<>(); /** * 记录一次请求的结果 * key 格式: serviceId:instanceId */ public void record(String serviceId, String instanceId, long responseTimeMs, boolean success) { String key = serviceId + ":" + instanceId; statsMap.computeIfAbsent(key, k -> new SlidingWindowStats(60)) .record(responseTimeMs, success); } public InstanceStats getStats(String serviceId, String instanceId) { String key = serviceId + ":" + instanceId; SlidingWindowStats stats = statsMap.get(key); if (stats == null) { return InstanceStats.empty(); } return new InstanceStats(stats.getAvgResponseTimeMs(), stats.getErrorRate()); } /** * 滑动窗口统计：每秒一个桶，保留最近 60 秒 * 避免使用全局锁，采用 CAS 更新桶内计数器 */ static class SlidingWindowStats { private final AtomicReferenceArray<StatsBucket> buckets; private final int windowSizeSeconds; SlidingWindowStats(int windowSizeSeconds) { this.windowSizeSeconds = windowSizeSeconds; this.buckets = new AtomicReferenceArray<>(windowSizeSeconds); } void record(long responseTimeMs, boolean success) { int idx = (int) (System.currentTimeMillis() / 1000 % windowSizeSeconds); StatsBucket bucket = buckets.get(idx); if (bucket == null || bucket.isExpired()) { StatsBucket newBucket = new StatsBucket(); buckets.compareAndSet(idx, bucket, newBucket); bucket = newBucket; } bucket.record(responseTimeMs, success); } double getAvgResponseTimeMs() { long totalResponseTime = 0, totalCount = 0; for (int i = 0; i < windowSizeSeconds; i++) { StatsBucket b = buckets.get(i); if (b != null && !b.isExpired()) { totalResponseTime += b.totalResponseTime; totalCount += b.count; } } return totalCount == 0 ? 100.0 : (double) totalResponseTime / totalCount; } double getErrorRate() { long totalErrors = 0, totalCount = 0; for (int i = 0; i < windowSizeSeconds; i++) { StatsBucket b = buckets.get(i); if (b != null && !b.isExpired()) { totalErrors += b.errorCount; totalCount += b.count; } } return totalCount == 0 ? 0.0 : (double) totalErrors / totalCount; } } }3.3 自定义 LoadBalancer 配置注册
@Configuration @ConditionalOnClass(ReactorLoadBalancer.class) public class WeightedLoadBalancerConfig { @Bean @ConditionalOnMissingBean public ReactorLoadBalancer<ServiceInstance> weightedLoadBalancer( Environment environment, LoadBalancerClientFactory factory, InstanceStatsCollector statsCollector) { String serviceId = environment.getProperty( LoadBalancerClientFactory.PROPERTY_NAME ); ServiceInstanceListSupplier supplier = factory.getLazyProvider( serviceId, ServiceInstanceListSupplier.class ).getIfAvailable(); return new ResponseTimeWeightedLoadBalancer(serviceId, supplier, statsCollector); } }四、权重负载均衡的边界分析与架构权衡
权重计算的冷启动问题。新实例上线时没有历史指标，权重因子无法计算。常见做法是给新实例分配一个"预热权重"——初始权重设为平均值，在收集到足够样本（如 100 次请求）后切换为动态权重。预热期间流量分配可能不均，但避免了新实例被分配零流量的问题。
指标收集的内存开销。每个实例维护 60 秒的滑动窗口，如果服务有 100 个实例，需要 6000 个桶。每个桶包含计数器和累加值，内存开销可控。但在超大规模场景（万级实例）下，需要考虑采样而非全量统计。
权重震荡风险。当某个实例因瞬时抖动导致响应时间飙升，其权重会急剧下降，流量涌向其他实例，可能导致级联过载。建议对权重变化做平滑处理：新权重 = 0.7 × 旧权重 + 0.3 × 计算权重，避免权重突变。
适用边界：动态权重策略最适合实例异构的场景（混合部署、弹性伸缩）。如果所有实例配置相同且负载均匀，简单的轮询策略已经足够，引入动态权重反而增加了不必要的复杂度。
五、总结
Spring Cloud LoadBalancer 通过ServiceInstanceListSupplier装饰器和ReactorLoadBalancerSPI 提供了灵活的扩展机制。基于响应时间的动态权重策略可以实现"快者多劳"的流量分配，但需关注冷启动、权重震荡和指标收集开销等问题。建议在实例异构场景下启用动态权重，在实例同构场景下使用轮询策略，保持架构简洁。
