Ribbon是Netflix推出的一款客户端负载均衡器，它与Nginx这类服务端负载均衡最大的区别在于：负载均衡的逻辑不在独立的代理服务器上执行，而是直接运行在服务消费者的进程内部。消费者从注册中心拉取服务提供者的实例列表后，由Ribbon按照某种策略选出一个实例，再发起HTTP请求。这种方式省去了代理层的转发开销，也让负载均衡策略可以更灵活地定制。在Spring Cloud技术栈中，Ribbon与RestTemplate或Feign配合使用，是早期微服务调用最主流的方案之一。
一、Ribbon的核心工作原理
要理解Ribbon的行为，关键在于弄清楚它是如何拿到服务列表、又是如何挑选实例的。Ribbon内部维护了三个核心组件：ServerList负责获取候选服务实例列表，IRule负责根据规则挑选一个实例，ServerListFilter负责对列表进行过滤。三者协同工作，完成一次完整的负载均衡决策。
当Ribbon与Eureka整合时，默认的ServerList实现是DiscoveryEnabledNIWSServerList，它会定时从Eureka Server拉取注册表，把服务名对应的所有实例缓存在本地。这个拉取动作是异步的，默认每30秒刷新一次，所以即使Eureka Server短暂不可用，消费者依然可以用本地缓存的列表继续调用，这在一定程度上提升了系统的容错能力。
挑选实例的逻辑由IRule接口定义，Ribbon内置了多种实现：RoundRobinRule轮询策略按顺序依次选择实例，适合实例配置相近的场景；RandomRule随机选择，在压测或实例性能差异明显时更常用；WeightedResponseTimeRule会根据每个实例的平均响应时间动态分配权重，响应越快的实例被选中的概率越高；BestAvailableRule则会跳过处于熔断状态的实例，选择并发数最小的那个。了解这些策略的差异，是后续调优的基础。
二、整合配置完整步骤
首先是依赖引入。如果你的项目使用的是Spring Cloud Netflix全家桶，且版本在2020年之前，那么只需要引入spring-cloud-starter-netflix-eureka-client，Ribbon会作为传递依赖自动带上。如果需要单独使用Ribbon而不结合注册中心，也可以直接引入ribbon核心依赖：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-ribbon</artifactId>
</dependency>第二步是配置RestTemplate并开启负载均衡。关键就是在创建RestTemplate的Bean方法上加一个@LoadBalanced注解，这个注解会触发Ribbon的自动配置，给RestTemplate注入一个拦截器，把请求中的逻辑服务名替换成真实的服务器地址：
@Configuration
public class RestTemplateConfig {
@Bean
@LoadBalanced // 开启客户端负载均衡
public RestTemplate restTemplate() {
return new RestTemplate();
}
}第三步在业务代码中直接使用服务名发起调用。注意这里的URL中写的是注册到Eureka的服务名，而不是具体的IP和端口：
@Service
public class OrderService {
@Autowired
private RestTemplate restTemplate;
public String getUserInfo(Long userId) {
// USER-SERVICE 是服务提供者注册到Eureka的服务名
return restTemplate.getForObject(
"http://USER-SERVICE/user/" + userId, String.class);
}
}配置完成后，建议启动两个不同端口的提供者实例进行验证，多次调用后观察两个实例的控制台日志，如果请求被交替处理，说明负载均衡已经生效。如果调用报UnknownHostException，大概率是忘了加@LoadBalanced注解，或者RestTemplate不是通过Bean注入而是自己new出来的，这两种情况都会导致服务名无法被解析。
三、自定义负载均衡策略与进阶配置
切换负载均衡策略有两种方式。第一种是配置文件方式，针对特定服务配置rule属性即可：
# application.yml 中针对 USER-SERVICE 服务配置随机策略
USER-SERVICE:
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
ConnectTimeout: 3000
ReadTimeout: 5000
MaxAutoRetries: 1
MaxAutoRetriesNextServer: 1第二种是Java代码方式，通过定义IRule的Bean来全局生效：
@Configuration
public class RibbonRuleConfig {
@Bean
public IRule customRule() {
// 使用加权响应时间策略
return new WeightedResponseTimeRule();
}
}还有一个容易被忽视的点是饥饿加载。Ribbon默认采用懒加载，也就是第一次调用某个服务时才会初始化对应的LoadBalancer，这个过程包括拉取服务列表、创建定时任务等，会导致首次请求明显偏慢。可以在配置文件中开启饥饿加载，让应用启动阶段就完成初始化：
ribbon:
eager-load:
enabled: true
clients: USER-SERVICE,ORDER-SERVICE重试机制也值得配置。上面配置中的MaxAutoRetries表示当前实例失败后重试次数，MaxAutoRetriesNextServer表示切换到下一个实例的次数，配合OkToRetryOnAllOperations可以控制是否对所有请求类型都重试。需要注意的是，如果业务接口不是幂等的，盲目开启POST重试可能造成重复下单之类的数据问题，务必结合业务场景评估。
四、常见问题与排查思路
整合过程中最常见的问题之一是调用超时。默认的连接超时和读取超时都比较宽松，生产环境建议根据实际接口的响应时间收紧配置，同时结合熔断器Hystrix的超时时间统一考虑，避免出现Ribbon还没超时、Hystrix先熔断的情况，这会导致重试机制失效。
另一个高频问题是负载不均衡。明明配置了轮询策略，但某个实例的请求量明显偏多。这通常是因为同一个应用中存在多个RestTemplate，其中只有部分加了@LoadBalanced注解，未加注解的那个走的是直连逻辑；也可能是自定义的IRule配置作用域不对，被全局应用到了不该生效的服务上。排查时可以通过Ribbon的动态配置端点，或者临时把日志级别调到DEBUG观察LoadBalancer的选择过程。
最后需要提醒的是版本兼容问题。从Spring Cloud 2020.0版本开始，Ribbon已被移出官方维护范围，取而代之的是Spring Cloud LoadBalancer。如果你的项目还在使用较老的Netflix技术栈，Ribbon依然可以稳定运行；但对于新项目，建议直接采用Spring Cloud LoadBalancer，它保持了@LoadBalanced注解的使用习惯，迁移成本相对较低。理解了Ribbon的工作原理后再去学习新的负载均衡组件，思路是完全相通的。
Spring BootRibbon负载均衡修改时间：2026-08-31 17:56:32