Ribbon负载均衡

Ribbon负载均衡

Ribbon

Eureka帮我们集成了负载均衡组件：Ribbon，简单修改代码即可使用。

什么是Ribbon：客户端负载均衡组件

开启负载均衡

1、Eureka中已经集成了Ribbon，所以我们无需引入新的依赖，直接修改代码。

2、spring-consumer的引导类，在RestTemplate的配置方法上添加@LoadBalanced注解

@Bean
@LoadBalanced  //不添加这个注解，不能直接用服务名访问
public RestTemplate getRestTemplate(RestTemplateBuilder builder){
    return builder.build();
}

3、修改调用方式，不再手动获取ip和端口，而是直接通过服务名称调用：

@RestController
public class UserController {

    @Autowired
    private RestTemplate restTemplate;
    
    @RequestMapping(value = "/consumerLoadBalanced/{id}")
    public String consumerLoadBalanced(@PathVariable String id){
        String url = "http://spring-provider/provider/" + id;
        String consumer = restTemplate.getForObject(url, String.class);
        return "LoadBalanced restTemplate consumer " + consumer;
    }

}

4、运行结果：

第一次调用结果

第二调用结果

Ribbon 的超时和超时重试

Ribbon 是有超时设置，以及超时之后的重试功能的。但是，在 RestTemplate 和 Ribbon 结合的方案中，Ribbon 的超时设置和重试设置的配置方式一直在变动，因此有很多『配置无效』的现象，十分诡异。

考虑到我们在后续的项目中不会使用 RestTemplate 和 Ribbon 整合，而是使用 OpenFeign ，因此，这里就不展开解释了。

Ribbon 的饥饿加载

默认情况下，服务消费方调用服务提供方接口的时候，第一次请求会慢一些，甚至会超时，而之后的调用就没有问题了。

这是因为 Ribbon 进行客户端负载均衡的 Client 并不是在服务启动的时候就初始化好的，而是在调用的时候才会去创建相应的 Client，所以第一次调用的耗时不仅仅包含发送HTTP请求的时间，还包含了创建 RibbonClient 的时间，这样一来如果创建时间速度较慢，同时设置的超时时间又比较短的话，很容易就会出现上面所描述的现象。

你可以通过启用 Ribbon 的饥饿加载（即立即加载）模式，并指定在项目启动时就要加载的服务：

ribbon:
  eager-load:
    enabled: true   # 开启饥饿加载
    clients: spring-provider, xxx        # (服务名)需要饥饿加载的服务

负载均衡策略

1.轮询策略

轮询策略：RoundRobinRule，按照一定的顺序依次调用服务实例。比如一共有 3 个服务，第一次调用服务 1，第二次调用服务 2，第三次调用服务 3，依次类推。此策略的配置设置如下：

spring-provider: # nacos中的服务id  
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule #设置负载均衡

格式是：{服务名称}.ribbon.NFLoadBalancerRuleClassName，值就是IRule的实现类。

2.权重策略

权重策略：WeightedResponseTimeRule，根据每个服务提供者的响应时间分配一个权重，响应时间越长，权重越小，被选中的可能性也就越低。它的实现原理是，刚开始使用轮询策略并开启一个计时器，每一段时间收集一次所有服务提供者的平均响应时间，然后再给每个服务提供者附上一个权重，权重越高被选中的概率也越大。此策略的配置设置如下：

spring-provider: # nacos中的服务id
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.WeightedResponseTimeRule

3.随机策略

随机策略：RandomRule，从服务提供者的列表中随机选择一个服务实例。此策略的配置设置如下：

spring-provider: # nacos中的服务id
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

4.最小连接数策略

最小连接数策略：BestAvailableRule，也叫最小并发数策略，它是遍历服务提供者列表，选取连接数最小的⼀个服务实例。如果有相同的最小连接数，那么会调用轮询策略进行选取。此策略的配置设置如下：

spring-provider: # nacos中的服务id
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.BestAvailableRule #设置负载均衡

5.重试策略

重试策略：RetryRule，按照轮询策略来获取服务，如果获取的服务实例为 null 或已经失效，则在指定的时间之内不断地进行重试来获取服务，如果超过指定时间依然没获取到服务实例则返回 null。此策略的配置设置如下：

ribbon:
  ConnectTimeout: 2000 # 请求连接的超时时间
  ReadTimeout: 5000 # 请求处理的超时时间
spring-provider: # nacos 中的服务 id
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule #设置负载均衡

6.可用性敏感策略

可用敏感性策略：AvailabilityFilteringRule，先过滤掉非健康的服务实例，然后再选择连接数较小的服务实例。此策略的配置设置如下：

spring-provider: # nacos中的服务id
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.AvailabilityFilteringRule

7.区域敏感策略

区域敏感策略：ZoneAvoidanceRule，根据服务所在区域（zone）的性能和服务的可用性来选择服务实例，在没有区域的环境下，该策略和轮询策略类似。此策略的配置设置如下：

spring-provider: # nacos中的服务id
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.ZoneAvoidanceRule

​

Ribbon与Nginx的区别

Nginx是基于服务端的负载均衡，客户端所有请求统一交给 nginx，由 nginx 进行实现负载均衡请求转发，Nginx保持服务清单的同时，也负责负载均衡算法

Ribbon是从 eureka 注册中心服务器端上获取服务注册信息列表，缓存到本地，然后在本地实现轮询负载均衡策略，Ribbon不负责出来服务清单，

应用场景的区别：

1、Nginx适合于服务器端实现负载均衡比如 Tomcat ，Ribbon适合与在微服务中RPC远程调用实现本地服务负载均衡，比如 Dubbo、SpringCloud 中都是采用本地负载均衡。

spring cloud的Netflix中提供了两个组件实现软负载均衡调用：ribbon和feign。

2、Ribbon

是一个基于 HTTP 和 TCP 客户端的负载均衡器，可以在客户端配置 ribbonServerList（服务端列表），然后轮询请求以实现均衡负载。

3、springcloud的ribbon和nginx有什么区别？哪个性能好？
nginx性能好，但ribbon可以剔除不健康节点，nginx剔除节点比较复杂。ribbon还可以配合熔断器一起工作；

ribbon是客户端负载均衡，nginx是服务端负载均衡。客户端负载均衡，所有客户端节点都维护自己要访问的服务端清单。服务端负载均衡的软件模块会维护一个可用的服务清单；

ribbon 是一个客户端负载均衡器，可以简单的理解成类似于 nginx的负载均衡模块的功能。