2.负载均衡策略

一、简介

为什么一开始就需要了解这一块，原因就是这块涉及到的组件的调用关系相对独立，更容易理解，而这块也是ribbon的核心之一。

二、接口

ribbon的负载均衡最终都委托给了一个类来实现，那就是IRule，IRule负责不同的策略算法，接口定义如下：

public interface IRule{
    public Server choose(Object key);
    public void setLoadBalancer(ILoadBalancer lb);
    public ILoadBalancer getLoadBalancer();    
}

通过接口定义可见，IRule需要依赖一个ILoadBalancer，这里我们先暂时抛开不看何谓ILoadBalancer。

只看其核心的方法是Server choose(Object key)，即根据key返回Server对象，而Server包含了关键信息，例如host，port等：

而这里IRule仅仅是个接口，netflix提供了好多实现策略，详细如下：

三、深入

通过上面的结构，可以了解到如此多的实现，这里只拿出一个来看看其实现，别的只做描述。这里拿比较简单的RoundRobinRule来说明：

其逻辑比较简单，与其他交互的组件就是从ILoadBalancer获取server列表，之后获取下一个下标，返回server，循环10次。

另外，它并没有使用到传入的参数key。

四、总结

下面将不同的策略实现做简单的总结：

序号	类型	策略名	描述	实现简单介绍
1	不依赖于server运行状况	RoundRobinRule	字如其名，轮询获取server	内置计数器，计数器递增与server列表长度取模，作为下标来从server列表获取下一个server
2		RandomRule	字如其名，随机获取server	内置jdk的Random，随机一个小于server列表长度的数，作为下标从server列表来获取下一个server
3		RetryRule	在默认500ms内，通过重试获取到可用server	内部采用RoundRobinRule获取server，如果server不可用，则循环重试获取。监控线程会定时中断重试任务。
4		ClientConfigEnabledRoundRobinRule	轮询选择server	内部依赖RoundRobinRule实现轮询
5	依赖于server运行状况	WeightedResponseTimeRule	根据server响应时间来分配权重，响应时间越小，权重越高，选中的几率越大	每30s执行一次权重计算任务。权重计算以响应时间为依据，响应时间来自于LoadBalancerStats，其中存储了每个server的平均响应时间。权重算法类似如下：
6		BestAvailableRule	获取并发请求数最小的非故障server	内部依赖LoadBalancerStats来判断server是否故障（断路器打开）,同样，从LoadBalancerStats获取当前请求数最小的server
7		AvailabilityFilteringRule	随机获取可用的并且并发数小的server	内部委托了AvailabilityPredicate来实现，依赖LoadBalancerStats来判断server是否故障（断路器打开），同样，从LoadBalancerStats获取当前请求数从而过滤掉并发量大的server
8		ZoneAvoidanceRule	排除不可用区域和性能差的区域，并选择可用的并发数小的server。	与AvailabilityFilteringRule类似其内部同样依赖了AvailabilityPredicate来实现server的判断。 对于zone的判断，依赖ZoneAvoidancePredicate来实现。

默认情况下，ribbon使用的策略是ZoneAvoidanceRule，如果服务没有分区部署（默认情况下，我们的zone都是defaultZone），那么其实ZoneAvoidanceRule就会退化为AvailabilityFilteringRule。

关于如何配置不同的策略，请参见：结合ribbon