前言
Ribbon是Netflix发布的负载均衡器，在SpringCloud体系中占据重要的地位，可以单独引入使用，也可以配合其他组件使用，比如在Feign中就默认集成了Ribbon组件。所以在decision中，对Ribbon的拦截和增强是其实现动态路由的核心操作，所以咱们今天从Ribbon的源码出发，一起来解密decision对Ribbon做了什么处理，来达到动态路由的效果。
Ribbon负载均衡策略
因为Ribbon最终是通过RestTemplate对服务提供者发送请求的，所以在使用Ribbon时需要结合RestTemplate使用，通常的使用方式如下所示：
@Bean
// Ribbon负载均衡
@LoadBalanced
public RestTemplate getRestTemplate() {
return new RestTemplate();
}
在这里大家会有个疑问，为啥给RestTemplate添加一个@LoadBalanced的注解就能够实现负载均衡呢？接下来我们就来好好分析一下这个注解背后的操作
通过查看这个对这个注解的描述可以知道，这个注解是能够让一个RestTemplate对象被LoadBalancerClient（它的实现类是RibbonLoadBalancerClient）所使用，LoadBalancerClient类是啥呢？这里先放着，按照springboot的套路，我们先分析一下Ribbon的自动装配的过程：
-
通过spring.factories文件，找到自动配置类RibbonAutoConfiguration
根据RibbonAutoConfiguration配置类中的装配顺序依次进行分析-
分析LoadBalancerAutoConfiguration类
在这里插入图片描述
经过上述的几个步骤，得知添加了注解的RestTemplate对象会被添加⼀个拦截器
LoadBalancerInterceptor，所以接下来我们重点分析一下拦截器LoadBalancerInterceptor； -
拦截器LoadBalancerInterceptor
通过分析LoadBalancerInterceptor的intercept方法，得知，最终指向负载均衡的是LoadBalancerClient对象的execute方法，而LoadBalancerClient对象就是上面咱们分析RestTemplate注解里面的注释中的LoadBalancerClient接口类，其实现类是RibbonLoadBalancerClient，分析其execute方法：
最终选择服务的方法是getServer（），分析这个方法，得知最终是调用ILoadBalancer的chooseServer方法，默认实现类为ZoneAwareLoadBalancer
ZoneAwareLoadBalancer的chooseServer方法最终调用的是其父类BaseLoadBalancer的chooseServer
最终由执行IRule的choose方法进行选择，IRule接口的实现类就是Ribbon对应的几种负载均衡方式
通过分析所有的负载均衡策略类，最终都会去调用ILoadBalancer的getAllservers进行过滤，这就是我们的突破口，在这些策略类执行之前，我们先把getAllservers的结果按照header中的参数进行过滤，将过滤后的结果在交由策略类执行，即可达到我们想要的路由结果。
-
decison-ribbon-plugin拦截并过滤getAllservers的结果列表
由上述可知最终会调用ILoadBalancer接口类的getAllServers方法进行获取，ILoadBalancer的实现类有两个，其中NoOpLoadBalancer返回是空列表，所以我们关注另一个实现类BaseLoadBalancer，并在decision中对其进行拦截增强
-
总结
通过上述分析就完成了decision最核心的动态路由的关键插件，是不是很简单呢？但是在这个看似简单的结果中，我也走了一些弯路，最早时候，没有详细的去分析Ribbon的源码，只是一步步的断点跟踪调用栈，最终埋点的位置是在默认负载均衡策略类上，一开始也没发现问题，直到有一天，有业务组同学反馈说他的服务一直没有按照header的配置进行路由选择，于是我就开始各种排查，最终发现是它的服务配置了其他的负载均衡策略导致的，所以之后我又重新进行了一遍源码阅读，重新选择埋点拦截位置，最终解决了该问题。
