Ribbon
Ribbon----客户端负载均衡器
如果有多个相同的服务注册到Eureka中，服务消费者应该选择哪个服务器就成了一个问题。这里很明显也是一个负载均衡问题，可以使用Ribbon解决或者Spring Cloud Loadbalancer来解决。
在Spring Cloud 中，当Ribbon和Eureka配合使用的时候，Ribbon可从Eureka Server中获取服务提供者地址列表，并基于负载均衡算法，请求其中一个服务提供者实例。
Nginx是服务器负载均衡，客户端所有请求都会交给nginx,然后由nginx实现转发请求，即负载均衡是由服务端实现的。即集中式LB，在服务端消费方和提供方之间使用独立的LB设施（可以是硬件，如F5，也可以是软件，如nginx）,由该设施负责把访问请求通过某种策略转发至服务的提供方。
Ribbon本地负载均衡，在调用微服务接口时候，会在注册中心上获取注册信息服务列表之后缓存到本地JVM中，从而在本地实现RPC远程服务调用技术。即进程内LB,将LB逻辑集成到消费方，消费方从服务服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的服务器。
在Spring Cloud 构建的微服务中，Ribbon作为服务消费者的负载均衡器，有两种使用方式，一种是与RestTemplate相结合，另一种是与Feign相结合。
我们这里讲解Ribbon与RestTemplate相结合方式。
注：springcloud 2020.0.1 版本之后 删除了eureka中的ribbon，替代ribbon的是spring cloud自带的LoadBalancer，但公司开发中并没有那么快更新，大部分项目还是在用Ribbon，所以两个我们都讲解一下。
添加一个公共返回类，这样不同服务之间访问，返回的是同样的结果体，restfu章节中讲过，我们直接拿过来用。
这里我们启动两个SEARCH服务,并注册到Eureka服务器中
idea中想要启动两个SEARCH服务，需要使用不同的端口，设置如下：
点击Eureka02Application,然后点击上面的复制配置,设置端口
将两个服务放在一组，这样可以启动这个组，就可以启动两个服务
启动服务组:
测试:
添加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服务
访问User服务中的方法，该方法中调用Search服务中的方法，第一次访问的是Search8081端口，第二次访问的是Search8082端口，说明负载均衡默认采用的是轮询方法.
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 |
方式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
``
