Ribbon

Ribbon----客户端负载均衡器

一.为什么要使用Ribbon？

如果有多个相同的服务注册到Eureka中，服务消费者应该选择哪个服务器就成了一个问题。这里很明显也是一个负载均衡问题，可以使用Ribbon解决或者Spring Cloud Loadbalancer来解决。

在Spring Cloud 中，当Ribbon和Eureka配合使用的时候，Ribbon可从Eureka Server中获取服务提供者地址列表，并基于负载均衡算法，请求其中一个服务提供者实例。

二.Nginx和Ribbon负载均衡的区别

Nginx是服务器负载均衡，客户端所有请求都会交给nginx,然后由nginx实现转发请求，即负载均衡是由服务端实现的。即集中式LB，在服务端消费方和提供方之间使用独立的LB设施（可以是硬件，如F5，也可以是软件，如nginx）,由该设施负责把访问请求通过某种策略转发至服务的提供方。

Ribbon本地负载均衡，在调用微服务接口时候，会在注册中心上获取注册信息服务列表之后缓存到本地JVM中，从而在本地实现RPC远程服务调用技术。即进程内LB,将LB逻辑集成到消费方，消费方从服务服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的服务器。

三.Ribbon的实现方式

在Spring Cloud 构建的微服务中，Ribbon作为服务消费者的负载均衡器，有两种使用方式，一种是与RestTemplate相结合，另一种是与Feign相结合。

我们这里讲解Ribbon与RestTemplate相结合方式。

注：springcloud 2020.0.1 版本之后 删除了eureka中的ribbon，替代ribbon的是spring cloud自带的LoadBalancer，但公司开发中并没有那么快更新，大部分项目还是在用Ribbon，所以两个我们都讲解一下。

四.Ribbon与RestTemplate相结合实现负载均衡.

4.1改造以下前面的SEARCH服务

添加一个公共返回类，这样不同服务之间访问，返回的是同样的结果体，restfu章节中讲过，我们直接拿过来用。

4.2 服务提供者需要启动多个服务实例并注册到一个注册中心或多个相关联的服务注册中心。

这里我们启动两个SEARCH服务,并注册到Eureka服务器中

idea中想要启动两个SEARCH服务，需要使用不同的端口，设置如下：

点击Eureka02Application,然后点击上面的复制配置,设置端口

将两个服务放在一组，这样可以启动这个组，就可以启动两个服务

启动服务组:

测试:

4.3 服务消费者通过调用被@LoadBalanced注解修饰的Restemplate来实现面向服务的接口调用。

添加Ribbon包

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

创建一个配置类，将RestTemplate对象的创建放在配置类中

import org.springframework.cloud.client.loadbalancer.LoadBalanced;
  import org.springframework.context.annotation.Bean;
  import org.springframework.context.annotation.Configuration;
  import org.springframework.web.client.RestTemplate;

  @Configuration
  public class RemoteClientConfiguration {

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

  }

修改前面的User服务,通过restTemplate访问SEARCH服务

重启启动User服务

4.4测试

访问User服务中的方法，该方法中调用Search服务中的方法，第一次访问的是Search8081端口，第二次访问的是Search8082端口，说明负载均衡默认采用的是轮询方法.

五 Ribbon负载均衡方式

5.1Ribbon负载均衡方式有哪些？

Ribbon提供了七种负载均衡策略，默认的负载均衡策略是轮询策略。

策略类	命名	描述
RandomRule	随机策略	随机选择server
RoundRobinRule	轮询策略	轮询选择， 轮询index，选择index对应位置的Server；
RetryRule	重试策略	对选定的负载均衡策略机上重试机制，在一个配置时间段内当选择Server不成功，则一直尝试使用subRule的方式选择一个可用的server；
BestAvailableRule	最低并发策略	逐个考察server，如果server断路器打开，则忽略，再选择其中并发链接最低的server
AvailabilityFilteringRule	可用过滤策略	过滤掉一直失败并被标记为circuit tripped的server，过滤掉那些高并发链接的server（active connections超过配置的阈值）或者使用一个AvailabilityPredicate来包含过滤server的逻辑，其实就就是检查status里记录的各个Server的运行状态；
ResponseTimeWeightedRule	响应时间加权重策略	根据server的响应时间分配权重，响应时间越长，权重越低，被选择到的概率也就越低。响应时间越短，权重越高，被选中的概率越高，这个策略很贴切，综合了各种因素，比如：网络，磁盘，io等，都直接影响响应时间
ZoneAvoidanceRule	区域权重策略	综合判断server所在区域的性能，和server的可用性，轮询选择server并且判断一个AWS Zone的运行性能是否可用，剔除不可用的Zone中的所有server

5.2 修改负载均衡策略的两种方式

方式1:使用JavaBean

在配置类中添加一个方法，返回需要的负载均衡策略对象,IRule是接口,RandomRule是随机负载均衡方式

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

方式2：

在配置文件中设置：

前面加服务名表示 指定当前服务的负载均衡方式

SEARCH:
  ribbon:
    #负载策略调整        
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

不加服务名，表示全局

ribbon:
    #负载策略调整        
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

lix.loadbalancer.RandomRule

不加服务名，表示全局

ribbon:
#负载策略调整
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
``