首先，我们还是先从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配置了随机策略）：
-
microservice-provider-user:ribbon:NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
-
我们需要把上节课配置Ribbon的那些代码都去掉，避免影响我们的配置文件自定义Ribbon Client的效果。为了方便看效果，我们在MovieController的findById方法中添加了两行代码：
-
ServiceInstance serviceInstance = this.loadBalancerClient.choose("microservice-provider-user");
-
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这个服务是轮询的。
