1. Ribbon 负载均衡流程
图中的地址不是真实可用的地址，这样的请求实际上是无法直接到达user-service的；
Ribbon 将这个请求拦下并做一些处理：
Ribbon 在拦截下请求之后，需要寻找真实的地址；它首先要知道这个请求指定的是哪个服务，然后去找 Eureka-server 拉取 userservice，然后 Eureka-server 返回服务列表
配置类：
@Configuration
public class Config {
@Bean
@LoadBalanced
public RestTemplate restTemplate() {
return new RestTemplate();
}
}
// @LoadBalanced 注解就是一个标记，标记将来 RestTemplate 发起的请求要被Ribbon去拦截和处理
2. 总结Ribbon的工作流程
当请求进入 Ribbon 之后，Ribbon会怎么去处理呢？
首先，请求会被一个拦截器拦住， 这个拦截器的名字叫做 LoadBalancerInterceptor 负载均衡拦截器
它拦截下来以后会得到请求中的服务名称，然后把它交给 RibbonLoadBanlancerClient
而 RibbonLoadBanlancerClient 又会将服务交给 DynamicServerListLoadBalancer（动态服务列表负载均衡器）ServerList也就是服务列表
然后 DynamicServerListLoadBalancer 又会去 Eureka-server 拉取服务列表
拉取服务之后进行负载均衡
之后 DynamicServerListLoadBalancer 会去找 IRule（规则接口）；
RandomRule–随机
RoundRobinRule–轮询
WeightedResponseTimeRule--按照权重来选择服务器，响应时间越长，权重越小
ZoneAvoidanceRule--以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询
而默认的负载规则是：ZoneAvoidanceRule
而 IRule 会基于规则选择某个服务，并将选中的服务返回给 RibbonLoadBanlancerClient
RibbonLoadBanlancerClient 用得到的真实的 IP 和端口替换服务名称，得到真实的请求地址去完成请求
3. 负载均衡策略
IRule 规则接口决定了负载均衡的策略
Ribbon 负载均衡规则是一个叫做 IRule 的接口来定义的，每一个子接口都是一种规则：
默认的实现是 ZoneAvoidanceRule
通过定义IRule 实现可以修改负载均衡规则，有两种方式：
3.1. 修改负载均衡的规则---代码方式（全局配置）
Bean的类型是IRule，但是实现的时候可以是IRule的任何一种实现
这里RandomRule是随机规则；这样配置以后就会让负载均衡规则从轮询变成随机
@Configuration
public class Config {
@Bean
@LoadBalanced
public RestTemplate restTemplate() {
return new RestTemplate();
}
@Bean
public IRule randomRule() {
return new RandomRule();
}
}
3.2. 修改负载均衡的规则---配置文件方式（某个服务）
在 order-service 的 application.yml 文件中，添加新的配置也可以修改规则：
userservice:
ribbon:
NFLoadBalancerRuleClassName: ***.***flix.loadbalancer.RandomRule # 负载均衡规则
这种方式会先指定服务名称再去指定负载均衡的规则；
因此，这种方案是针对于某一个微服务而言
