第一代 Spring Cloud 核⼼组件-2.Ribbon负载均衡

关于负载均衡

负载均衡⼀般分为服务器端负载均衡和客户端负载均衡所谓服务器端负载均衡,⽐如Nginx、F5这些,请求到达服务器之后由这些负载均衡器根据⼀定的算法将请求路由到⽬标服务器处理。
所谓客户端负载均衡,⽐如我们要说的Ribbon,服务消费者客户端会有⼀个服务器地址列表,调⽤⽅在请求前通过⼀定的负载均衡算法选择⼀个服务器进⾏访问,负载均衡算法的执⾏是在请求客户端进⾏。
Ribbon是Netflix发布的负载均衡器。Eureka⼀般配合Ribbon进⾏使⽤,Ribbon利⽤从Eureka中读取到服务信息,在调⽤服务提供者提供的服务时,会根据⼀定的算法进⾏负载。
第一代 Spring Cloud 核⼼组件-2.Ribbon负载均衡_第1张图片

Ribbon⾼级应⽤

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

第一代 Spring Cloud 核⼼组件-2.Ribbon负载均衡_第2张图片

代码中使⽤如下,在RestTemplate上添加对应注解即可

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

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

第一代 Spring Cloud 核⼼组件-2.Ribbon负载均衡_第3张图片

测试

打印如下

Ribbon负载均衡策略

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

第一代 Spring Cloud 核⼼组件-2.Ribbon负载均衡_第4张图片

负载均衡策略 描述
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重新选取。
AvailabilityFilteringRule:可⽤过滤策略 扩展了轮询策略,会先通过默认的轮询选取⼀个server,再去判断该server是否超时可⽤,当前连接数是否超限,都成功再返回。
ZoneAvoidanceRule:区域权衡策略(默认策略) 扩展了轮询策略,继承了2个过滤器:ZoneAvoidancePredicate和AvailabilityPredicate,除了过滤超时和链接数过多的server,还会过滤掉不符合要求的zone区域⾥⾯的所有节点,AWS --ZONE 在⼀个区域/机房内的服务实例中轮询

 

 

 

 

 

 

 

 

 

 

 

修改负载均衡策略

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

 

你可能感兴趣的:(ribbon,spring,cloud)