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的负载均衡模块的功能。