【Spring Cloud】Ribbon 实现负载均衡的原理，策略以及饥饿加载

我不是女神ヾ 2023-10-16 15:33 7阅读 0赞

#### 文章目录 ####

*  前言
 *  一、什么是 Ribbon
 *  二、Ribbon 实现负载均衡的原理
 *   *  2.1 负载均衡的流程
     *  2.2 Ribbon 实现负载均衡的源码剖析
 *  三、Ribbon 负载均衡策略
 *   *  3.1 负载均衡策略
     *  3.2 演示 Ribbon 负载均衡策略的更改
 *  四、Ribbon 的饥饿加载
 *   *  4.1查看 Ribbon 的懒加载
     *  4.2 Ribbon 的饥饿加载模式

--------------------

## 前言 ##

在前文[《深入理解 Eureka 注册中心的原理、服务的注册与发现》][Eureka]中，介绍了如何使用 Eureka 实现服务的注册与拉取，并且通过添加 `@LoadBalanced` 注解实现了负载均衡。这种自动化的背后隐藏着许多疑问：

*  服务是在何时进行拉取的？
 *  负载均衡是如何实现的？
 *  负载均衡的原理和策略又是什么？

本文旨在深入探讨使用 Eureka 实现负载均衡的原理，为我们理解微服务架构中服务调用的内部机制提供更清晰的认识。通过解答这些疑惑，我们将更好地理解服务发现、负载均衡的运作方式，为构建高性能、稳定的分布式系统打下坚实的基础。

## 一、什么是 Ribbon ##

**Ribbon** 是一个基于 HTTP 和 TCP 客户端的负载均衡器。在微服务架构中，服务的调用通常涉及到负载均衡的问题，即在多个服务提供方中选择一个进行调用。Ribbon 提供了一种简单而有效的负载均衡解决方案。

Ribbon 最初是 Netflix 公司开发的，后来成为 Spring Cloud 项目的一部分。它的主要作用是在服务消费者和提供者之间实现均衡的流量分发，确保每个服务提供者都能够得到适当的请求，避免出现服务过载或资源浪费的情况。

**具体而言，Ribbon 实现了以下功能：**

1.  **负载均衡算法：** Ribbon 支持多种负载均衡算法，例如轮询、随机、权重轮询等，使得服务消费者可以根据实际场景选择适当的负载均衡策略。
2.  **服务实例的自动发现：** Ribbon 与 Eureka 等服务注册中心集成，能够自动获取可用的服务实例列表。
3.  **故障转移和重试机制：** Ribbon 具备故障转移和重试功能，可以在服务提供者发生故障时自动切换到其他健康的实例，提高系统的稳定性和可用性。

在 Spring Cloud 中，Ribbon 作为一个负载均衡的客户端组件，通过拦截微服务的调用请求，动态地选择目标服务实例，从而分配请求的负载，实现了对服务调用的细粒度控制。

## 二、Ribbon 实现负载均衡的原理 ##

### 2.1 负载均衡的流程 ###

Ribbon 实现负载均衡的流程图如下：  
![负载均衡流程][19d9d22f25694247a99563468904e9fc.png]

**下面是对这个流程的详细说明：**

1.  首先，服务消费者发起请求，Ribbon 负载均衡器收到请求之后，获取请求路径中的服务名称，例如 `userservice`。
2.  然后负载均衡器使用这个获取到的服务名称去向 Eureka Service 拉取对应的服务。
3.  在实际生产中，一个服务一般都会有多个实例，因此拉取到的就是一个服务列表，列表中包含了这个服务所有正常实例的 IP 和端口号。
4.  负载均衡器在获取到这个列表之后，使用当前采取的负载均衡策略去选择一个合适的服务，然后再访问这个服务。

这个流程确保了服务的请求能够被合理地分发到多个实例中，从而实现了负载均衡。

### 2.2 Ribbon 实现负载均衡的源码剖析 ###

首先，Ribbon 实现负载均衡使用到的一个类叫做 `LoadBalancerInterceptor`负载均衡拦截器，可以通过 IDEA 查看它的源码：

![5d5009e354dc486fb82a355e5f455878.png][]  
发现它实现了一个 `ClientHttpRequestInterceptor`接口，即客户端 HTTP 请求拦截器：  
![4bc420cbbc634a6c976fff808bfe5d93.png][]

它会拦截 `RestTemplate` 发生的 HTTP 请求，`ClientHttpRequestInterceptor` 是一个接口，并且其中包含了一个 `intercept` 方法，因此`LoadBalancerInterceptor` 作为实现这个接口的类也一定重写了 `intercept` 方法，此时我们可以在这个方法中设置一个断点进行调试，以追踪代码的运行：

![3ce556b7bc6b49e5bbabba8455a44a3d.png][]

1.  `request.getURI()` 获取请求地址：  
    ![d2c31bc0160948489d1d5f9de8abc488.png][]
2.  `originalUri.getHost()` 获取到了请求的地址中的主机名，此时获取到的就是服务的名称，也就是 `userservice`：

![23d9a7d1e1204f23bc39d47dc2d74154.png][]  
3. 当找到了服务的名称之后，接下来要做的工作就是向 EurekaServer 去拉取对应的服务了，然后这个方法就把获取到的服务名交给了一个`RibbonLoadBalancerClient` （Ribbon负载均衡客户端）进行处理。  
![767a0bf9b5964af98e2bcbf5c031e27b.png][]  
4. **继续调试代码，进入`execute` 方法：**

![bf61213fe8ac4e0dbd2ae3a26e17e616.png][]  
![25fe29b11f7149a9ac04decd85255621.png][]

1.  继续往下走，就得到了一个 `LoadBalancer` 对象，：  
    ![5d8a83f1f4c94aa0babb7bb096f4a557.png][]  
    这个对象的名称叫做“动态服务列表均衡器”，查看这个对象的内容，可以发现服务列表中服务的数量为3，这三个服务就是获取到的三个 `user-service` 向 EurekaServer 中注册的服务。  
    ![15f91601eb57477f972b98a39e033df4.png][]

因此`getLoadBalancer` 方法的作用就是根据服务名称向 EurekaServer 中寻找服务列表。当找到了服务列表之后，我们就可以大胆的猜测，下一步所要做的工作就是进行负载均衡操作了。

1.  此时，我们进入 `getServer` 方法：  
    ![5c115042bf5e427c831b4fa528fd36c2.png][]
2.  接下来就调用了`chooseServer` 方法，进入这个方法：

![在这里插入图片描述][bcfd28c14ee1450a8d32d4d6831a8819.png]  
![e7b874b292c349ba8d6e71fd1c7bcb74.png][]  
8. 然后再进入`chooseServer` 方法，最后找到了`rule.choose`方法：  
![57e268eb1e294efaa01c816d0e1b175c.png][]  
此时查看 rule 对象，发现是一个接口：  
![0837ad1485294529997f7240ecc2d405.png][]  
既然是接口，那么就有实现类：

![30845cb8fed34680ab699e437efd9467.png][]

此时发现的实现类就是负载均衡的规则了。大致的规则有随机、轮询等等。

1.  最后，通过默认的规则，就选择到了 8082 这个端口的服务了。

![6120596fa4ba49ebb69c6a09f92b9e8b.png][]  
接下来就可以使用真正的IP和端口号去代替 `userservice` ，然后去访问指定了服务了。

以上就是 Ribbon 实现负载均衡的源码剖析，通过调试了方法深入探索了服务发现与负载均衡是实现流程，帮助我们更好的理解了服务发现、负载均衡的运作方式

## 三、Ribbon 负载均衡策略 ##

### 3.1 负载均衡策略 ###

通过上面的源码分析不难发现，Ribbon 的负载均衡规则是一个叫做 IRule 的接口来定义的，每一个子接口都是一种规则。

关于 IRule 接口的继承体系如下图所示：  
![4f9a2e7f58c74aabb96e60231a030953.png][]

关于 Ribbon 的负载均衡策略可以总结如下表所示：

<table> 
 <thead> 
  <tr> 
   <th align="left">内置负载均衡规则类</th> 
   <th align="left">规则描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">RoundRobinRule</td> 
   <td align="left">简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。</td> 
  </tr> 
  <tr> 
   <td align="left">AvailabilityFilteringRule</td> 
   <td align="left">对短路和并发数过高的服务器进行忽略</td> 
  </tr> 
  <tr> 
   <td align="left">WeightedResponseTimeRule</td> 
   <td align="left">为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。</td> 
  </tr> 
  <tr> 
   <td align="left">ZoneAvoidanceRule</td> 
   <td align="left">以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。</td> 
  </tr> 
  <tr> 
   <td align="left">BestAvailableRule</td> 
   <td align="left">忽略那些短路的服务器，并选择并发数较低的服务器。</td> 
  </tr> 
  <tr> 
   <td align="left">RandomRule</td> 
   <td align="left">随机选择一个可用的服务器</td> 
  </tr> 
  <tr> 
   <td align="left">RetryRule</td> 
   <td align="left">重试机制的选择逻辑</td> 
  </tr> 
 </tbody> 
</table>

Ribbon 提供了这些内置的负载均衡规则，同时也支持自定义负载均衡规则。在实际应用中，根据业务特点选择合适的负载均衡策略是非常重要的。下面演示了 Ribbon 负载均衡策略的更改。

### 3.2 演示 Ribbon 负载均衡策略的更改 ###

通过定义IRule实现可以修改负载均衡规则，有两种方式：

1.  代码方式：在`order-service`中的`OrderApplication`启动类中，定义一个新的`IRule`，并使用 `@Bean` 注解注册到 Spring 容器中：

@Bean
    public IRule randomRule(){
        
        return new RandomRule();
    }

1.  配置文件方式：在`order-service`的`application.yml`文件中，添加新的配置也可以修改规则：

# 修改 Ribbon 负载均衡策略
    userservice:
      ribbon:
        NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则

例如，下面是修改了负载均衡策略之后，再次使用 `order-service` 访问订单的结果。可以发现，现在不再是以轮询的方式挑选`user-service`服务了，而是以随机的方式进行挑选了。

![154510ed4c0d4143b57abe37420d437f.png][]

![91577512727447ee9342415af689be8b.png][]

## 四、Ribbon 的饥饿加载 ##

### 4.1查看 Ribbon 的懒加载 ###

当我们重新启动 `order-service` 服务，然后在浏览器中进行订单访问，可以发现如下的现象：

当 `order-service` 服务启动后，第一次访问服务可以发现耗时需要三百多毫秒：

![cd70ba8d154242e7b82bb41952f2feba.png][]  
然后，再次访问多次，可以发现耗时都变成了十几毫米：  
![5bc53ac298fc40ab92fb12d035d9cfbb.png][]  
![46ac2705f4294f9d9a80f81c50c55d32.png][]  
通过以上的现象就可以发现，Ribbon 默认采用的是懒加载模式，就像单例模式的懒汉模式一样，第一次访问的时候才会去创建`LoadBalanceClient`实例，请求时间会很长。

### 4.2 Ribbon 的饥饿加载模式 ###

为了解决上述懒加载的耗时问题，Ribbon 还提供了饥饿加载模式，饥饿加载则会在项目启动时创建，降低第一次访问的耗时。

**通过下面配置开启饥饿加载：**

此时重启 `order-service`服务：

在启动服务的时候，就会发现日志变得更多了：  
![79e6939ec89f4ff6bdf0f1b68076fb96.png][]  
这个日志的内容就是加载`LoadBalanceClient`实例所产生的日志。

再次首次访问 `order-service`服务，就会发现消耗的时间变短了：

![c17fbe239820422c962ebf1c0b060bf2.png][]

[Eureka]: https://blog.csdn.net/qq_61635026/article/details/133356097?spm=1001.2014.3001.5501
[19d9d22f25694247a99563468904e9fc.png]: https://img-blog.csdnimg.cn/19d9d22f25694247a99563468904e9fc.png
[5d5009e354dc486fb82a355e5f455878.png]: https://img-blog.csdnimg.cn/5d5009e354dc486fb82a355e5f455878.png
[4bc420cbbc634a6c976fff808bfe5d93.png]: https://img-blog.csdnimg.cn/4bc420cbbc634a6c976fff808bfe5d93.png
[3ce556b7bc6b49e5bbabba8455a44a3d.png]: https://img-blog.csdnimg.cn/3ce556b7bc6b49e5bbabba8455a44a3d.png
[d2c31bc0160948489d1d5f9de8abc488.png]: https://img-blog.csdnimg.cn/d2c31bc0160948489d1d5f9de8abc488.png
[23d9a7d1e1204f23bc39d47dc2d74154.png]: https://img-blog.csdnimg.cn/23d9a7d1e1204f23bc39d47dc2d74154.png
[767a0bf9b5964af98e2bcbf5c031e27b.png]: https://img-blog.csdnimg.cn/767a0bf9b5964af98e2bcbf5c031e27b.png
[bf61213fe8ac4e0dbd2ae3a26e17e616.png]: https://img-blog.csdnimg.cn/bf61213fe8ac4e0dbd2ae3a26e17e616.png
[25fe29b11f7149a9ac04decd85255621.png]: https://img-blog.csdnimg.cn/25fe29b11f7149a9ac04decd85255621.png
[5d8a83f1f4c94aa0babb7bb096f4a557.png]: https://img-blog.csdnimg.cn/5d8a83f1f4c94aa0babb7bb096f4a557.png
[15f91601eb57477f972b98a39e033df4.png]: https://img-blog.csdnimg.cn/15f91601eb57477f972b98a39e033df4.png
[5c115042bf5e427c831b4fa528fd36c2.png]: https://img-blog.csdnimg.cn/5c115042bf5e427c831b4fa528fd36c2.png
[bcfd28c14ee1450a8d32d4d6831a8819.png]: https://img-blog.csdnimg.cn/bcfd28c14ee1450a8d32d4d6831a8819.png
[e7b874b292c349ba8d6e71fd1c7bcb74.png]: https://img-blog.csdnimg.cn/e7b874b292c349ba8d6e71fd1c7bcb74.png
[57e268eb1e294efaa01c816d0e1b175c.png]: https://img-blog.csdnimg.cn/57e268eb1e294efaa01c816d0e1b175c.png
[0837ad1485294529997f7240ecc2d405.png]: https://img-blog.csdnimg.cn/0837ad1485294529997f7240ecc2d405.png
[30845cb8fed34680ab699e437efd9467.png]: https://img-blog.csdnimg.cn/30845cb8fed34680ab699e437efd9467.png
[6120596fa4ba49ebb69c6a09f92b9e8b.png]: https://img-blog.csdnimg.cn/6120596fa4ba49ebb69c6a09f92b9e8b.png
[4f9a2e7f58c74aabb96e60231a030953.png]: https://img-blog.csdnimg.cn/4f9a2e7f58c74aabb96e60231a030953.png
[154510ed4c0d4143b57abe37420d437f.png]: https://img-blog.csdnimg.cn/154510ed4c0d4143b57abe37420d437f.png
[91577512727447ee9342415af689be8b.png]: https://img-blog.csdnimg.cn/91577512727447ee9342415af689be8b.png
[cd70ba8d154242e7b82bb41952f2feba.png]: https://img-blog.csdnimg.cn/cd70ba8d154242e7b82bb41952f2feba.png
[5bc53ac298fc40ab92fb12d035d9cfbb.png]: https://img-blog.csdnimg.cn/5bc53ac298fc40ab92fb12d035d9cfbb.png
[46ac2705f4294f9d9a80f81c50c55d32.png]: https://img-blog.csdnimg.cn/46ac2705f4294f9d9a80f81c50c55d32.png
[79e6939ec89f4ff6bdf0f1b68076fb96.png]: https://img-blog.csdnimg.cn/79e6939ec89f4ff6bdf0f1b68076fb96.png
[c17fbe239820422c962ebf1c0b060bf2.png]: https://img-blog.csdnimg.cn/c17fbe239820422c962ebf1c0b060bf2.png