【深入理解SpringCloud微服务】Ribbon源码解析
Ribbon的原理
RestTemplate中的拦截器链
在深入理解Ribbon之前，我们先要研究一下RestTemplate。RestTemplate是Spring提供的一个用于发送http请求的工具类。而在RestTemplate的父类InterceptingHttpAccessor里面有这么个东西：
public abstract class InterceptingHttpAccessor extends HttpAccessor {
private final List<ClientHttpRequestInterceptor> interceptors = new ArrayList<>();
...
}
interceptors是RestTemplate里面的拦截器，拦截器类型是ClientHttpRequestInterceptor。当我们使用RestTemplate时，在RestTemplate真正发出http请求之前，请求会经过interceptors这个拦截器链处理。于是，我们可以通过给RestTemplate添加拦截器，对RestTemplate即将发送的请求做各种拦截处理。
Ribbon的拦截器
比如Ribbon的拦截器做的处理就是url重构，url中的域名部分原先是某微服务的服务名，重构后替换成真正的ip端口。
当然完整的流程应该是先通过负载均衡策略选出一个服务实例，然后再根据该实例的ip和port重构url。
如何将拦截器放入到RestTemplate中
在RestTemplate的父类InterceptingHttpAccessor中有一个getInterceptors() 方法：
public List<ClientHttpRequestInterceptor> getInterceptors() {
return this.interceptors;
}
可以直接获取到它的拦截器链，于是我们可以调用restTemplate.getInterceptors()获取到拦截器链，然后调用list.add(interceptor)把我们的拦截器interceptor添加到RestTemplate的拦截器链中。
经过上面这一套动作，就可以把我们的拦截器添加到RestTemplate，但是这一套需要有一个时机以及地点去触发它。而Ribbon就利用了Spring提供的SmartInitializingSingleton这个扩展点去触发。
public interface SmartInitializingSingleton {
void afterSingletonsInstantiated();
}
Spring会在完成了所有非懒加载单例bean的初始化之后调用注册到Spring容器中的所有SmartInitializingSingleton的afterSingletonsInstantiated()方法。于是Ribbon实现了一个SmartInitializingSingleton并注册到Spring中，在afterSingletonsInstantiated()方法中把Ribbon自己的拦截器设置到RestTemplate中。
Ribbon中的核心类
Ribbon中的核心类一共就以下那么几个：
LoadBalancerAutoConfiguration
LoadBalancerAutoConfiguration是Ribbon的自动配置类，会被SpringBoot的自动装配机制加载。LoadBalancerAutoConfiguration利用Spring的扩展点SmartInitializingSingleton设置Ribbon自己的拦截器LoadBalancerInterceptor到RestTemplate的拦截器链中。
LoadBalancerInterceptor
LoadBalancerInterceptor是Ribbon的拦截器，会被添加到RestTemplate的拦截器链中。当调用RestTemplate发起http请求时，请求会经过该拦截器进行负载均衡以及url重写的处理。
LoadBalancerClient
LoadBalancerClient是Ribbon的负载均衡客户端，会被LoadBalancerInterceptor调用，负载均衡以及url重写的工作其实是由LoadBalancerClient完成的。
当LoadBalancerInterceptor拿到原始url时，会从url中取出服务名serviceName（也就是域名部分），然后把serviceName传给LoadBalancerClient。LoadBalancerClient根据serviceName取得对应的ILoadBalancer，调用ILoadBalancer进行负载均衡处理，ILoadBalancer返回负载均衡选出的一个服务实例并返回。LoadBalancerClient拿到返回的服务实例，会把url中的域名（也就是服务名serviceName）改写为该实例的ip和port。
ILoadBalancer
ILoadBalancer是Ribbon的负载均衡器，ILoadBalancer是与服务名一一对应的，也就是每一个服务名对应一个ILoadBalancer，不同服务间的ILoadBalancer互不相干。LoadBalancerClient会通过服务名作为key从loadBalancerMap中获取对应的ILoadBalancer负载均衡器，通过ILoadBalancer的负载均衡选出一个服务实例。
在ILoadBalancer的实现类BaseLoadBalancer有四个比较重要的字段：
- List<Server> allServerList：所有的服务实例
- List<Server> upServerList：在线的服务实例
- IRule rule：负载均衡策略
- IPing ping：用于ping一个服务实例以检查是否存活的工具
ILoadBalancer使用IRule负载均衡策略从upServerList选出一个服务实例Server。然后ILoadBalancer内部有个定时任务通过IPing去ping在allServerList中的每个服务实例，得出所有在线的Server，然后更新upServerList。
然后在BaseLoadBalancer的子类DynamicServerListLoadBalancer中还有一个重要的字段：
- ServerList<T> serverListImpl：向注册中心拉取服务实例列表的工具
DynamicServerListLoadBalancer有一个定时任务从调用serverListImpl拉取最新的服务实例列表，更新到allServerList中。
于是这ILoadBalancer中的这五者就是以下这样的关系：
ServerList
ServerList是一个用于从注册中心拉取服务实例列表的接口，不同的注册中心客户端会有不同的ServerList实现，比如nacos的NacosServerList就是通过NamingService去拉取。
IRule
IRule是Ribbon的负载均衡规则接口，不同的负载均衡策略有不同的IRule实现。
- RandomRule：随机选择一个Server
- RoundRobinRule：轮询选择
- WeightedResponseTimeRule：根据响应时间加权的轮询策略，响应时间越长，权重越小
- BestAvailableRule：最小并发优先策略，在众多Server中选取并发数最小的
- ZoneAvoidanceRule：默认的负载均衡策略，在有区域的环境下，会复合判断Server所在区域的性能和Server的可用性选择Server，在没有区域的环境下，就是轮询，因此默认的负载均衡策略就是轮询
IPing
Iping接口就是用于判断一个Server是否可用的接口，有一个boolean isAlive(Server server)方法需要实现，判断当前这个server是否可用。
Ribbon核心源码解析
LoadBalancerAutoConfiguration
@Configuration(...)
...
public class LoadBalancerAutoConfiguration {
// 把被@LoadBalanced注解修饰的RestTemplate通过Spring自动注入的方式收集到这里
@LoadBalanced
@Autowired(required = false)
private List<RestTemplate> restTemplates = Collections.emptyList();
...
// 通过Spring提供的SmartInitializingSingleton扩展点，
// 调用RestTemplateCustomizer把LoadBalancerInterceptor放入RestTemplate的拦截器链中
@Bean
public SmartInitializingSingleton loadBalancedRestTemplateInitializerDeprecated(
final ObjectProvider<List<RestTemplateCustomizer>> restTemplateCustomizers) {
return () -> restTemplateCustomizers.ifAvailable(customizers -> {
for (RestTemplate restTemplate : LoadBalancerAutoConfiguration.this.restTemplates) {
for (RestTemplateCustomizer customizer : customizers) {
customizer.customize(restTemplate);
}
}
});
}
...
// Ribbon的负载均衡拦截器，会被放入到RestTemplate的拦截器链中
@Bean
public LoadBalancerInterceptor ribbonInterceptor(
LoadBalancerClient loadBalancerClient,
LoadBalancerRequestFactory requestFactory) {
return new LoadBalancerInterceptor(loadBalancerClient, requestFactory);
}
// Ribbon通过RestTemplateCustomizer
// 把LoadBalancerInterceptor放入到RestTemplate的拦截器链中
@Bean
@ConditionalOnMissingBean
public RestTemplateCustomizer restTemplateCustomizer(
final LoadBalancerInterceptor loadBalancerInterceptor) {
return restTemplate -> {
List<ClientHttpRequestInterceptor> list = new ArrayList<>(
restTemplate.getInterceptors());
list.add(loadBalancerInterceptor);
restTemplate.setInterceptors(list);
};
}
...
}
LoadBalancerAutoConfiguration中配置了许多bean，但是重点就是以上三个。LoadBalancerAutoConfiguration通过Spring的扩展点SmartInitializingSingleton调用RestTemplateCustomizer，通过RestTemplateCustomizer把LoadBalancerInterceptor放入到RestTemplate的拦截器链中。
LoadBalancerInterceptor
RestTemplate的拦截器链中有了LoadBalancerInterceptor之后，当我们使用RestTemplate发起http请求时，就会经过LoadBalancerInterceptor的拦截处理。
public class LoadBalancerInterceptor implements ClientHttpRequestInterceptor {
// 负载均衡客户端
private LoadBalancerClient loadBalancer;
// Request对象工厂
private LoadBalancerRequestFactory requestFactory;
...
// RestTemplate发起http请求，会经过LoadBalancerInterceptor的intercept方法拦截处理
@Override
public ClientHttpResponse intercept(final HttpRequest request, final byte[] body,
final ClientHttpRequestExecution execution) throws IOException {
final URI originalUri = request.getURI();
String serviceName = originalUri.getHost();
// LoadBalancerInterceptor的intercept方法，调用LoadBalancerClient的execute方法。
// 传入了服务名serviceName，requestFactory创建的Request对象
return this.loadBalancer.execute(serviceName,
this.requestFactory.createRequest(request, body, execution));
}
}
RestTemplate发起的http请求会被LoadBalancerInterceptor的intercept方法拦截，LoadBalancerInterceptor的intercept方法从url中取出域名部分作为服务名serviceName，然后调用LoadBalancerClient的execute方法。
RibbonLoadBalancerClient
LoadBalancerClient接口的实现类是RibbonLoadBalancerClient。
public class RibbonLoadBalancerClient implements LoadBalancerClient {
...
public <T> T execute(String serviceId, LoadBalancerRequest<T> request, Object hint)
throws IOException {
// 根据服务名（serviceId就是服务名），取得对应的ILoadBalancer
ILoadBalancer loadBalancer = getLoadBalancer(serviceId);
// getServer方法里面通过ILoadBalancer选出一个服务实例Server
Server server = getServer(loadBalancer, hint);
...
// Server包装为RibbonServer
RibbonServer ribbonServer = new RibbonServer(serviceId, server, ...);
// 调用execute方法（重写url，发起请求）
return execute(serviceId, ribbonServer, request);
}
...
@Override
public <T> T execute(String serviceId, ServiceInstance serviceInstance,
LoadBalancerRequest<T> request) throws IOException {
...
// 调用LoadBalancerRequest的apply方法（重写url，发起请求）
T returnVal = request.apply(serviceInstance);
...
}
...
protected Server getServer(ILoadBalancer loadBalancer, Object hint) {
// 调用ILoadBalancer的chooseServer方法选取一个服务实例
return loadBalancer.chooseServer(hint != null ? hint : "default");
}
...
}
RibbonLoadBalancerClient首先调用getLoadBalancer(serviceId)，根据服务名（serviceId就是服务名），取得对应的ILoadBalancer。然后通过ILoadBalancer的chooseServer方法选取一个服务实例Server。最后选出的服务实例作为参数，调用LoadBalancerRequest的apply方法进行下一步操作（重写url，发起请求）
ILoadBalancer
我们看看ILoadBalancer中的chooseServer方法是如何选出实例的。默认的ILoadBalancer就是ZoneAwareLoadBalancer，由于我们一般不会配置zone（区域），所以最后还是会进入父类BaseLoadBalancer的chooseServer方法。
public Server chooseServer(Object key) {
...
return rule.choose(key);
...
}
就是调用IRule的choose方法，默认就是轮询策略。
request.apply(serviceInstance)
我们再看看上面request.apply(serviceInstance)这行代码里面的逻辑。
这里的request是LoadBalancerRequestFactory的createRequest创建的。
public LoadBalancerRequest<ClientHttpResponse> createRequest(
final HttpRequest request, final byte[] body,
final ClientHttpRequestExecution execution) {
return instance -> {
// 以选出的服务实例对象instance作为参数创建了一个ServiceRequestWrapper对象
HttpRequest serviceRequest = new ServiceRequestWrapper(request, instance,
this.loadBalancer);
...
return execution.execute(serviceRequest, body);
};
}
可以看到LoadBalancerRequestFactory返回的request对象的apply方法里面，以选出的服务实例对象instance作为参数创建了一个ServiceRequestWrapper对象。然后调用execution.execute(serviceRequest, body)方法。
public ClientHttpResponse execute(HttpRequest request, byte[] body) throws IOException {
...
// request.getURI()调用到ServiceRequestWrapper的getURI()方法，里面会重写url，然后返回一个重写了url的URI对象
// 然后这里的requestFactory（ClientHttpRequestFactory类型）拿着重写后的URI对象，创建一个新的ClientHttpRequest对象
ClientHttpRequest delegate = requestFactory.createRequest(request.getURI(), method);
...
// 调用ClientHttpRequest的execute()方法真正发起请求，返回ClientHttpResponse（响应结果）
return delegate.execute();
}
我们看一下ServiceRequestWrapper的getURI()方法。
@Override
public URI getURI() {
// 调用LoadBalancerClient的reconstructURI方法（这里的loadBalancer是LoadBalancerClient类型）
URI uri = this.loadBalancer.reconstructURI(this.instance, getRequest().getURI());
return uri;
}
所以总结起来request.apply(serviceInstance)里面就是调用LoadBalancerClient的reconstructURI方法重写url，然后调用ClientHttpRequestFactory的createRequest方法重新创建一个Request对象，然后调用该Request对象的execute()方法真正发起http请求。
