Spring Cloud Ribbon：客户端负载均衡的工作原理与迁移实践

摘要： 服务实例会扩容、下线、迁移，调用方如果把 IP 写死，很快就会被配置维护拖住。Netflix Ribbon 把负载均衡放在客户端：调用方拿到服务实例列表后，在本地选择目标实例并发起请求。本文从一次服务调用出发，介绍 Ribbon 的核心组件、Spring Cloud 接入方式、常见规则与重试边界，并说明存量项目如何评估迁移。

关键词： Ribbon、Spring Cloud、客户端负载均衡、Eureka、Spring Cloud LoadBalancer

一、服务调用为什么需要负载均衡

假设订单服务要调用库存服务。最初库存服务只有一个实例，调用方直接请求 http://10.0.0.12:8080，简单直接。等库存服务扩成多个实例，问题就来了：调用方怎么知道新实例？某台机器故障后，谁来避开它？每个调用方都维护一份 IP 列表，很快就会把服务治理变成“全公司一起改配置”。

负载均衡负责把请求分配到多个可用实例。Ribbon 的思路是客户端负载均衡：调用方获取实例列表，在发起请求时自行挑选一个实例。Netflix 将 Ribbon 定义为带有内置软件负载均衡能力的客户端 IPC 库；在 Spring Cloud 的集成中，它以服务名为单位组织客户端组件。citeturn560910search0turn804587view1

这和传统的服务端负载均衡不一样：服务端负载均衡通常由 Nginx、云负载均衡器等代理接收请求，再转发给后端；客户端负载均衡则由调用方直接选择实例并连接。前者有统一入口，后者少一跳、调用方更了解实例信息，但也意味着客户端需要维护服务发现和请求治理逻辑。

二、一次 Ribbon 调用经过哪些环节

以订单服务调用库存服务为例，代码使用逻辑地址 http://inventory-service/api/stock。inventory-service 不是 DNS 域名，而是 Ribbon 客户端标识。典型流程如下：

1. 识别客户端名称。 调用方根据服务名找到对应的 Ribbon 客户端配置。
2. 获取服务实例。 实例列表可以来自 Eureka 等服务发现组件，也可以通过配置指定固定服务器列表。
3. 过滤候选实例。 例如根据可用状态或区域偏好筛选实例。
4. 选择目标实例。 IRule 根据负载均衡策略选出一个服务端。
5. 执行网络请求。 Ribbon 集成的 HTTP 客户端将服务名解析为选中的实例地址，再发送请求；失败时是否重试由相关配置与调用方式共同决定。

Spring Cloud Netflix 为每个命名客户端创建独立的客户端上下文，并组合 ILoadBalancer、HTTP 客户端、ServerListFilter 等组件。官方文档列出的默认组件包括 ZoneAvoidanceRule、ZonePreferenceServerListFilter 和 ZoneAwareLoadBalancer；具体行为会受依赖版本、服务发现集成和项目配置影响。citeturn804587view1

Ribbon 和 Eureka 不是一回事

两者经常一起出现，但职责不同：

• Eureka： 维护服务实例注册信息，回答“这个服务有哪些实例”。
• Ribbon： 获取候选实例并回答“这次请求选哪个实例”。
• HTTP 客户端： 与选中的实例建立连接、发送请求并读取响应。

可以把 Eureka 看成动态通讯录，把 Ribbon 看成调用方手里的分配器。没有 Eureka，Ribbon 仍然可以使用配置好的固定地址列表；只有 Eureka 而没有负载均衡器，调用方也仍需决定如何选择实例。

三、Spring Cloud Netflix 旧版接入示例

下面是面向使用 Ribbon 的旧版 Spring Cloud Netflix 项目的示例。Spring Cloud Release Train 与 Spring Boot 版本必须按官方兼容关系配套，别把不同时代的依赖版本拼成“全家桶”。

1. 添加依赖

使用 Maven BOM 管理 Spring Cloud 版本时，旧项目曾通过以下 starter 引入 Ribbon：

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

如果实例列表来自 Eureka，还需要与项目版本相匹配的 Eureka Client 依赖和注册中心配置。

2. 配置负载均衡策略

Ribbon 的客户端级配置以服务名为前缀。以下 YAML 为旧版 Ribbon 客户端指定轮询规则：

inventory-service:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule

inventory-service 对应调用代码里的逻辑服务名。配置项名称受 Ribbon 版本和配置绑定机制影响；迁移或升级时，应以当前项目实际加载的 Ribbon 配置为准，不要只看网上复制来的片段。

3. 用逻辑服务名发起请求

在旧版 Spring Cloud 集成中，给 RestTemplate 标记 @LoadBalanced 后，可使用服务名作为 URL 主机部分：

@Configuration
public class HttpClientConfiguration {

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

@Service
public class InventoryClient {

    private final RestTemplate restTemplate;

    public InventoryClient(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    public String getStock(String sku) {
        return restTemplate.getForObject(
                "http://inventory-service/api/stock/{sku}",
                String.class,
                sku
        );
    }
}

这里的 @LoadBalanced 会让 Spring Cloud 为请求接入负载均衡客户端；它不会把服务名变成一个真实 DNS 名称。请求最终选到哪个实例，取决于实际生效的负载均衡实现和服务发现结果。

四、常见负载均衡规则怎么选

Ribbon 通过 IRule 抽象选择策略。常见规则包括：

策略不是性能开关。轮询不会自动感知业务处理耗时，随机也不保证每个时间窗口绝对均匀；区域策略若没有正确的 zone 信息，最后可能退化成普通选择逻辑。先确认实例列表、健康状态、区域元数据和真实流量，再谈换规则，别把一个类名当成调优方案。

五、重试、超时与幂等性：别让保护机制变成放大器

负载均衡只负责选择目标实例，不会自动保证下游调用可靠。生产配置至少要把下面几件事放在一起评估：

• 连接超时和读取超时： 需要有明确上限，避免请求线程被慢连接长期占住。
• 重试范围： 明确哪些异常、哪些状态码、在哪个实例上重试，以及最多尝试几次。
• 请求幂等性： GET 通常更容易安全重试；扣款、下单等写操作要有幂等键或业务去重机制。
• 总耗时预算： 多次重试会叠加连接与读取耗时，必须确保总调用时间仍落在上游请求的超时预算内。
• 重试层级： 如果 Ribbon、Feign、HTTP 客户端和网关都各自重试，重试次数可能相乘，形成意料之外的流量放大。

尤其别把“换一台机器再发一次”当作没有代价的动作：如果第一次写请求已经在服务端完成，只是响应丢了，第二次请求就可能重复执行。重试需要基于业务语义设计，不能只靠负载均衡配置兜底。

六、Ribbon 的维护状态与新项目选型

Ribbon 是经典的客户端负载均衡组件，但它已经进入维护模式。Spring Cloud Netflix 的文档明确说明 Ribbon 处于维护模式，并建议在相应的旧版集成中转向 Spring Cloud LoadBalancer；Netflix 项目仓库也说明 Ribbon 处于 maintenance 状态。citeturn560910search0turn804587view1

因此，选型要分两种情况：

• 存量项目： 先盘点 Spring Boot / Spring Cloud 版本、Eureka 或其他服务发现方式、Feign / RestTemplate 使用情况，以及 Ribbon 的自定义规则和重试参数，再决定升级路径。不要只删一个依赖就认为迁移完成。
• 新项目： 优先查看与当前 Spring Cloud 版本配套的 Spring Cloud LoadBalancer。当前官方文档将它作为 Spring Cloud 自带的客户端负载均衡抽象与实现，提供轮询和随机等实现，并支持与服务发现集成。citeturn560910search2turn804587view3

从概念上看，迁移时要逐项映射：服务实例来源、实例过滤方式、负载均衡策略、超时和重试边界、监控指标，以及 Feign 或 HTTP 客户端集成。Spring Cloud LoadBalancer 的扩展模型与 Ribbon 并不完全相同，迁移应以目标 Release Train 的官方文档和集成测试为准；旧版配置键不能假定在新版本里仍然有效。

七、排查 Ribbon 调用异常的顺序

服务名调用失败时，按链路逐层检查，比盯着“负载均衡算法”猜来猜去靠谱：

1. 确认客户端标识。 URL 中的服务名、Eureka 注册名、配置前缀是否一致。
2. 确认发现结果。 调用方实际拿到的实例列表是否为空、是否包含过期地址。
3. 确认筛选结果。 zone、状态过滤或自定义过滤器是否把候选实例全部筛掉。
4. 确认选择器。 实际生效的 IRule 是否为预期规则，客户端专属配置有没有覆盖默认配置。
5. 确认网络与 HTTP 客户端。 DNS、路由、防火墙、连接池和 TLS 等问题，负载均衡器本身解决不了。
6. 确认超时与重试。 日志里区分首次请求失败、换实例重试失败和总耗时超限，避免把多种故障揉成一个“调用超时”。

排查时最好记录服务名、选中的实例、重试次数、耗时和最终异常。没有这些信息，所谓“轮询不均”很容易只是实例注册不完整、请求量分布不均或某个下游响应特别慢。

八、总结

Ribbon 把服务实例选择放在调用方，核心价值是让服务调用使用逻辑名称，并由客户端结合实例列表和策略完成选择。理解它时要把服务发现、实例过滤、负载均衡规则、HTTP 请求和重试分开看：它们处在同一条调用链路上，却不是同一个职责。

对于旧系统，Ribbon 仍值得读懂，因为它承载了大量历史 Spring Cloud 项目的调用逻辑；对于新系统，则应优先采用当前 Spring Cloud 版本支持的负载均衡组件。真正稳的不是某个策略名字，而是清楚实例从哪来、请求会选到谁、失败后会发生什么，以及重试是否会重复业务操作。