SpringCloud全面解析@FeignClient标识接口的过程

Feign的作用

是将Http请求抽象化为一个Interface客户端，可以调用接口的形式来执行Http请求，以达到简化Http调用的目的。

Feign将分散在@FeignClient，@EnableFeignClients，标识接口，接口方法，Spring环境上的各种配置信息提取出来封装成一个对象，然后将对象里的信息注入到RestTemplate中，生成一次Http请求，然后执行。

正常在SpringMVC的Controller

是将Http请求的信息提取出来注入@RequestMapping标识的方法中；而Feign是将接口中的信息提取出来，封装成一个Http请求的相关信息，是对SpringMVC解析过程的一个逆向处理。

当我们通过IOC注入接口对象时，得到的肯定是此接口的实现类对象，这个对象应该就是SpringCloud通过动态代理生成的对象。对于接口对象生成动态代理对象，一般选用JDK的Proxy，这样实现简单且耦合性低，SpringCloud就是如此。

SpringCloud将@FeignClient标识的接口

注册成一个 FeignClientFactoryBean 类型的Bean对象，我们通过IOC注入的是此Bean的 getObject( ) 得到的对象，这篇文章主要就是讲解此方法的执行过程。

当然直接贴源码那太无脑了，我主要是会将解析的过程总结成一个个点

让大家明白在使用过程中需要注意以及可以灵活拓展的地方

在解析接口前，先加载SpringCloud的Feign配置，默认情况先加载 @FeignClient，@EnableFeignClients注解上的配置，其次加载 Spring环境里 feign.client.default 指定的配置，最后加载 feign.client.appName(应用名称) 指定的配置后续的配置信息会覆盖之前的，也就是越靠后的优先级越高。可以通过 “feign.client.defaultToProperties” 属性来改变这种优先级顺序
验证：接口方法参数长度不能为0
验证：标识@FeignClient的接口最多只能继承一个接口
验证：@FeignClient标识的接口的父接口不能再继承自其它接口，也就是@FeignClient的接口最多也只能有一个上级接口
解析接口方法时，忽略这些类型的方法：Object的方法，Static方法，Default方法
将@FeignClient标识接口的最上级 Interface 的@RequestMapping注解的 value（）值设置为 MethodMetadata里的RequestTemplate的 “url” 的第一位；也就是说如果@FeignClient标识接口有Super Interface，那么取Super Interface 的@RequestMapping；如果没有，那么取自己的@RequestMapping；如果都没有此注解，那么忽略
如果 Method 上未标识 @RequestMapping，忽略
Method上的@RequestMapping ，其 method（）和value（）的值都最多只能有一个
将Method上 @RequestMapping 的 value（）追加到 RequestTemplate的 “url” 上，接在接口上的 @RequestMapping 的value（）之后，机制匹配Controller。
解析Method上 @RequestMapping 上的 produces（），验证其值只能有一个元素，将其值添加到Header上的 Accept 中，比如 Accept=application/json
解析 Method上@RequestMapping 上的 consumes（），验证其值只能有一个元素，将其值添加到Header上的 Content-Type中，比如 Content-Type=application/json
解析 Method上@RequestMapping 上的 headers（），headers是一个String[]，其元素是一个个的键值对，value可以使用 "${ }"来获取环境变量的值，比如userName=${spring.application.name}
解析参数上的 @PathVariable 注解，如果此注解上的 value（）= id ，若 “{ id }” 不存在与 url , headers，queries中，那么将 “id” 加入MethodMetadata 的 formParams 属性中，一般不容易出现这种情况
解析参数上的 @RequestHeader 注解，如果此参数类型是Map，设置下MethodMetadata 里的headerMapIndex，也就是参数序号；如果不是，假设value（）= uname，那么将uname 和参数值作为键值对加入到MethodMetadata 的 template（RequestTemplate ）的 headers 属性中
解析参数上的 @RequestParam注解，如果此参数类型是Map，设置下MethodMetadata 里的queryMapIndex，也就是参数序号；如果不是，假设value（）= uname，那么将uname 和参数值作为键值对加入到MethodMetadata 的 template（RequestTemplate ）的 queries属性中
@PathVariable，@RequestHeader， @RequestParam 这三个注解起作用的前提是SpringMVC里有他们的转换器，能够将他们转换为String。也就是说比如参数类型是Date，需要自定义一个Date > String 的转换器，注入到ConversionService里；其他复杂类型也可以自定义相应的转换器。也就是这三个注解不是只能标识基本数据类型，只要定义了相应的转化器，也可以标识复杂类型。
一个参数可以标识以上3种注解，不同的注解执行时起不同的作用。不同的注解可能value（）不同，也就是一个参数可能被放进多个地方，比如 ( @PathVariable(“name”) @RequestHeader(“id”) @RequestParam (“flag”) String userName ) 。每一个注解都会将此参数顺序和value（）存入 MethodMetadata 的 indexToName，以备后续执行时解析。
只要参数标识上述3个注解中的一个，那么将参数序号和转换器放入 MethodMetadata 的 indexToExpander 中；多种注解共用一个转换器，类型是 ConvertingExpander，也就是要将参数转化为Http请求中的数据。
如果参数上未标识上述3种注解，那么此参数作为 RequestBody 的内容。一个方法中只能有一个未标识注解的参数，将参数的序号和实际类型放入 MethodMetadata 的 bodyIndex 和 bodyType 中。
将MethodMetadata(接口Class和方法上的数据)，@FeignClient注解里的数据，Spring环境里配置的数据都放进 SynchronousMethodHandler 类型的对象中，此对象将配合JDK的AOP动态代理，代理对象执行相应方法时将其转发给SynchronousMethodHandler 执行，每一个Method对应一个SynchronousMethodHandler
为@FeignClient标识的接口创建JDK动态代理对象，InvocationHandler类型为：FeignInvocationHandler，持有Map< Method, MethodHandler > 类型的属性，在调用相应方法时转发给指定的 MethodHandler 处理。

以上就是解析@FeignClient接口的，生成相应接口的动态代理对象的过程。

最终所有信息都汇总到SynchronousMethodHandler对象里，在实际执行Http请求时，根据接口上的参数数据和MethodHandler信息生成feign.Request对象，此对象里装着当前Http请求的所有信息，然后Feign将这些信息拷贝到RestTemplate中，就能执行相应的Http请求。

希望能给大家一个参考，也希望大家多多支持服务器之家。

原文链接：https://jiangjibo.blog.csdn.net/article/details/81064820