Spring Cloud Ribbon负载均衡策略详解

客户端负载均衡Spring Cloud Ribbon

 Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，基于Netflix Ribbon实现。

目录

客户端负载均衡

源码分析

负载均衡器

负载均衡策略(本文重点)

配置详解

自动化配置

负载均衡器

 负载均衡器相关内容见上一篇文章

负载均衡策略

AbstractLoadBalancerRule

 负载均衡策略的抽象类，在该抽象类中定义了负载均衡器ILoadBalancer对象，该对象能够在具体实现选择服务策略时，获取到一些负载均衡器中维护的信息作为分配依据，并以此设计一些算法来实现针对特定场景的高效策略。

RandomRule

 该策略实现了从服务实例清单中随机选择一个服务实例的功能。下面先看一下源码:

 分析源码可以看出，IRule接口中Server choose(Object key)函数的实现委托给了该类中的Server choose(ILoadBalancer lb, Object key)函数，该方法增加了一个负载均衡器参数。从具体的实现可以看出，它会使用负载均衡器来获得可用实例列表upList和所有的实例列表allList，并且使用rand.nextInt(serverCount)函数来获取一个随机数，并将该随机数作为upList的索引值来返回具体实例。同时，具体的选择逻辑在一个while (server == null)循环之内，而根据选择逻辑的实现，正常情况下每次都应该选出一个服务实例，如果出现死循环获取不到服务实例时，则很有可能存在并发的Bug。

RoundRobinRule

 该策略实现了按照线性轮询的方式依次选择每个服务实例的功能。下面看一下源码：

 RoundRobinRule具体实现和RandomRule类似，但是循环条件和从可用列表获取实例的逻辑不同。循环条件中增加了一个count计数变量，该变量会在每次循环之后累加，如果循环10次还没获取到Server，就会结束，并打印一个警告信息No available alive servers after 10 tries from load balancer:...。

 线性轮询的实现是通过AtomicInteger nextServerCyclicCounter对象实现，每次进行实例选择时通过调用int incrementAndGetModulo(int modulo)方法来实现。

RetryRule

 该策略实现了一个具备重试机制的实例选择功能。从源码中可以看出，内部定义了一个IRule对象，默认是RoundRobinRule实例，choose方法中则实现了对内部定义的策略进行反复尝试的策略，若期间能够选择到具体的服务实例就返回，若选择不到并且超过设置的尝试结束时间(maxRetryMillis参数定义的值 + choose方法开始执行的时间戳)就返回null。

WeightedResponseTimeRule

 该策略是对RoundRobinRule的扩展，增加了根据实例的运行情况来计算权重，并根据权重来挑选实例，以达到更优的分配效果。它的实现主要有三个核心内容。

定时任务

 WeightedResponseTimeRule策略在初始化的时候会通过serverWeightTimer.schedule(new DynamicServerWeightTask(), 0, serverWeightTaskTimerInterval)启动一个定时任务，用来为每个服务实例计算权重，该任务默认30s执行一次。

权重计算

 在源码中我们可以轻松找到用于存储权重的对象private volatile ListaccumulatedWeights = new ArrayList();该List中每个权重值所处的位置对应了负载均衡器维护的服务实例清单中所有实例在清单中的位置。下面看一下权重计算函数maintainWeights的源码:

 该方法的实现主要分为两个步骤:

根据LoadBalancerStats中记录的每个实例的统计信息，累加所有实例的平均响应时间，得到总平均响应时间totalResponseTime，该值会用于后续的计算。

为负载均衡器中维护的实例清单逐个计算权重(从第一个开始)，计算规则为weightSoFar + totalResponseTime - 实例的平均响应时间，其中weightSoFar初始化为0，并且每计算好一个权重需要累加到weightSoFar上供下一次计算使用。

 通过概算计算出来的权重值只是代表了各实例权重区间的上限。下面图节选自Spring Cloud 微服务实战。

实例选择

 下面看一下Server choose(ILoadBalancer lb, Object key)如何选择Server的

 下面我们看一下源码的主要步骤有：

首先先获取accumulatedWeights中最后一个权重，如果该权重小于0.001或者实例的数量不等于权重列表的数量，就采用父类的线性轮询策略

如果满足条件，就先产生一个[0,最大权重值)区间内的随机数

遍历权重列表，比较权重值与随机数的大小，如果权重值大于等于随机数，就拿当前权重列表的索引值去服务实例列表获取具体的实例。

细心的可能会发现第一个服务实例的权重区间是双闭，最后一个服务实例的权重区间是双开，其他服务实例的区间都是左开右闭。这是因为随机数的最小值可以为0，所以第一个实例下限是闭区间，同时随机数的最大值取不到最大权重值，所以最后一个实例的上限是开区间。

ClientConfigEnabledRoundRobinRule

 该策略比较特殊，一般不直接使用它。因为他本身并没有实现特殊的处理逻辑，在他内部定义了一个RoundRobinRule策略，choose函数的实现其实就是采用了RoundRobinRule的线性轮询机制。

 在实际开发中，我们并不会直接使用该策略，而是基于它做高级策略扩展。

BestAvailableRule

 该策略继承自ClientConfigEnabledRoundRobinRule，在实现中它注入了负载均衡器的统计对象LoadBalancerStats，同时在choose方法中利用LoadBalancerStats保存的实例统计信息来选择满足要求的服务实例。

 当LoadBalancerStats为空时，会使用RoundRobinRule线性轮询策略，当有LoadBalancerStats时，会通过遍历负载均衡器中维护的所有服务实例，会过滤掉故障的实例，并找出并发请求数最小的一个。

 该策略的特性是可以选出最空闲的服务实例。

PredicateBasedRule

 这是一个抽象策略，它继承了ClientConfigEnabledRoundRobinRule，从命名中可以猜出这是一个基于Predicate实现的策略，Predicate是Google Guava Collection工具对集合进行过滤的条件接口。

 在该源码中，它定义了一个抽象函数getPredicate来获取AbstractServerPredicate对象的实现，在choose方法中，通过AbstractServerPredicate的chooseRoundRobinAfterFiltering函数来选择具体的服务实例。从该方法的命名我们可以看出大致的逻辑：首先通过子类中实现的Predicate逻辑来过滤一部分服务实例，然后再以线性轮询的方式从过滤后的实例清单中选出一个。

 在上面choose函数中调用的chooseRoundRobinAfterFiltering方法先通过内部定义的getEligibleServers函数来获取备选的实例清单(实现了过滤)，如果返回的清单为空，则用Optional.absent来表示不存在，反之则以线性轮询的方式从备选清单中获取一个实例。

 下面看一下getEligibleServers方法的源码

 上述源码的大致逻辑是遍历服务清单，使用this.apply方法来判断实例是否需要保留，如果是就添加到结果列表中。

 实际上，AbstractServerPredicate实现了com.google.common.base.Predicate接口，apply方法是接口中的定义，主要用来实现过滤条件的判断逻辑，它输入的参数则是过滤条件需要用到的一些信息(比如源码中的new PredicateKey(loadBalancerKey, server))，传入了关于实例的统计信息和负载均衡器的选择算法传递过来的key。

 AbstractServerPredicate没有apply的实现，所以这里的chooseRoundRobinAfterFiltering方法只是定义了一个模板策略:先过滤清单，再轮询选择。

 对于如何过滤，需要在AbstractServerPredicate的子类中实现apply方法来确定具体的过滤策略。

AvailabilityFilteringRule

&emsps;该类继承自PredicateBasedRule，遵循了先过滤清单，再轮询选择的基本处理逻辑，其中过滤条件使用了AvailabilityPredicate，下面看一下AvailabilityPredicate的源码:

 从上面的源码可以看出，主要过的过滤逻辑都是在boolean shouldSkipServer(ServerStats stats)方法中实现，该方法主要判断服务实例的两项内容:

是否故障，即断路由器是否生效已断开

实例的并发请求数大于阀值，默认值2^32 - 1，该配置可以通过参数\.\.ActiveConnectionsLimit来修改

 上面两项只要满足一项，apply方法就返回false，代表该服务实例可能存在故障或负载过高，都不满足就返回true。

 在AvailabilityFilteringRule进行实例选择时做了小小的优化，它并没有向父类一样先遍历所有的节点进行过滤，然后在过滤后的集合中选择实例。而是先以线性的方式选择一个实例，接着使用过滤条件来判断该实例是否满足要求，若满足就直接使用该实例，若不满足要求就再选择下一个实例，检查是否满足要求，这个过程循环10次如果还没有找到合适的服务实例，就采用父类的实现方案。

 该策略通过线性轮询的方式直接尝试寻找可用且比较空闲的实例来用，优化了每次都要遍历所有实例的开销。

ZoneAvoidanceRule

 该类也是PredicateBasedRule的子类，它的实现是通过组合过滤条件CompositePredicate，以ZoneAvoidancePredicate为主过滤条件，以AvailabilityPredicate为次过滤条件。

 ZoneAvoidanceRule的实现并没有像AvailabilityFilteringRule重写choose函数来优化，所以它遵循了先过滤清单再轮询选择的基本逻辑。

 下面看一下CompositePredicate的源码

 从源码中可以看出，CompositePredicate定义了一个主过滤条件delegate和一组过滤条件列表fallbacks，次过滤条件的过滤顺序是按存储顺序执行的。

 在获取结果的getEligibleServers函数中的主要逻辑是:

使用主过滤条件对所有实例过滤并返回过滤后的实例清单

每次使用次过滤条件过滤前，都要判断两个条件，一个是过滤后的实例总数 >= 最小过滤实例数(minimalFilteredServers,默认值为1)，另一个是过滤后的实例比例 > 最小过滤百分比(minimalFilteredPercentage，默认为0),只要有一个不符合就不再进行过滤，将当前服务实例列表返回

依次使用次过滤条件列表中的过滤条件对主过滤条件的过滤结果进行过滤。

后续

后面会介绍Spring Cloud Ribbon配置方式，请持续关注！！！