Feign源码解析5：loadbalancer

背景

经过前面几篇的理解，我们大致梳理清楚了FeignClient的创建、Feign调用的大体流程，本篇会深入Feign调用中涉及的另一个重要组件：loadbalancer，了解loadbalancer在feign调用中的职责，再追溯其是如何创建的。

在讲之前，我先提个重点，本文章的前期是引用了nacos依赖且开启了如下选项，启用了nacos的Loadbalancer：

spring.cloud.loadbalancer.nacos.enabled=true

nacos的Loadbalancer是支持了基于nacos实例中的元数据进行服务实例筛选，比如权重等元数据。

不开这个选项，则是用默认的Loadbalancer，不知道支不支持基于nacos实例中的元数据进行服务实例筛选（没测试）。

我们这边是打开了这个选项，所以本文就基于打开的情况来讲。

feign调用流程

大体流程

接上一篇文章，feign调用的核心代码如下：

1处主要是封装请求；

2处主要是依靠loadbalancer获取最终要调用的实例。

但是在1和2之间，有一段代码是，获取LoadBalancerLifecycle类型的bean列表，大家看到什么lifecycle之类的名字，大概能知道，这些类是一些listener类，一般包含了几个生命周期相关的方法，比如这里就是：

void onStart(Request<RC> request);

void onStartRequest(Request<RC> request, Response<T> lbResponse);

void onComplete(CompletionContext<RES, T, RC> completionContext);

这几个方法分别就是在loadbalancer的不同阶段进行调用。

比如，我举个例子，我之前发现feign的日志里没打印最终调用的实例的ip、端口，导致查日志不方便，所以我就定义了一个自定义的LoadBalancerLifecycle类，将最终选择的实例的ip端口打印出来。

我们看下，这里是如何获取LoadBalancerLifecycle对象的？

loadBalancerClientFactory.getInstances(serviceId, LoadBalancerLifecycle.class)

工厂用途

loadBalancerClientFactory这个字段，类型为LoadBalancerClientFactory，其定义：

public class LoadBalancerClientFactory extends NamedContextFactory<LoadBalancerClientSpecification>

再看其注释：

A factory that creates client, load balancer and client configuration instances. It creates a Spring ApplicationContext per client name, and extracts the beans that it needs from there.

这里就直说了，这是个工厂，它会给每个client创建一个spring容器。这里的client是啥呢，其实是org.springframework.cloud.client.loadbalancer.LoadBalancerClient类型的对象，它是在spring-cloud-commons中定义的接口：

工厂自身的创建

工厂本身是自动装配的：

看上图，需要一个构造函数参数，这个就是一些配置：

调用的构造函数逻辑如下：

public class LoadBalancerClientFactory extends NamedContextFactory<LoadBalancerClientSpecification>

public static final String NAMESPACE = "loadbalancer";    
public static final String PROPERTY_NAME = NAMESPACE + ".client.name";

public LoadBalancerClientFactory(LoadBalancerClientsProperties properties) {
    super(LoadBalancerClientConfiguration.class, NAMESPACE, PROPERTY_NAME);
    this.properties = properties;
}

这里调用了父类构造函数，把几个值存到父类中：

private final String propertySourceName;
private final String propertyName;
private Class<?> defaultConfigType;

public NamedContextFactory(Class<?> defaultConfigType, String propertySourceName, String propertyName) {
    this.defaultConfigType = defaultConfigType;
    this.propertySourceName = propertySourceName;
    this.propertyName = propertyName;
}

完成构造后，我们发现，还调用了：

clientFactory.setConfigurations(this.configurations.getIfAvailable(Collections::emptyList));

这里的configurations类型是:

private final ObjectProvider<List<LoadBalancerClientSpecification>> configurations;

这个字段本身是通过构造函数方式注入的，来源呢，就是spring 容器。

我们有必要探究下，这个LoadBalancerClientSpecification类型的bean，是怎么进入spring 容器的？

其实，这个类也是代表了一份LoadbalancerClient的配置，之前feignClient也是一样的:

public class LoadBalancerClientSpecification implements NamedContextFactory.Specification {

	private String name;

	private Class<?>[] configuration;
}

这种类型的bean，其实是通过LoadBalancerClient注解和LoadBalancerClients注解进入容器的，当你使用这两个注解时，其实是支持配置一个class：

然后，它们两注解都import了一个LoadBalancerClientConfigurationRegistrar类：

这个会负责将对应的配置class，注册到容器中：

注册时，name会有所区别，如果是LoadBalancerClients注解引入的，会加个default前缀。

在默认情况下（引入了nacos-discovery、spring-cloud-loadbalancer的情况下），就会在代码中如下三处有@LoadBalancerClients注解：

所以，我们工厂创建时debug，可以看到如下场景：

从工厂获取LoadBalancerLifecycle

上面讲完了工厂的创建，这里回到工厂的使用。我们之前看到，会获取LoadBalancerLifecycle这种bean：

loadBalancerClientFactory.getInstances(serviceId, LoadBalancerLifecycle.class),

但奇怪的是，获取bean不应该先用loadBalancerClientFactory创建的给各个loadBalancerClient的spring容器；再从容器获取bean吗？

这里是简化了，直接让工厂负责全部事务，我要bean的时候，只找工厂要，工厂内部自己再去创建spring容器那些。

所以我们看到，工厂是实现了接口：

public class LoadBalancerClientFactory extends NamedContextFactory<LoadBalancerClientSpecification>
		implements ReactiveLoadBalancer.Factory<ServiceInstance>    

这个接口就有如下方法，这是个泛型方法：

Allows accessing beans registered within client-specific LoadBalancer contexts.
    
<X> Map<String, X> getInstances(String name, Class<X> type);

下面就看看方法如何实现的：

这里就是分了两步，先获取容器，再从容器获取bean。

创建容器

这个获取容器是先从缓存map获取，没有则创建。

我们这里自然是没有的，进入createContext：

这里首先是创建了一个spring上下文，里面是有一个bean容器的，容器里要放什么bean呢，首先就是上图中的configurations中那些LoadBalancerClient注解里指定的配置类，再然后，就是LoadBalancerClients注解里指定的那些默认的配置类，我们这里有3处LoadBalancerClients注解，但是只有nacos那一个，指定了配置类：

@LoadBalancerClients(defaultConfiguration = NacosLoadBalancerClientConfiguration.class)
public class LoadBalancerNacosAutoConfiguration {

所以，这里会把NacosLoadBalancerClientConfiguration这个配置类注册到容器。

接下来，是如下这行：

context.register(PropertyPlaceholderAutoConfiguration.class, this.defaultConfigType);

这里的defaultConfigType是啥呢，其实就是创建工厂时，指定的LoadBalancerClientConfiguration：

到这里为止，基本spring容器该手工放入的bean就这些了。但这个容器内到时候只会有这些bean吗，不是的。

因为我们这里放进去的几个bean，内部又定义了更多的bean。

nacosLoadBalancerClientConfiguration
loadBalancerClientConfiguration    

nacosLoadBalancerClientConfiguration

首先是自动装配一个NacosLoadBalancer（在缺少这种ReactorLoadBalancer bean的情况下）

再下来，会自动装配ServiceInstanceListSupplier bean：

loadBalancerClientConfiguration

这边注意，也是在没注册这个bean的时候，自动装配ReactorLoadBalancer，这个其实会和上面的nacos的产生竞争，最终到底是哪个上岗呢，只能看顺序了：

和nacos一样，自动装配ServiceInstanceListSupplier:

竞争关系谁胜出

我们上面提到，nacos的配置类和spring-cloud-loadbalancer的配置类，是全面竞争的，最终的话，是谁胜出呢？

我们看看容器完成bean创建后的情况：

可以发现，是nacos的配置赢了。

具体为什么赢，这个暂时不细说，基本就是bean的order那些事情。反正现在nacos赢了，看起来也没啥问题，我们就继续往后走，目前是完成了bean容器的创建。

获取LoadBalancerLifecycle类型bean

我这个项目，并没定义这种bean，所以实际是取不到的，注意的是，在LoadbalancerClient对应的容器取不到，还是会去父容器取的。

我们在父容器也没定义，所以最终是取不到。

根据服务名获取最终实例

loadBalancerClient

目前准备分析如下代码：

先看下这个字段来自于哪里：

可以看出，来自于spring容器注入。

所以，这里可以看出，loadBalancerClient类型为BlockingLoadBalancerClient。

loadBalancerClient.choose

进入该方法：

最终就是从容器获取，取到的就是nacos自动装配的NacosLoadBalancer：

loadBalancer.choose

nacos这里的实现用的反应式编程，不怎么了解这块，反正最终是调用getInstanceResponse方法，且会把从nacos获取到的服务列表传递进来：

可以看到，这里传入的就是实际的服务实例，还包含了nacos相关的元数据，如cluster、weight、是否临时、是否健康等。

后续的逻辑就根据实例的各种属性进行筛选，如meta.nacos.cluster、ipv4/ipv6、

根据权重进行选择：

根据实例进行feign调用

我们跟进去后，发现主要就是feignClient.execute进行调用，在前后则是调用生命周期的相关方法：

我们看到，这个client就是默认的FeignClient，比较原始，直接就是用原生的HttpURLConnection；我们之前文章提到，也是可以使用httpclient、okhttp那些feign.Client的实现，只要引入对应依赖即可。

另外，这个也是没有连接池的，每次都是打开新连接；这里也用了外部options参数中的超时时间。

后面的响应处理就略过不讲了。

总结

我们总算是把大体流程都讲完了，下一篇讲讲我遇到的问题。