Spring Cloud 负载均衡实战：Ribbon 与 LoadBalancer 对比解析

? 从历史舞台看：两者的出身与现状

?️ 核心原理拆解：底层逻辑大不同

? 配置实战：从依赖到策略全流程对比

<dependency>
    <groupId>org.springframework.cloudgroupId>
    <artifactId>spring-cloud-starter-netflix-ribbonartifactId>
dependency>

@Bean
@LoadBalanced
public RestTemplate restTemplate() {
    return new RestTemplate();
}

@Bean
public IRule ribbonRule() {
    // 配置随机策略
    return new RandomRule();
}

<dependency>
    <groupId>org.springframework.cloudgroupId>
    <artifactId>spring-cloud-starter-loadbalancerartifactId>
dependency>

<dependency>
    <groupId>org.springframework.cloudgroupId>
    <artifactId>spring-cloud-starter-netflix-eureka-clientartifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.cloudgroupId>
            <artifactId>spring-cloud-starter-netflix-ribbonartifactId>
        exclusion>
    exclusions>
dependency>

spring:
  cloud:
    loadbalancer:
      clients:
        user-service:  # 针对特定服务配置
          configuration:
            NacosLoadBalancerConfiguration  # 自定义的配置类

spring:
  cloud:
    loadbalancer:
      clients:
        user-service:
          nlb:
            rule:
              name: random

? 性能实测：高并发下的表现差异

? 坑点预警：这些问题一定要避开

1. 版本兼容问题：Ribbon 和 Spring Cloud 新版本兼容性极差，升级到 2020.0 之后的版本，会出现各种 NoClassDefFoundError，因为官方已经把它从核心依赖里移除了。去年升级项目时，光是解决 Ribbon 的依赖冲突就花了 3 天，最后不得不硬着头皮迁移到 LoadBalancer。
   
   
2. 自定义策略生效难：虽然支持自定义，但 Ribbon 的策略类加载机制很奇葩，经常出现配置了不生效的情况。必须把配置类放在 @ComponentScan 扫描不到的地方，还要用 @RibbonClient 显式指定，新手很容易在这里栽跟头。
   
   
3. 重试机制坑人：Ribbon 的重试和 Spring Retry 整合得不好，经常出现重复请求导致服务幂等性问题。有次支付服务就因为这个，用户明明只付了一次钱，结果扣了两次款，排查半天才发现是 Ribbon 重试机制触发的。
   
   

1. 初始版本功能不全：2.2.x 版本之前的 LoadBalancer 连基本的超时配置都没有，必须自己写拦截器。建议直接用 3.0 以上版本，官方补全了这些基础功能。
   
   
2. 服务发现依赖强：如果服务发现组件挂了，LoadBalancer 会直接报错，因为它没有本地缓存兜底。生产环境一定要给服务发现组件做集群，同时配置 LoadBalancer 的故障转移策略。
   
   
3. WebFlux 适配问题：虽然 LoadBalancer 基于 Reactor 开发，但和 Spring WebFlux 整合时，默认的 RestTemplate 会有线程阻塞问题。要用 WebClient 配合 LoadBalancerExchangeFilterFunction 才行，这个配置网上教程很少，踩了不少坑才搞定。
   
   

? 选型建议：到底该选哪个？

• 官方明确推荐，后续会持续更新维护，Ribbon 已经停止开发，迟早要被淘汰
• 轻量高效，性能和资源占用都优于 Ribbon
• 配置简单，扩展方便，特别适合云原生环境
• 对服务动态变化支持更好，适合频繁扩缩容的业务

• 锁定 Ribbon 版本，不要轻易升级 Spring Cloud
• 禁用自动重试，自己实现幂等性重试机制
• 定期清理服务实例缓存，避免脏数据
• 制定迁移计划，逐步替换成 LoadBalancer

? 总结：技术选型要向前看