Ribbon负载均衡

1、关于负载均衡

  负载均衡一般分为服务器端负载均衡和客户端负载均衡

        所谓服务器端负载均衡，比如Nginx、F5这些，请求到达服务器之后由这些负载均衡器根据一定的算法将请求路由到目标服务器处理。

        所谓客户端负载均衡，比如我们要说的Ribbon，服务消费者客户端会有一个服务器地址列表，调用方在请求前通过一定的负载均衡算法选择一个服务器进行访问，负载均衡算法的执行是在请求客户端进行。

        Ribbon是Netflix发布的负载均衡器。Eureka⼀般配合Ribbon进行使用，Ribbon利用从Eureka中读取到服务信息，在调用服务提供者提供的服务时，会根据一定的算法进行负载。

2、Ribbon高级应用 

        不需要引入额外的Jar坐标，因为在服务消费者中我们引入过eureka-client，它会引入Ribbon相关Jar。

  代码中使用如下，在RestTemplate上添加对应注解即可 （消费者）

@Bean
// Ribbon负载均衡
@LoadBalanced
public RestTemplate getRestTemplate() {
    return new RestTemplate();
}

  修改服务提供者api返回值，返回当前实例的端口号，便于观察负载情况

测试 

打印如下（默认策略为轮询）

3、Ribbon负载均衡策略

Ribbon内置了多种负载均衡策略，内部负责复杂均衡的顶级接口为 com.netflix.loadbalancer.IRule ，类树如下

负载均衡策略	描述
RoundRobinRule：轮询策略	默认超过10次获取到的server都不可用，会返回⼀个空的server
RandomRule：随机策略	如果随机到的server为null或者不可用的话，会while不停的循环选取
RetryRule：重试策略	一定时限内循环重试。默认继承RoundRobinRule，也⽀持⾃定义注入，RetryRule会在每次选取之后，对选举的server进行判断，是否为null，是否alive，并且在500ms内会不停的选取判断。而RoundRobinRule失效的策略是超过10次，RandomRule是没有失效时间的概念，只要serverList没都挂。
BestAvailableRule：最小连接数策略	遍历serverList，选取出可用的且连接数最小的⼀个server。该算法里面有⼀个LoadBalancerStats的成员变量，会存储所有server的运行状况和连接数。如果选取到的server为null，那么会调用RoundRobinRule重新选取。1（1） 2（1）3（1）
AvailabilityFilteringRule：可用过滤策略	扩展了轮询策略，会先通过默认的轮询选取⼀个server，再去判断该server是否超时可用，当前连接数是否超限，都成功再返回。
ZoneAvoidanceRule：区域权衡策略（默认策略）	扩展了轮询策略，继承了2个过滤器：ZoneAvoidancePredicate和AvailabilityPredicate，除了过滤超时和链接数过多的server，还会过滤掉不符合要求的zone区域里面的所有节点，AWS --ZONE 在⼀个区域/机房内的服务实例中轮询

修改负载均衡策略 

# 针对的被调⽤⽅微服务名称,不加就是全局⽣效
lagou-service-resume:
    ribbon:
        NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule #负载策略调整（策略类的全限定类名）