企业🤖AI智能体构建引擎,智能编排和调试,一键部署,支持知识库和私有化部署方案 广告
## 名词解释 * Server:在本文中,Ribbon Server指的是“服务提供者”所代表的微服务。 ## 一、ILoadBalancer接口 在上一节我们为大家介绍了Ribbon的负载均衡实现的HTTP请求流程,其中有一个非常关键的接口就是ILoadBalancer 。本节就来重点的介绍一下该接口的实现逻辑:即如何实现负载均衡策略。 ~~~ public interface ILoadBalancer { void addServers(List<Server> var1); Server chooseServer(Object var1); void markServerDown(Server var1); /** @deprecated */ @Deprecated List<Server> getServerList(boolean var1); List<Server> getReachableServers(); List<Server> getAllServers(); } ~~~ * chooseServer()方法是根据key去获取Server;该方法是ILoadBalancer接口中最重要的一个方法,决定了如何使用“负载均衡算法”选择合适的微服务实例Server,进行远程服务调用。 * addServers()方法是添加一个Server集合; * markServerDown()方法用来标记某个服务下线; * getReachableServers()获取可用的Server集合; * getAllServers()获取所有的Server集合。 下图是ILoadBalancer接口的实现类图。 ![](https://img.kancloud.cn/f8/c0/f8c09407232560a3bdafd457b059d2c1_1172x465.png) 在上一节中,我们介绍了RibbonLoadBalancerClient,其中调用了ILoadBalancer 接口的chooseServer方法。 ![](https://img.kancloud.cn/ea/6d/ea6d55542048c0101fccdb4315673eca_1408x229.png) 在BaseLoadBalancer(ILoadBalancer接口实现类)中可以找到如下的chooseServer()的方法实现。 ![](https://img.kancloud.cn/d8/03/d803165ee2bd76943469c9b26745db08_1573x586.png) 从上图中可以看出,chooseServer()选择微服务实例Server的过程是在rule.choose方法中实现的。这里的rule是一个IRule接口的实现类对象。IRule接口就是Ribbon负载均衡中,提供负载均衡策略抽象方法的接口。其默认的负载均衡策略就是:轮询。轮询用白话讲就是,服务提供者轮着被调用,平均分、你一次、我一次。 ![](https://img.kancloud.cn/08/a7/08a7136711f3b12330235e7dd3e09fdb_1042x135.png) ## 二、IRule接口 IRule接口是负载均衡的策略接口,它有三个方法: * choose()是根据key 来获取微服务server * setLoadBalancer()和getLoadBalancer()是用来设置和获取ILoadBalancer的 ~~~ public interface IRule { Server choose(Object var1); void setLoadBalancer(ILoadBalancer var1); ILoadBalancer getLoadBalancer(); } ~~~ 下图是IRule接口的所有实现类,即:Ribbon默认提供的负载均衡策略。 ![](https://img.kancloud.cn/1f/f6/1ff6619efc4cb2d97a53c54c3d519fce_463x291.png) #### 1)RoundRobinRule(默认) 轮询选择,轮询Server服务数组中index,选择 index 对应位置的 Server。即:取数组下标,每次加1,保证数组中的备选Server依次被调用。 #### 2)RandomRule 从多个备选Server(服务提供者),随机选择一个 Server。 #### 3)RetryRule 对选定的负载均衡策略机加上重试机制,也就是说当选定了某个策略进行请求负载时在一个配置时间段内若选择 Server 不成功,则一直尝试使用 subRule 的方式选择一个可用的 Server。 #### 4)WeightedResponseTimeRule 对RoundRobinRule扩展,根据响应时间分配一个 Weight(权重),响应时间越长,Weight 越小,被选中的可能性越低。 #### 5)ResponseTimeWeightedRule 作用同 WeightedResponseTimeRule,ResponseTime-Weighted Rule 后来改名为 WeightedResponseTimeRule。 #### 6)BestAvailablRule 先过滤掉因为多次访问故障,而被标记为Error的Server。然后选择一个并发量(ActiveRequestCount)最小的Server。俗话说就是:先去掉不能干活的,然后在能干活的里面找一个最闲的。 #### 7)AvailabilityFilteringRule 过滤掉那些一直连接失败的且被标记为 circuit tripped 的后端 Server,并过滤掉那些高并发的后端 Server 或者**使用一个 AvailabilityPredicate 来包含过滤 Server 的逻辑**。其实就是检查 Status 里记录的各个 Server 的运行状态 。 #### 8)ZoneAvoidanceRule **使用 ZoneAvoidancePredicate 和 AvailabilityPredicate 来判断是否选择某个 Server**,前一个判断判定一个 Zone 的运行性能是否可用,剔除不可用的 Zone(的所有 Server),AvailabilityPredicate 用于过滤掉连接数过多的 Server。 * * * 后两种方式,需要结合断路、超时等参数配置。使用起来比较复杂,容易进坑。从笔者观察的角度使用者也比较少(几乎没见过),基础的Rule(轮询、权重、BestAvailabl)策略,使用简单,运行也比较高效。 如果真的没有合适的负载均衡策略,我们还可以根据自己的算法进行自定义。后面章节就会为大家介绍到。 ## 三、负载均衡策略配置 Ribbon默认的负载均衡策略是:轮询,如果我们想调整一下负载均衡策略,可以通过如下的配置。在“服务消费者”的服务中,做ribbon负载均衡策略的调整。 网上有很多版本的配置方式(基于注解的、基于配置文件的),目前最简单的方式就是: ~~~ aservice-rbac: ribbon: NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule ~~~ 针对aservice-rbac对外调用服务提供者的服务,使用RandomRule策略。