Feign源码解析4：调用过程
背景
前面几篇分析了Feign的初始化过程，历经艰难，可算是把@FeignClient注解的接口对应的代理对象给创建出来了。今天看下在实际Feign调用过程中的一些源码细节。
我们这里Feign接口如下：
@FeignClient(value = "echo-service-provider") // 指向服务提供者应用
public interface EchoService {
@GetMapping("/echo/{message}")
String echo(@PathVariable("message") String message);
}
调用代码：
http://localhost:8080/feign/echo/ddd
@GetMapping("/feign/echo/{message}")
public String feignEcho(@PathVariable String message) {
return echoService.echo(message);
}
完整解析
动态代理
这里的echoService此时的类型其实是jdk动态代理，内部有一个字段，就是实现了jdk的InvocationHandler接口：
实际逻辑如下，会根据被调用的method找到一个合适的handler：
import feign.InvocationHandlerFactory.MethodHandler
static class FeignInvocationHandler implements InvocationHandler{
private final Map<Method, MethodHandler> dispatch;
}
一般获取到的都是如下类型：
这个类有如下核心属性：
都是和http请求息息相关的，如重试、请求拦截器、响应拦截器、logger、logger级别、options（包含了超时时间等参数）。
重试
接下来看实际请求的大体框架：
上面主要是一个while循环，内部会执行请求，如果请求报错，抛出了RetryableException类型的异常，此时就会由重试组件（Retryer retryer），判断是否要重试，如果要的话，就会continue，就会再次执行请求。
但如果重试组件认为不需要重试或重试次数已经超过，就会抛出异常，此时就走不到continue部分了，会直接向上层抛异常。
image-20240111202202423
注意，这个重试接口实现了Cloneable，因为每次请求的时候，都要有一个对应的重试对象来记录当前请求的重试状态（比如重试了几次了），正因为有状态，所以得每次clone一个新的。
Retryer retryer = this.retryer.clone();
默认情况下，不做任何配置，都是不重试的，此时的retryer类型为一个内部类，意思是NEVER_RETRY：
这里再拓展一点，什么情况下，Feign会抛出RetryableException呢？
其实就是在执行上图的正常执行部分，遇到了java.io.IOException的时候，就会抛这种RetryableException。
static FeignException errorExecuting(Request request, IOException cause) {
return new RetryableException(
-1,
format("%s executing %s %s", cause.getMessage(), request.httpMethod(), request.url()),
request.httpMethod(),
cause,
null, request);
}
还有一种情况是啥呢？是服务端返回的http header中包含了Retry-After这个header的时候：
这个header一般是在503的时候返回：
根据模版创建请求
大家看看我们的接口，用了path variable，所以，在真正进行请求前，必须先完成一些准备工作，比如把path variable替换为真实的值：
@GetMapping("/echo/{message}")
String echo(@PathVariable("message") String message);
另外，大家看代码，还有个参数传给下层：
这个就是控制请求超时参数的。这个options从哪里来呢，从我们的传参来。我们可以在方法中加一个参数：
@GetMapping("/echo/{message}")
String echo(@PathVariable("message") String message, Request.Options options);
这个的优先级，我觉得应该是最高的。
这样就能支持，每个接口用不一样的超时时间。
executeAndDecode概览
生成绝对路径请求
先说说1处：
Request targetRequest(RequestTemplate template) {
// 使用请求拦截器
for (RequestInterceptor interceptor : requestInterceptors) {
interceptor.apply(template);
}
return target.apply(template);
}
请求拦截器的类型：
public interface RequestInterceptor {
/**
* Called for every request. Add data using methods on the supplied {@link RequestTemplate}.
*/
void apply(RequestTemplate template);
}
这里是对模版进行修改，我看注释，有如下场景（增加全局的header）：
接下来，再看看模版如何转化为请求：
return target.apply(template);
结果，其实也没干啥，就是模版里只有接口的相对路径，此处要拼接为完整路径：
client.execute接口
实际执行请求，靠client对象，它的默认类型为：
它是自动装配的：
它内部包裹了实际发http请求的库，上面的代码中，默认用的是feign自带的（位于feign-core依赖）：
new Client.Default(null, null)
比如，假设我们想用httpclient （在classpath中包含），就会触发自动装配：
也支持okhttp（feign.okhttp.enabled为true）：
这里看看FeignBlockingLoadBalancerClient的几个构造参数：
public FeignBlockingLoadBalancerClient(Client delegate, LoadBalancerClient loadBalancerClient, LoadBalancerClientFactory loadBalancerClientFactory) {
this.delegate = delegate;
this.loadBalancerClient = loadBalancerClient;
this.loadBalancerClientFactory = loadBalancerClientFactory;
}
第一个是上面提到的http客户端，第二个、第三个呢，其实是负责负载均衡的客户端（不只是要负责客户端负载均衡算法，还要负责从nacos这些地方获取服务对应的实例）
client获取服务实例
这个execute方法实际有两部分，一部分是如下，根据service名称，获取服务实例（包含了真实的ip、端口），再一部分才是对服务实例发起请求。
下面的1处，是获取一些listener，然后通知listener，我们已经开始请求了，这里的listener的类型是：
org.springframework.cloud.client.loadbalancer.LoadBalancerLifecycle
包含了好些个生命周期方法，如onStart方法：
void onStart(Request<RC> request);
然后是2处，利用loadBalancerClient，根据服务名，如我们这里的echo-service-provider，获取到一个实例（类型为org.springframework.cloud.client.ServiceInstance）。
3处会判断，如果没获取到实例，此时就会报503了，服务实例不存在。
这里面，获取实例的部分，比较复杂，我们得单独开一篇来讲。
发起真实请求
根据服务实例，组装真实的url进行请求。
这个等负载均衡部分写完了，再讲解这部分，这块的逻辑也还好，无非是对httpclient这些的封装。
总结
我们把整体的feign调用的脉络梳理了一遍，下篇继续loadbalancer的部分，那里也是有点坑的。
用讲师的话来结个尾：啥也不是，散会！