4、深入理解ribbon

一、负载均衡的两种方式

• 服务器端负载均衡

  传统的方式前端发送请求会到我们的的nginx上去，nginx作为反向代理，然后路由给后端的服务器，由于负载均衡算法是nginx提供的，而nginx是部署到服务器端的，所以这种方式又被称为服务器端负载均衡。

  

• 客户端侧负载均衡

现在有三个实例，内容中心可以通过discoveryClient 获取到用户中心的实例信息，如果我们再订单中心写一个负载均衡的规则计算请求那个实例，交给restTemplate进行请求，这样也可以实现负载均衡，这个算法里面，负载均衡是有订单中心提供的，而订单中心相对于用户中心是一个客户端，所以这种方式又称为客户端负负载均衡。

二、手写一个客户端侧负载均衡器

◆随机选择实例

@Autowired
private DiscoveryClient discoveryClient;
@GetMapping("/order/create")
public String createOrder(Integer productId,Integer userId){
    List<ServiceInstance> instances = discoveryClient.getInstances("msb-stock");
    List<String> targetUrls = instances.stream()
        // 数据变换
        .map(instance -> instance.getUri().toString() + "/stock/reduce")
        .collect(Collectors.toList());
    int i = ThreadLocalRandom.current().nextInt(targetUrls.size());
    String targetUrl = targetUrls.get(i);
    log.info("请求求目标地址：{}",targetUrl);
    String result = restTemplate.getForObject(targetUrl +"/"+ productId, String.class);
    log.info("进行减库存:{}",result);
    return "下单成功";
}

三、使用Ribbon实现负载均衡

Ribbon是什么?
Netflix开源的客户端侧负载均衡器

更加直观说就是ribbon就是简化我们这段代码的小组件，不过他比我们的代码要强大一些，他给他们提供了丰富的负载均衡算法。

引入ribbon :三步骤： 加依赖，启动注解，写配置

不需要加，nacosdiscovery，已经给添加了依赖，

写注解，需要写到RestTemplate上面。

第三步：写配置

没有配置。

改造我们的请求：

url:改为 下面 当请求发送的发送的时候ribbon会将nx-us进行转化为我们nacos里面中的地址。并且进行负载均衡算法，进行请求，

四、Ribbon的重要接口 以及内置负载均衡规则

1、Ribbon重要接口

接口	作用	默认值
IClientConfig	读取配置	DefaultclientConfigImpl
IRule	负载均衡规则，选择实例	ZoneAvoidanceRule
IPing	筛选掉ping不通的实例	默认采用DummyPing实现，该检查策略是一个特殊的实现， 实际上它并不会检查实例是否可用，而是始终返回true，默认认为所 有服务实例都是可用的.
ServerList	交给Ribbon的实例列表	Ribbon: ConfigurationBasedServerList Spring Cloud Alibaba: NacosServerList
ServerListFilter	过滤掉不符合条件的实例	ZonePreferenceServerListFilter
ILoadBalancer	Ribbon的入口	ZoneAwareLoadBalancer
ServerListUpdater	更新交给Ribbon的List的策略	PollingServerListUpdater

2、Ribbon负载均衡规则

我们说一下常用的规则

规则名称	特点
RandomRule	随机选择一个Server
NacosRule	同集群优先调用
RetryRule	对选定的负责均衡策略机上充值机制，在一个配置时间段内当选择Server不成功，则一直尝试使用subRule的方式选择一个可用的Server
RoundRobinRule	轮询选择，轮询index，选择index对应位置Server
WeightedResponseTimeRule	根据相应时间加权，相应时间越长，权重越小，被选中的可能性越低
ZoneAvoidanceRule	（默认是这个）该策略能够在多区域环境下选出最佳区域的实例进行访问。在没有Zone的环境下，类似于轮询（RoundRobinRule）

六、细粒度配置自定义

ribbon支持非常灵活的配置，用的最多的就是配置他的负载均衡规则，比如：默认ZoneAvoidanceRule 满足不了我们的要求，我们想把这个规则改为随机，ribbon支持细粒度的配置，加入内容中心同时调用两个微服务，那么调用第一个微服务的时候我们可以用随机方式，第二种我们用默认的配置，好这样我们围着这个场景来看一下怎样配置。

先看Java代码的配置。

1、类配置方式

这里的配置类需要放到springboot扫描路径之外，这个需要注意的点。

public class RibbonConfiguration {
    @Bean
    public IRule ribbonRule(){
        //随机选择
        return new RandomRule();
    }
}

/**
* 指定配置
**/
@Configuration
@RibbonClient(name = "nx-user",configuration = RibbonConfiguration.class)
public class UserRibbonConfiguration {
}

讲解我们这里配置类并没有增加配置类注解

如果放到springboot能扫描的地方就会成为全局配置文件。对所有的调用都会用这个规则。

2、属性配置方式

将前面的配置注释掉：

如下进行配置：

msb-stock:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

3、优先级高低

java配置的要高， 我们可以类配置的路由规则为随机（RandomRule），然后属性配置为轮训（RoundRobinRule）;

测试是随机则java配置高于属性配置

4、全局配置

◆方式一︰让ComponentScan上下文重叠（强烈不建议使用）

◆方式二【唯正确的途径】:
@RibbonClients(defaultConfiguration=xxx.class)

就是将RibbonClient改为RibbonClients 将configuration改为defaultConfiguration

七、支持的配置项

那ribbon那些是支持自定义呢？ 下面都支持自定义。

接口	作用	默认值
IRule	负载均衡规则，选择实例	ZoneAvoidanceRule
IPing	筛选掉ping不通的实例	DumyPing(该类什么不干，认为每个实例都可用，都能ping通)
ServerList	交给Ribbon的实例列表	Ribbon: ConfigurationBasedServerList Spring Cloud Alibaba: NacosServerList
ServerListFilter	过滤掉不符合条件的实例	ZonePreferenceServerListFilter
ILoadBalancer	Ribbon的入口	ZoneAwareLoadBalancer

ServerListUpdaterClassName

• NFLoadBalancerClassName : ILoadBalancer 实现类
• NFLoadBalancerRuleClassName : IRule实现类
• NFLoadBalancerPingClassName : IPing 实现类
• NIWSServerListClassName : ServerList实现类
• NIWSServerListFilterClassName : ServerListFilter实现类

八、饥饿加载

ribbon默认是懒加载的，只有第一层调用的时候才会生成userCenter的ribbonClient，这就会导致首次调用的会很慢的问题。

ribbon:
  eager-load:
    enabled: true
      clients: msb-stock

九、源码分析

1、猜测源码的实现

我们在看源码的时候我们可以根据功能先想一下，他是怎样实现的，如果让我们来实现我们会怎么做，我们想ribbon不过就是替换nx-stock，为ip+端口我们会怎样做，大家想一下 ？ 是不是我们可以增加加一个拦截器， 如下，你这样有这样一个思维再去看源码就应该容易一点：我们RestTemplate有一个扩展点是

ClientHttpRequestInterceptor 我们Ribbon通过LoadBalancerInterceptor实现了这个扩展早点，将nx-stock替换为 192.168.0.3:8003

2、初始化的过程

我们首先进入我们的注解@LoadBalanced，我们学spring源码的时候一般是注解中增加一个@Import,引入一个对象此时他没有，所以我们想它是和springboot整合的，所以我们可以找到同包下的spring.factories中，看一下，自动装配类。

我们先进入spring-cloud-starter-netflix-ribbon.2.2.6

.Release 里面乜有对应spring.factories，他是空的，这和我们讲springboot时候说mybatis一样，starter是空的但是他能引用一些自动配置的jar,我们进去看

导入了RibbonAutoConfiguration

我们可以全文搜索一下哪里加载了LoadBalancerAutoConfiguration，

这样应该和我们的LoadBalanced注解有关

AsyncLoadBalancerAutoConfiguration和LoadBalancerAutoConfiguration应该和我们对应的注解有关系，那么我们想Async是应该和异步有关系应该是更高级的作用，所以我们进入LoadBalancerAutoConfiguration这个类。 我们进入配置类中发现

好这里面就应该是我们找的类，这里应该是获取容器中所有标注@LoadBalanced注解的所有类。

我们进入LoadBalancerAutoConfiguration 里面初始化一些对象，

我们这里初始化一个对象是LoadBalanceInterceptor，这就是一个拦截器，然后后面是一个RestTemplateCustomizer，我们从名字可以看出他就是一个自定义的RestTemplate，我们可以看一下里面内容就有一个customize方法，我们这里用哪个lambda表达式来处理，就是穿进去一个restTemplate然后给里面增加一个拦截器。这个拦截器里面就是上面弄的LoadBalancerInterceptor。

接着还有一个对象就是：SmartInitializingSingleton

这一部分就是给我们的restTemplate增加了拦截器。

接下来我们就可以进入拦截器查看一下，进入拦截器是不是就查看intercept,写过拦截器一个知道他最重要的方法就是intercept

3、负载均衡的过程

request.getURI()， 这个不用我多解释了吧，restTemplate就是发送http请求，这里获取他的请求链接，然后获取他的host，他的host是什么就是nx-stock，就是serviceName，然后将这serviceName传递到我们的execute里面，我们推想这里很可能对我们serviceName进行解析，从我们的nacos注册中心获取注册列表，然后通过负均衡选择一个合适的地址，进行调用。

这里我么可以一个看到第一个应该是获取负载均衡器，第一个是根据负载均衡器来获取对应的一个服务

那我们简单看一下怎样获取负载均衡器：

AnnotationConfigApplicationContext 就是我们注解配置的上下文，我们则是从容器中获取对应的对象，ILoadBalancer对应的负载均衡器。

我们可以看出是从一个Map里获得，如果没有我们需要创建他createContext

获取配置然后注册刷新容器，这里和我们的spring容器一样。

所以我们一定有一个地方是创建这个对象，然后注入容器的，那一定是一个配置类，其实他是在RibbonClientConfiguration这个类中。在这里其实就是我们对应ribbon可配置类的默认配置是在这里配置，看这里每个注入类对应的注解@ConditionalOnMissingBean，从这里我们能知道我们配置了我们自己的类就用我们自己的类，如果没有配置我们自己的类，就会用到默认的配置类。

从这里我们能验证一个事情，@ConditionOnMissingBean中是查看容器中是否有对应的ILoadBalancer如果有则使用，如果没有则调用这个方法，然后我们看一下这个方法propertiesFactory是查看property中是否设置了我们的配置，如果有则获取到，没有则是获取默认的，

所以这里证明一个前面的结论： java配置高于属性配置

好，看到这里就可以，当然我们也可以查看一下这个负载均衡器，但里面对应的内容很复杂，我们知道我们获取一个负载均衡器就可以了，后面可以不看。等我们后面用的时候再看。

好我们回到刚才的位置：

通过这个名称getServer我们就应该知道，这个应该是通过负载均衡器中的算法获取对应一个服务

这里是调用这个负载均衡器的chooseServer，通过名称我们就知道这里是选择一个服务，这里肯定是从nacos中获取对应的服务列表，然后选择一个进行调用。

在这里我们可以看到我们应该调用ZoneAvoidanceRule

进入后我们看到一个关键方法就是role.choose，这里面我们发现他有很多实现，刚才我们说过RibbonClientConfiguration初始化了我们一些默认的对应的类，

我们可以发现这里创建了一个默认的规则ZoneAvoidanceRule，所以就会调用他方法，同时我们也要看一下他的集成关系，因为我们调用的方法可能是他的父类中的方法，

这里没有对应的ZoneAvoidanceRule 但是有PredicateBasedRule，所以会调用这个方法。

首先获取一个负载均衡器，然后这里chooseRoundRobinAfterFiltering 从这个方法我们就知道，这里使用轮训方法，ZoneAvoidanceRule如果没有设置时钟就会才用轮训算法，接着这里通过负载均衡器获取对应所有的server,我们可以推算这里是应该是从nacos中获取对应的服务列表，当然我们先不考虑他是怎样获取的，我们先知道他这里获取对应的服务列表就可以。

下面就轮训机制获取对应有效的服务，首先看一下 nextIndex他是AtomicInteger类型，我们首先获取对应的值，然后加一求余，得到next值，然后

nextIndex.compareAndSet方法，判断是否是current这个值，如果是则返回，并且将next值设置进去，方便下一次的获取，这就是轮训机制，大家能不能明白，

好，那我们看这里用掉了cas方式，这样大大提高了他的性能，如果不用cas的话就需要用到lock，这样性能就会降低，当然如果设置返回false,他还会进入下一次循环处理是吧， 这就是并发编程中的应用，我们可能在工作中做业务用不到，但是你写一些中间件或者上大厂这些就用到的很多了，所以并发编程的基本功一定要搞好。

好，负载均衡我们说完了，我们看一下我们的server是怎么样获取的。

4、获取服务列表

我们要从我们的负载均衡器中看起，因为我们前面就是从负载均衡器中获取对应的server列表

我们可以进入我们的配置类中RibbonClientConfiguration中查看对应的创建。从这里构造方法我们可以看到对应的serverList，所以说他是在创建构造方法的时候就已经获取到对应的服务列表，好我们看他的服务列表是怎么获取的。

好，我们来全文搜索一下 ， 这里是从配置文件中获取对应的配置server,因为我们的ribbon可以独立使用的，所以我们这里获取的serverlist应该是空的。

好，这里我们进入负载均衡器的构造方法里面。

这里面有个restofInit方法，好这里的init方法我们可以进去看看，看到这个init或者start方式都是重要方法，我们可以进去看一下

看这个方法，我们可以翻译一下 这里 了开启并初始化学习新服务的特点， 这是什么意思我们可以看一下

他们最后会调用这个updateListOfServers方法，这个是重点后面我们会看到。

=

获取实例

这里就和nacos中获取数据

5、更新服务列表

进行服务赋值，后面就可以使用了

6、重构请求的URL

此时我们需要debug进入这个容器中：

路跟下来发现在⼀个匿名内部类中，发现了很可疑的地点：ServiceRequestWrapper，服务请求的⼀个

包装类，难不成在这⾥重构请求，有点接近了，进去看下：

debug进入就会发现里面对host的替换