Spring Cloud LoadBalancer 最佳实践

Ribbon 曾经是 Spring Cloud 家族默认的客户端负载均衡工具，而 Spring Cloud LoadBalancer (SCLB) 是官方替换 Ribbon 的新实现。表面上它们都解决 “服务调用时选哪个实例” 的问题，但在理念、架构和生态上差异不小。

一、Ribbon vs SCLB

1. 定位和生态地位

Ribbon
- Netflix OSS 出品，老一代的客户端负载均衡器。
- 在 Spring Cloud Dalston ~ Greenwich 时代是默认选择。
- 后来 Netflix OSS 宣布 进入维护模式（2018年起不再活跃发展）。
Spring Cloud LoadBalancer
- Spring 团队自研，替代 Ribbon。
- 完全独立于 Netflix 生态，不再依赖过时组件。
- 与 Spring Boot 2.x/3.x、Reactor、WebClient、Feign 等深度集成。

2. 核心设计思路

Ribbon
- 侵入性较强：依赖 IClientConfig、IRule、IPing 等接口，配置体系复杂。
- 强调“策略类 + 配置类”模式（比如 RoundRobinRule、ZoneAvoidanceRule）。
- 同步调用模型为主，虽然可扩展但偏“重量级”。
- 与 RestTemplate 深度耦合（通过 @LoadBalanced RestTemplate）。
Spring Cloud LoadBalancer
- 函数式 + 轻量化：核心是 ServiceInstanceListSupplier（负责提供实例列表）和 ReactorServiceInstanceLoadBalancer（负责挑选实例）。
- 完全 Reactor 化，支持响应式编程（Reactor/Flux/Mono），天然适配 WebClient。
- API 更简单，默认策略是 RoundRobin，但很容易定制。
- 更解耦，和 DiscoveryClient、Feign、gRPC 等可自由组合。

3. 扩展能力

Ribbon
- 有比较多的现成策略：RoundRobinRule、RandomRule、RetryRule、WeightedResponseTimeRule…
- 自定义需要继承 IRule，配置也要绕 Ribbon 的专用配置体系。
- 支持 Zone 概念（跨机房/多可用区），适合 Netflix 内部环境，但在普通企业里很少用上。
Spring Cloud LoadBalancer
- 策略很“干净”：只要实现 ReactorServiceInstanceLoadBalancer 接口即可。
- ServiceInstanceListSupplier 提供了天然的 hook：你可以在实例列表进入负载均衡前加上 过滤、排序、权重。
- 没有 Ribbon 那种内置十几个策略的复杂度，但用组合的方式，灵活度更高。

4. 与 Spring 生态的关系

Ribbon
- 被强绑定到 RestTemplate + Feign（老版本）。
- Spring Cloud Netflix 维护成本高，升级阻力大。
Spring Cloud LoadBalancer
- 未来路线核心组件，和 Spring Cloud Gateway、Feign 3.x、WebClient 全兼容。
- 官方推荐替代方案，Ribbon 已经标记 Deprecated。
- 随 Spring Boot/Spring Cloud 版本更新，能持续获得支持。

5. 性能与现代化

Ribbon
- 基于老旧同步模型（虽然功能全，但显得笨重）。
- 没有天然的 Reactor 支持，在响应式场景里不合拍。
Spring Cloud LoadBalancer
- 基于 Reactor，轻量、非阻塞，天然适合高并发场景。
- 使用 Flux<ServiceInstance>，可以灵活叠加缓存、权重、健康检查逻辑。
- 更加云原生，能和 Kubernetes Service、Consul、Nacos 等平滑对接。

二、源码说明

1. 核心抽象

Ribbon
- 结果：实例获取、缓存、负载均衡策略，全都绑死在 Ribbon 的体系。
- 负载均衡器接口：ILoadBalancer
  内部维护实例列表（ServerList），并交给 IRule 挑选。
- 负载均衡策略接口：IRule
```
public interface IRule {Server choose(Object key);void setLoadBalancer(ILoadBalancer lb);ILoadBalancer getLoadBalancer();
}
```
  代表“从一堆服务实例里挑一个”。
- Spring Cloud LoadBalancer (SCLB)
  - 实例供应接口：
```
public interface ServiceInstanceListSupplier extends Supplier<Flux<List<ServiceInstance>>> {String getServiceId();
}
```
    负责“提供候选实例列表”，来源可以是 DiscoveryClient、缓存、静态配置。
  - 策略接口：
```
public interface ReactorServiceInstanceLoadBalancer {Mono<Response<ServiceInstance>> choose(Request request);
}
```
    专注于“如何从候选列表里挑一个”。
  - 结果：候选列表与选择逻辑完全解耦，职责单一，而且基于 Reactor（非阻塞）。

2. Spring Cloud LoadBalancer 和 Feign 相对 Ribbon 的解耦性

看源码上的调用链对比最明显：

Ribbon + Feign
Feign 的 LoadBalancerFeignClient → 直接调用 RibbonLoadBalancerClient → 使用 ILoadBalancer + IRule 绑定。

public class RibbonLoadBalancerClient implements LoadBalancerClient {@Overridepublic ServiceInstance choose(String serviceId) {ILoadBalancer loadBalancer = getLoadBalancer(serviceId);Server server = loadBalancer.chooseServer(null);return new RibbonServer(serviceId, server, isSecure(server), serverIntrospector(serviceId).getMetadata(server));}
}

可以看到：Feign 和 Ribbon 耦合紧密，ILoadBalancer 和 IRule 必须都存在。

SCLB + Feign（Spring Cloud 2020+）
Feign 的 LoadBalancerFeignClient → 使用 BlockingLoadBalancerClient 或 ReactorLoadBalancerExchangeFilterFunction。
```
public class BlockingLoadBalancerClient implements LoadBalancerClient {private final LoadBalancerClientFactory clientFactory;@Overridepublic ServiceInstance choose(String serviceId) {ReactorServiceInstanceLoadBalancer loadBalancer = clientFactory.getInstance(serviceId, ReactorServiceInstanceLoadBalancer.class);// 核心是调用 loadBalancer.choose()}
}
```
这里的关键：
- Feign 只依赖于 ReactorServiceInstanceLoadBalancer 抽象，而不关心实例供应如何实现。
- ServiceInstanceListSupplier 可随时替换（比如 Kubernetes、Consul、Nacos），Feign 本身无需改动。

👉 结论：Ribbon 时代 Feign 直接依赖 Ribbon 核心接口，导致强绑定；SCLB 下 Feign 只依赖于统一的 LoadBalancer 抽象，而实例来源和策略完全可插拔 → 解耦性更高。

三、Spring Cloud LoadBalancer 最佳实践

1. 基础使用

引入依赖

<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-loadbalancer</artifactId>
</dependency>

RestTemplate / WebClient 集成

@Bean
@LoadBalanced
public RestTemplate restTemplate(RestTemplateBuilder builder) {return builder.build();
}@Bean
@LoadBalanced
public WebClient.Builder webClientBuilder() {return WebClient.builder();
}

建议优先用 WebClient，因为它能发挥 SCLB 的 Reactor 非阻塞优势。

2. 缓存与性能优化

SCLB 默认每次请求会调用 DiscoveryClient 获取实例，可以用内置的 缓存供应器：

@Bean
public ServiceInstanceListSupplier discoveryClientServiceInstanceListSupplier(ConfigurableApplicationContext context) {return ServiceInstanceListSupplier.builder().withDiscoveryClient().withCaching() // 启用缓存.build(context);
}

这样能减少注册中心压力，尤其是在高并发场景。

3. 自定义策略

简单示例：基于元数据的优先级选择

比如实例 metadata 里有 "zone": "shanghai"，只要优先调用同城实例：

@Bean
ReactorServiceInstanceLoadBalancer zoneAwareLoadBalancer(ObjectProvider<ServiceInstanceListSupplier> supplierProvider) {return new ReactorServiceInstanceLoadBalancer() {@Overridepublic Mono<Response<ServiceInstance>> choose(Request request) {return supplierProvider.getIfAvailable().get().next().map(instances -> {List<ServiceInstance> localZone = instances.stream().filter(i -> "shanghai".equals(i.getMetadata().get("zone"))).toList();if (!localZone.isEmpty()) {return new DefaultResponse(localZone.get(0));}return new DefaultResponse(instances.get(0));});}};
}

更复杂：权重路由

实现 ReactorServiceInstanceLoadBalancer，结合 metadata.weight 字段，做加权随机选择。这相当于 Ribbon 的 WeightedResponseTimeRule，但在 SCLB 里更灵活。

4. ServiceInstanceListSupplier 增强

SCLB 提供了“供应链”思想，常用扩展点：

过滤：过滤掉 metadata 标记为 "status=down" 的实例；
排序：按响应时间/CPU负载排序，把健康的放前面；
包装：组合多层供应器（比如先 DiscoveryClient → 再缓存 → 再 zone 过滤）。

这种链式增强比 Ribbon 的配置类清晰得多。

5. 与 Feign 配合

在新版 Spring Cloud 中，Feign 默认走 SCLB。最佳实践：

配置 spring.cloud.loadbalancer.retry.enabled=true → 自动开启重试机制；
自定义 ReactorServiceInstanceLoadBalancer，Feign 会自动走你的策略；
如果想做更细粒度控制，可以写 @FeignClient(configuration=...) 指定独立的 LoadBalancer 配置。

6. 容错与重试

SCLB 不再像 Ribbon 那样内置 RetryRule，而是把重试交给 Spring Retry：

spring:cloud:loadbalancer:retry:enabled: trueretry-on-all-operations: truemax-retries-on-same-service-instance: 1max-retries-on-next-service-instance: 2

这样能保证单实例失败 → 自动切换下一个实例，避免单点问题。

7. 云原生环境最佳实践

在 Kubernetes 上，推荐直接基于 spring-cloud-starter-kubernetes-client + SCLB，实例供应就是 Pod 列表；
在 Nacos / Consul 场景下，直接使用对应 DiscoveryClient starter，SCLB 自动适配；
保持 ServiceInstance metadata 丰富（zone、weight、tag），方便做策略。