ribbon Spring Cloud Netflix Ribbon介绍

在上一篇文章中，我们介绍了如何使用功能区的轮询机制为消费者配置负载平衡策略。这一次，我们将进一步了解功能区的一些细节以及如何自定义负载平衡策略。

谈谈Ribbon上负载均衡的总体思路。它用@ LoadBalanced修改RestTemplate，并将其提交到功能区进行配置。它为RestTemplate定义了一个拦截器，拦截rest请求，并将其提交给Ribbon进行处理，然后将其发送出去。Ribbon主要负责选择合适的实例和构造URL。(不想详细分析。如果你有兴趣，可以看看LoadBalancerAutoConfiguration，LoadBalancerClient和LoadBalancerClient。).

让我们来看看以下我们可能使用的重要接口。

load平衡器:Ribbon的负载平衡器接口，定义了添加服务实例、选择服务实例、标记服务实例离线、获取当前可用实例和获取所有服务实例的方法。通过方法定义可以看出，这个类是Ribbon最重要的管理类。它管理所有实例，并通过在实例方法中获取负载平衡策略来选择要返回的适当实例。主要涉及到AbstractLoadBalancer平衡器的实现接口，定义了一些基本方法。

1.baseload平衡器:继承了负载平衡器的基本实现类AbstractLoad平衡器，有几点需要注意:IP(检测实例状态的方法)对象没有实现，是空，需要在构造时传入。检查实例状态的默认策略是串行策略，它使用传入规则和轮询实例来检查它们的状态，这在网络中是不好的。检查策略也可以自定义传入。定义了IRule对象，主要用于定义负载均衡策略。iLoad平衡器将通过构造函数将自身传递到IRule中，IRule将通过select函数获取服务器列表，并返回规则下的服务器。均衡器的默认规则是RoundRobinRule，其策略是线性轮询服务实例返回。

2.这个类继承了抽象负载平衡器。从名字可以看出来，反正也没啥用。。。

3.动态服务器列表负载均衡器继承了BaseLoadBalancer，实现了在运行过程中动态更新服务列表的能力，并具有过滤服务列表的功能。你可以自己看，我也没仔细看。

4.继承了DynamicServerlistloadBalancer的ZoneWareloadBalancer是功能最完善、最强大的。由于DynamicServerlistloadBalancer平衡器使用轮询方法调用实例，在不同的区域，网络延迟可能会影响性能，因此出现了Zonewareload平衡器，它具有区域亲和力，会优先考虑同一区域的实例。它使用区域回避规则作为负载平衡策略。

规则:负载平衡策略接口

1.抽象负载平衡规则，实现一些基本方法。iLoad平衡器对象已定义。

2.随机规则:随机选择策略。

3.圆形轮询规则:线性轮询策略

4.RetryRule:内部定义了另一种轮换策略，它具有判断一个实例是否存活的能力，如果不存活，轮询选择其他实例，判断实例的状态。它还设置了一个超时函数，如果在指定的时间内无法选择可用的实例，则返回null。

5.加权响应时间规则:RoundRobinRule的扩展，它定义了一个计算实例权重的算法。权重与实例的响应时间有关。反正最后的效果就是响应时间短的实例更容易被选中。

6.clientconfigenabledroundorbinrule:实现与roundRobinrule一致，后者用于其他类通过继承来扩展。

7.BestAvailableRule从ClientConfigenableDroundroBinrule继承，后者通过遍历所有实例来筛选故障实例，并找到需要返回的并发请求最少的实例。谁最闲找谁做事。

8.PredicateBasedRule:这个规则首先实现过滤(一种判断实例是否有故障且没有空忙的算法)，然后遍历寻找一个实例。这个我不太清楚。

9.AvailabilityFilteringRule:Inherit PredicateBasedRule，直接遍历实例，根据规则找到合适的实例后返回。

10.区域回避规则:继承了表语基本规则，具有区域亲和策略。首先，通过区域过滤掉同一区域中的实例，然后选择一个实例。如果同一区域中没有实例，则线性遍历其他实例。

检测实例是否可用的接口

1.抽象负载平衡器:实现IPing，定义抽象负载平衡器。

2.no apping:ipping被实现并返回true，表示默认情况下所有实例都可用。

3.DummyPing:默认情况下返回true，构造一个initwithinWSConfig空方法，应该用来给开发人员提供自己继承的类。

4.NiwsDiscoverging:与尤里卡结合使用时，以注册中心管理的实例状态为准，处于UP状态的实例返回为可用。

5.PingConstant:实现IPing，可以通过设置setConstant来设置当前或所有实例的状态。

6.pingur:实现IP，通过发送http请求判断实例返回值的状态码是否为200，判断实例是否存活。默认地址为http或https://ip: port，可以通过setPingAppendString将ip后的字符串联起来形成。

以上三个接口是Ribbon上最重要的接口，其他接口这里不介绍。

先说一下Ribbon使用的默认接口。注意，与尤里卡整合后，界面发生了变化。

1.iLoad平衡器，所用的区域负载平衡器

2.I规则，已使用区域回避规则

3.IPing，使用NoOpPing，可以默认完成

4.服务器列表服务器，由ConfigurationBasedServerList决定。配置模式为:servername . ribbon . list of server = localhost:8001，localhost: 8002，localhost: 8003

5.服务器列表过滤服务器，默认使用ZonePreferenceServerListFilter，优先过滤同一区域的实例。

6.功能区的客户端配置IClientConfig默认使用默认客户端配置

与尤里卡集成后，界面实例的使用有以下变化:

1.服务器列表服务器，由DiscoveryEnabledNIWSServerList替换。这个类实现了尤里卡注册中心对服务实例列表的管理。指示Ribbon直接从尤里卡注册中心获取服务列表。

2.IPing被。NIWSDiscoveryPing，这意味着实例的状态由尤里卡注册表维护，如果注册表列表中的实例处于UP状态，它将返回可用。

以上介绍完毕，我们来看看如何定制这些策略的实现类。如果想实现这些接口，可以自己做。

通过查看功能区源代码，我们可以找到以下类，其构造函数定义了这些配置的字段。

publicPropertiesFactory(){

class to property . put(iLoad平衡器. class，NFLoadBalancerClassName)；

class topproperty . put(ipping . class，nfloadbalancerspingClassName)；

class topproperty . put(irule . class，nfloadbalancercruleclassname)；

class topproperty . put(serverlist . class，niwsserverlist class name)；

class topproperty . put(serveristfilter . class，niwsserveristfilterclassname)；

}

我们可以看到它支持五个接口的实现类配置。例如，通过servername . ribbon . nfloadbalancercruleclassname = com . Netflix . load balancer . random rule，配置servername的负载平衡策略以随机选择一个实例。没有服务名的配置意味着全局效应。好了，结束了，亲测有效。您可以尝试自定义自己的负载平衡配置！