需求背景

【SpringCloud實戰(zhàn)】一次開發(fā)中使用Feign添加動態(tài)Header問題思考

最近有個需求鸳惯，是對接某個運動APP的Api開放平臺用戶授權業(yè)務螟炫。文中以兩個API為例：

1、獲取token

場景：用戶在授權?頁?面點擊授權后姜骡，?頁?面會跳轉到合作?方提供的redirect_url宣肚，合作?方通過跳轉傳回的code換取token，完成認證和授權悠栓。

Header附加參數：Authorization:Basic base64(AppKey:AppSecret) `

注意：Basic后?面必須有一個空格霉涨。

2、獲取用戶資料

場景：獲取用戶資料接??于獲取用戶在APP的用戶資料惭适。

Header附加參數：Authorization:Bearer token

注意：Bearer后?面必須有一個空格笙瑟。

分析

從上述API資料里面分析得出要對接這兩個API需要設置不同的Header信息，那么就需要代碼中支持動態(tài)設置header功能癞志。

【SpringCloud實戰(zhàn)】一次開發(fā)中使用Feign添加動態(tài)Header問題思考

API

項目框架

由于項目是使用SpringCloud 集成Feign搭建的基礎框架往枷，并且在項目中已經設計了全局的Header。

通過實現(xiàn)RequestInterceptor接口,完成對所有的Feign請求,設置Header代碼如下：

@Configurationpublic class FeignClientConfig implements RequestInterceptor {    @Value("${token}")    private String token;      @Override          public void apply(RequestTemplate template) {        template.header("token", token);    }    /*打印feign請求日志級別*/      @Bean      public Logger.Level level() {        return Logger.Level.FULL;    }}

原理：@FeignClient 的代理類在執(zhí)行的時候凄杯，會去使用該攔截器错洁，然后注入到 spring 上下文中，這樣就可以在請求的上下文中添加自定義的請求頭戒突。

優(yōu)點：所以自定義自己的攔截器

缺點：操作的是全局的 RequestTemplate屯碴，比較難以根據不同的服務方提供不同的 header。

方案一：使用Feign官方方案

經過分析得出現(xiàn)在的代碼是不支持這次需求膊存，那么項目中既然集成了OpenFeign导而，可以從這里入手看看官方是如何解決的。

OpenFeign源碼地址：https://github.com/OpenFeign/feign

// openfeign 官方文檔代碼示例public interface ContentService {    @RequestLine("GET /api/documents/{contentType}")    @Headers("Accept: {contentType}")    String getDocumentByType(@Param("contentType") String type);}

通過上面的官方文檔代碼示例發(fā)現(xiàn)不需要那么麻煩隔崎，用原生的@Headers 注解就能解決我們的問題了今艺，添加到代碼上。

@Headers 代碼示例

@FeignClient(name = "xxx-feign-service",url = "IP:端口")@Headers({"Authorization: ${token}"})    public interface FeignClient {      @RequestMapping(value = "/getToken")      String getToken();}

使用{token} 可以傳遞動態(tài)header屬性爵卒。

一番折騰后發(fā)現(xiàn)@Headers 沒有生效虚缎，在生成的RequestTemplate中，沒有獲取到token值技潘。 然后調試一下代碼遥巴，發(fā)現(xiàn)千康，ReflectFeign在生成遠程服務的代理類的時候，會通過 Contract 接口準備數據铲掐。 而@Headers 注解沒有生效的原因是：官方的 Contract 沒有生效：

代碼如下：

class FeignClientFactoryBean implements FactoryBean<Object>, InitializingBean, ApplicationContextAware {      protected Feign.Builder feign(FeignContext context) {         Feign.Builder builder = get(context, Feign.Builder.class)                   // required values                    .logger(logger)                     .encoder(get(context, Encoder.class))                   .decoder(get(context, Decoder.class))                   .contract(get(context, Contract.class));                    ...     } }

【SpringCloud實戰(zhàn)】一次開發(fā)中使用Feign添加動態(tài)Header問題思考

去翻一下springcloud-openfeign在創(chuàng)建 Feign 相關類的時候拾弃，使用的是容器中注入的 Contract代碼如下：

@Bean@ConditionalOnMissingBeanpublic Contract feignContract(ConversionService feignConversionService) {      return new SpringMvcContract(this.parameterProcessors, feignConversionService);} public class SpringMvcContract extends Contract.BaseContract implements ResourceLoaderAware {      @Override  public MethodMetadata parseAndValidateMetadata(Class<?> targetType, Method method)   {          ....            // 注意這里，它只取了 RequestMapping 注解          RequestMapping classAnnotation = findMergedAnnotation(targetType, RequestMapping.class);            ....            parseHeaders(md, method, classAnnotation);        }       return md;    }

我們來總結一下：

1摆霉、openfeign本身是支持在方法上使用@Header 注解豪椿，來實現(xiàn)自定義header功能。

2携栋、springcloud-openfeign只是集成了openfeign的核心功能搭盾，@Headers 注解并沒有被使用。

3婉支、SpringCloud 使用了自己的 SpringMvcContract 來處理請求的相關資源信息鸯隅，里面只使用 @RequestMapping 注解。

也就是被閹割了唄~~~~

方案二：使用 @RequestMapping的 headers 屬性

上面提到了第3點可以使用 **@RequestMapping **注解中的headers屬性來解決向挖，來試一下蝌以。

@FeignClient(name = "xxx-feign-service",url = "127.0.0.1:8080")public interface FeignClient {      @RequestMapping(value = "/getToken")      String getToken(@Param("token") String token);}

經測試SpringCloud 支持@RequestMapping 注解的 header，可以正常獲取頭部信息何之。

但是問題來了跟畅，很多同學不習慣在類上直接使用 @RequestMapping 注解，有沒有一個全局管理的地方溶推？也方便代碼維護呢徊件？

方案三：重寫RequestInterceptor的apply方法

【SpringCloud實戰(zhàn)】一次開發(fā)中使用Feign添加動態(tài)Header問題思考

上面提到過通過實現(xiàn)RequestInterceptor接口完成對所有的Feign請求，可不可以在FeignClientConfig文件里面統(tǒng)一管理呢蒜危？那就需要我們自定義這個類了虱痕。具體代碼如下：

@Configuration@Datapublic class FeignClientConfig implements RequestInterceptor {    @Value("${appKey}")    private String appkey;    @Value("${appSecret}")    private String appSecret;    private String token;    @Bean    public RequestInterceptor RequestInterceptor() {        return new RequestInterceptor() {        @Override        public void apply(RequestTemplate template) {            String text = appkey+":"+appSecret;            String authorization = "";            if(StringUtils.isBlank(token)){                authorization="Basic "+ StringUtil.encode(text);            }else{                authorization="Bearer "+ token;            }                template.header("Authorization", authorization);            }        };    }    /*打印feign請求日志級別*/       @Bean       public Logger.Level level() {        return Logger.Level.FULL;    }}

注釋：根據文中開始部分提到的業(yè)務中有兩個API，并且他們的請求Header信息不一樣舰褪，通過重寫RequestInterceptor的apply方法來封裝header值皆疹，達到解決動態(tài)參數的問題（有心的同學這里的代碼可以更加優(yōu)雅一點兒）。

總結

通過尋找解決問題的方法發(fā)現(xiàn)SpringMvcContract 是在 parseAndValidatateMetadata 中解決在類上面的 header 的問題占拍，這里也特別提醒一下各位同學Spring Cloud 并沒有基于Spring MVC 全部注解來做Feign 客戶端注解協(xié)議解析略就，這個是一個不小的坑。這也導致了最開始沒寫想到在feign接口上使用 @RequestMapping來解決問題晃酒。

那么使用@RequestMapping 解決header問題是最簡單也更加原生的方案表牢，通過重寫RequestInterceptor的apply方法來實現(xiàn)可以統(tǒng)一管理頭部信息，方便后續(xù)的維護贝次，兩者各有千秋崔兴。