【SpringCloud】Ribbon负载均衡原理、负载均衡策略、饥饿加载

---

个人主页： 叶落闲庭
我的专栏：
c语言
数据结构
javaEE
操作系统
Redis

石可破也，而不可夺坚；丹可磨也，而不可夺赤。

---

一、 Ribbon负载均衡原理

1.1 负载均衡流程

在之前的远程调用中，有一个order-service服务需要调用user-service,这个user-service有两个不同的端口号，而在order-service的请求路径中是通过String url = "http://userservice/user/" + order.getUserId();的方式发送http请求，这时我们需要知道这个url字符串中的http://userservice/user/是否是一个真实可用的地址，显然它不是一个真实可用的地址，所以当order-service发起请求时是不会到达user-service的，因此，在这两者之间一定会有一个组件把它拦截下来做一定的处理从而找到真实的ip端口，Ribbon就是负责做这个处理的，Ribbon通过order-service发过来的url得到需要请求的服务，然后再去eureka注册中心找到对应的服务，拉取服务给到order-service，拉取到的服务可能是多个，这时Ribbon就会对多个服务进行负载均衡，挑一个返回给order-service。

---

---

1.2 负载均衡原理

在order-service的启动类中，注入了RestTemplate的bean，并给这个bean添加了@LoadBalanced注解，这个注解就是一个标记，表示这个RestTemplate发起的请求要被Ribbon拦截和处理，具体的拦截动作可以根据源码来分析：

• 以idea来演示拦截过程：
• 在idea中双击shift，搜索LoadBalancerInterceptor.java:

---

---

• 这个类实现了客户端http请求拦截器的接口：

---

---

• 实现了该接口中的方法，我们通过打断点来分析Ribbon负载均衡原理：
  

---

• 当刷新浏览器时，会直接跳转到断点处：

---

---

• 继续调试代码，得到userservice/user/1：

---

---

• 继续调试代码会得到服务的名称userservice:

---

---

• 找到了服务的名称，接下来就可以去eureka进行服务的拉取，这时会将userservice交给loadBalancer,也就是Ribbon负载均衡：

---

---

• 跟进这个方法继续调试，这时进入了RibbonLoadBalancerClient.java中的excute方法，excute中有一个参数(服务id)，会将这个参数传给getLoadBalancer方法，去处理，执行完后会得到一个getLoadBalancer对象，这个对象的名字叫做DynamicServerListLoadBalancer（动态服务列表负载均衡），在它里面有一个allServerList的参数，保存了所有的userservice服务的信息

---

---

---

---

• 经过这步操作就可以根据服务名称拉取到了服务列表，下一步就是负载均衡，跟进getServer继续调试观察：

---

---

---

• 一步步跟进，找到了一个rule.choose的方法，这个rule就是从DynamicServerList选择的规则，这个rule的类型是IRule的接口，所以负载均衡的策略是由IRule来决定的

---

---

• 继续调试，会返回一个选择的service:

---

---

• 接下来就可以根据真实的地址拿到相应的服务了

二、Ribbon负载均衡策略

内置负载均衡规则类	规则描述
RoundRobinRule	简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。
AvailabilityFilteringRule	对以下两种服务器进行忽略：(1)在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。(2)并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限，可以由客户端的,,ActiveConnectionsLimit属性进行配置。
WeightedResponseTimeRule	为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。
ZoneAvoidanceRule	以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Z0one内的多个服务做轮询。
BestAvailableRule	忽略哪些短路的服务器，并选择并发数较低的服务器
RandomRule	随机选择一个可用的服务器
RetryRule	重试机制的选择逻辑

2.1 定义IRule修改负载均衡规则

• 方式一： 在order–service中的OrderApplication类中，定义一个新的IRule：

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

• 方式二： 配置文件方式：在order–servicel的application.yml文件中，添加新的配置也可以修改规则：

userservice:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则

三 、饥饿加载

• Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient,请求时间会很长。
• 第一次加载，耗时很长：

---

• 第二次加载，耗时变短：

---

---

• 而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载：

ribbon:
  eager-load:
    enabled: true # 开启饥饿加载
    clients: 
    	- userservice # 指定饥饿加载的服务名称
    	- xxservice

• 项目启动就加载好

---

---

• 此时第一次加载浏览器比之前缩减了一半时间，由于还需要加载其他文件，所以这里看起来时间也是很久，但比之前确实缩减了，速度也得到了一定的提升：

---