背景
经过前面几篇的理解,我们大致梳理清楚了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 request);
void onStartRequest(Request request, Response lbResponse);
void onComplete(CompletionContext completionContext);
这几个方法分别就是在loadbalancer的不同阶段进行调用。
比如,我举个例子,我之前发现feign的日志里没打印最终调用的实例的ip、端口,导致查日志不方便,所以我就定义了一个自定义的LoadBalancerLifecycle类,将最终选择的实例的ip端口打印出来。
我们看下,这里是如何获取LoadBalancerLifecycle对象的?
loadBalancerClientFactory.getInstances(serviceId, LoadBalancerLifecycle.class)
工厂用途
loadBalancerClientFactory这个字段,类型为LoadBalancerClientFactory,其定义:
public class LoadBalancerClientFactory extends NamedContextFactory
再看其注释:
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
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 = defaultC服务器托管网onfigType;
this.propertySourceName = propertySourceName;
this.propertyName = propertyName;
}
完成构造后,我们发现,还调用了:
clientFactory.setConfigurations(this.configurations.getIfAvailable(Collections::emptyList));
这里的configurations类型是:
private final ObjectProvider> 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
implements ReactiveLoadBalancer.Factory
这个接口就有如下方法,这是个泛型方法:
Allows accessing beans registered within client-specific LoadBalancer contexts.
Map getInstances(String name, Class 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:
loadBalancerClientC服务器托管网onfiguration
这边注意,也是在没注册这个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参数中的超时时间。
后面的响应处理就略过不讲了。
总结
我们总算是把大体流程都讲完了,下一篇讲讲我遇到的问题。
服务器托管,北京服务器托管,服务器租用 http://www.fwqtg.net
机房租用,北京机房租用,IDC机房托管, http://www.fwqtg.net
相关推荐: 华为云编译构建CodeArts Build新手操作指南
华为云编译构建(CodeArts Build)基于云端大规模并发加速,为客户提供高速、低成本、配置简单的混合语言构建能力,帮助客户缩短构建时间,提升构建效率。 本文将给各位开发者带来华为云CodeArts Pipeline的手把手初级教学,让没有接触过的开发者…