Ribbon负载均衡策略


配置
对调用的某个服务启用某种负载策略
1）通过配置文件配置

hello:

ribbon:

NFLoadBalancerRuleClassName:com.netflix.loadbalancer.RandomRule
2）通过java注解配置

@Configuration

public class RibbonConfiguration{

@Bean

public IRule ribbonRule(){

//随机负载

return new RandomRule();

}

}
通过注解@RibbonClient为特定的服务配置负载均衡策略

@Configuration

@RibbonClient(name=“hello”, configuration=RibbonConfiguration.class)

public class TestRibbonConfiguration{

}
以上配置都是在服务消费者中配置。

单独使用Ribbon

因为往往Ribbon配合Eureka使用的，往往也有第三方服务没有注册到Eureka Server，但也部署了多个实例，也需要进行负载均衡，这时可以在服务消费者的配置文件中进行如下方式配置，实现负载均衡

hello:

ribbon:

listOfServers:localhost:8010,localhost:8011

ribbon负载均衡策略
Greenwich.SR1版本




类
中文
描述




RandomRule
随机策略
随机选择server


RoundRobinRule
轮询策略
按顺序循环选择server


RetryRule
重试策略
在配置时间内选择server不成功，则一直尝试选择一个可用的server


BestAvailableRule
最低并发策略
逐个考察server,如果server断路打开，则忽略，再选择并发连接最低的server


AvailabilityFilteringRule
可用过滤策略
过滤掉一直连接失败并标记为circuit breaker tripped的server,过滤掉高并发连接的server


WeightedResponseTimeRule
响应时间加权策略
根据server的响应时间分配权重，响应时间越长，权重越低，被选择的概率越低;响应时间越高，权重越高，被 选中的概率越高


ZoneAvoidanceRule
区域权衡策略
综合判断server所在区域的性能和server的可用性轮询选择server


Ribbon默认的负载均衡策略是 ZoneAvoidanceRule,可以在类RibbonClientConfiguration看到

Ribbon负载均衡策略——随机负载均衡策略使用


/**
 * 该类为Ribbon的配置类
 * 注意：该类不能放在主应用程序上下文@ComponentScan所扫描的包中，否则配置将会被所有Ribbon Client共享。*/
@Configuration
public class RibbonConfiguration {
  @Bean
  public IRule ribbonRule() {
    // 负载均衡规则，改为随机
    return new RandomRule();
  }
}

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

下面我们来看看在 Ribbon 中都提供了哪些负载均衡的策略实现。
RandomRule
该策略实现从服务实例名单中随机选择一个服务实例的功能。根据选择逻辑的实现， 正常情况下每次选择都应该选出一个服务实例， 如果出现死循环获取不到服务实例时，则很有可能存在并发的 Bug。

RoundRobinRule
该策略按照线性轮询的方式选择服务实例。该策略实现与 RandomRule 类似，在循环条件中增加了一个 count 计数器，如果一直选择不到服务实例持续10次，则结束尝试。
RetryRule
该策略具备重试机制的实例选择功能。其中实现了对内部定义的策略进行反复尝试的策略， 若期间能够选择到具体的服务实例就返回，若选择不到就根据设置的尝试直到结束时间，结束时间为阈值（maxRetryMillis 参数定义的值 + choose 方法开始执行的时间戳），当超过该阈值后就返回 null。
WeightedResponseTimeRule
对 RoundRobinRule 的扩展，增加根据实例运行情况来计算权重，根据权重选择服务实例，以达到最有分配效果。它的主要实现包含三个内容：


定时任务：通过设定定时任务计算服务实例权重，默认 30 秒执行一次。


权重计算：通过 List 维护负载均衡器维护的服务实例清单中所有实例的权重值。
权重计算规则：weightSoFar + totalResponseTime - 实例的平均响应时间，其中 weightSoFar 初始化为零， 并且每计算好一个权重需要累加到 weightSoFar 上供下一次计算使用。这里计算的权重值只表示每个服务实例的权重区间的上限，并不是实例优先级。
ETC: 假设有4个实例A、 B、 C、 D , 它们的平均响应时间为10、40、 80、100, 所以总响应时间是10 + 40 + 80 + 100 = 230, 每个实例的权重为总响应时间与实例自身的平均响应时间的差的累积所得，所以实例A、B、C、D 的权重分别如下所示。

实例A: 230-10 = 220
实例B: 220 + (230 - 40) = 410
实例C: 410 + (230 - 80) = 560
实例D: 560 + (230 - 100) = 690

因此所得实例区间：

实例 A ：[0, 220]
实例 B ：(220, 410]
实例 C ：(410， 560]
实例 D ：(560， 690)

实际上每个区间宽度是：总的响应时间 - 实例平均响应时间，所以平均响应时间越短，权重区间越大，被选中的几率也越大。


实例选择


ClientConfigEnabledRoundRobinRule
该策略的实现功能与 RoundRobinRule 相同，一般不直接使用它。虽然我们不会直接使用该策略，但是通过继承该策略，默认的 choose 就实现了线性轮询机制，在子类中做一些高级策略时通常有可能会存在一些无法实施的情况，那么就可以用父类的实现作为备选。
BestAvailableRule
该策略继承自 ClientConfigEnabledRoundRobinRule ，在实现中它注入了负载均衡器的统计对象LoadBalancer-Stats，同时在具体的 choose 算法中利用 LoadBalancerStats 保存的实例统计信息来选择满足要求的实例。它通过遍历负载均衡中维护的所有服务实例，会过滤掉故障的实例，并找出并发请求数最小的一个实例，所以此策略是选择最空闲的一个服务实例。此策略实现的核心依据是 LoadBalancerStats ，当 LoadBalancerStats 为空的时候策略无法执行，会采用父类的线性轮询策略。
PredicateBasedRule
先通过子类中实现的 Predicate 逻辑来过滤一部分服务实例， 然后再以线性轮询的方式从过滤后的实例清单中选出一个。
AvailaiblityFilteringRule
该策略继承自上面介绍的抽象策略 PredicateBasedRule ，所以它也继承了 “先过滤清单，再轮询选择”的基本处理逻辑。它主要判断服务实例的两项内容：

是否故障，即断路器是否生效已断开
实例的并发请求数大于阙值，默认值为 2^32 - 1，可通过 application.properties 文件配置。

ZoneAvoidanceRule