Spring Cloud Ribbon Client

首先，我们还是先从springcloud官方文档中找下相关说明，如下图所示，可以看到从1.2.0版本（也就是从Spriing Cloud Camden）之后，新增了这个通过配置文件来配置负载均衡的功能。

从上图可以看到负载均衡有很多种，我们还是玩最简单的IRule，我们看下IRule的实现类有哪些，如下图所示，我们使用RandomRule为例来说明。

不多说了，Ribbon作为后端负载均衡器，比Nginx更注重的是承担并发而不是请求分发，可以直接感知后台动态变化来指定分发策略。它一共提供了7种负载均衡策略：

策略名	策略声明	策略描述	实现说明
BestAvailableRule	public class BestAvailableRule extends ClientConfigEnabledRoundRobinRule	选择一个最小的并发请求的server	逐个考察Server，如果Server被tripped了，则忽略，在选择其中ActiveRequestsCount最小的server
AvailabilityFilteringRule	public class AvailabilityFilteringRule extends PredicateBasedRule	过滤掉那些因为一直连接失败的被标记为circuit tripped的后端server，并过滤掉那些高并发的的后端server（active connections 超过配置的阈值）	使用一个AvailabilityPredicate来包含过滤server的逻辑，其实就就是检查status里记录的各个server的运行状态
WeightedResponseTimeRule	public class WeightedResponseTimeRule extends RoundRobinRule	根据响应时间分配一个weight，响应时间越长，weight越小，被选中的可能性越低。	一个后台线程定期的从status里面读取评价响应时间，为每个server计算一个weight。Weight的计算也比较简单responsetime 减去每个server自己平均的responsetime是server的权重。当刚开始运行，没有形成status时，使用roubine策略选择server。
RetryRule	public class RetryRule extends AbstractLoadBalancerRule	对选定的负载均衡策略机上重试机制。	在一个配置时间段内当选择server不成功，则一直尝试使用subRule的方式选择一个可用的server
RoundRobinRule	public class RoundRobinRule extends AbstractLoadBalancerRule	roundRobin方式轮询选择server	轮询index，选择index对应位置的server
RandomRule	public class RandomRule extends AbstractLoadBalancerRule	随机选择一个server	在index上随机，选择index对应位置的server
ZoneAvoidanceRule	public class ZoneAvoidanceRule extends PredicateBasedRule	复合判断server所在区域的性能和server的可用性选择server	使用ZoneAvoidancePredicate和AvailabilityPredicate来判断是否选择某个server，前一个判断判定一个zone的运行性能是否可用，剔除不可用的zone（的所有server），AvailabilityPredicate用于过滤掉连接数过多的Server。

Ribbon 提供了几个负载均衡的组件，其目的就是让请求转给合适的服务器处理，因此，如何选择合适的服务器变成了负载均衡机制的核心，Ribbon 提供了如下负载均衡规则：

• RoundRobinRule：默认规则，通过简单的轮询服务列表来选择服务器
• AvailabilityFilteringRule：可用性筛选规则
  • 忽略无法连接的服务器，默认情况下，如果3次连接失败，该服务将会被置为"短路"的状态，该状态持续30秒；如果再次连接失败，"短路"状态的持续时间将会以几何级数增加，可以通过 niws.loadbalancer.<clientName>.connectionFailureCountThreshold 属性，来配置连接失败的次数；
  • 忽略并发过高的服务器，如果连接到该服务器的并发数过高，也会被这个规则忽略，可以通过修改 <clientName>.ribbon.ActiveConnectionsLimit 属性来设定最高并发数。
• WeightedResponseTimeRule：为每个服务器赋予一个权重值，服务器的响应时间越长，该权重值就越少，这个规则会随机选择服务器，权重值有可能会决定服务器的选择
• ZoneAvoidanceRule：该规则以区域、可用服务器为基础进行服务器选择，使用区域（Zone）对服务器进行分类
• BestAvailableRule：忽略"短路"的服务器，并选择并发数较低的服务器
• RandomRule：随机选择可用服务器
• RetryRule：含有重试的选择逻辑，如果使用 RoundRobinRule 选择的服务器无法连接，那么将会重新选择服务器

我们在movie工程的application.yml文件中添加如下配置（可以看到microservice-provider-user配置了随机策略）：

1. 1. 1. 1. microservice-provider-user:

            　　ribbon:

            　　　　NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

我们需要把上节课配置Ribbon的那些代码都去掉，避免影响我们的配置文件自定义Ribbon Client的效果。为了方便看效果，我们在MovieController的findById方法中添加了两行代码：

1.  
   ServiceInstance serviceInstance = this.loadBalancerClient.choose("microservice-provider-user");
2.  
   System.out.println("=======："+serviceInstance.getHost()+":"+serviceInstance.getPort()+":"+serviceInstance.getServiceId());

       下面我们依次启动Eureaka、端口为7900和7901的microservice-provider-user工程以及movie工程。然后在地址栏输入：http://localhost:8010/movie/1多刷新几次

我们看控制台输出的日志，如下图所示：可以看到7900和7901的访问是随机的。

下面我们修改movie工程的端口为7902，application的name设置为microservice-provider-user2，如下图所示

启动端口号为7902的movie工程，之后再将端口修改为7903，再启动movie工程。启动完后，我们访问地址:http://localhost:8761来看看是否都注册到eureka上了，如下图所示。

下面我们来访问地址http://localhost:8010/test，然后查看控制台日志，如下图所示，可以看到microservice-provider-user这个服务是随机的，microservice-provider-user2这个服务是轮询的。