前言

說起SpringChoud的feign大家用過的都說好。Feign是Netflix開發(fā)的聲明式、模板化的HTTP客戶端。對于我們微服務來說，微服務之間的api調用，使用feign來說是再方便不過的。本文先介紹一下，傳統的feign的調用寫法方式，再介紹我們的重點feign的繼承特性。 feign的繼承特性有很多的好處，可以進行參數和方法的統一管理，一次修改，feign和具體的controller都變了。 總之好處還是不少的。

傳統的feign的實現方式

傳統的feign是怎樣的實現的呢，我們先通過springmvc搞了一個controller，在controller里面實現我們代碼。此時另一個微服務想直接調用這個請求，那么被調用的微服務就可以聲明一個feign的客戶端，將自身要提供給外部調用的方法，feign提供的方法的requestMapper路徑映射和controller中的保持一致即可訪問得到。

傳統feign的代碼實現

我們先寫一個傳統的controller。我們的目的很簡單，這個controller來返回123。

@RestControllerpublic class DemoController { @PostMapping("/demo/list") public String demo( @RequestBody DemoFeignQueryVO demoFeignQueryVO){ return "123"; }}

有了controller，我們來寫feign。feign的代碼是十分簡單的，只要保證feignClint的值是我們要調用的微服務的值，然后其中的postMapping的值和上方controller的一樣即可調用到。

@FeignClient(value = "user-system")@Componentpublic interface IDemoFeign { @PostMapping("/demo/list") public String demo( @RequestBody DemoFeignQueryVO demoFeignQueryVO);}

傳統feign的缺點

由上方的代碼來看，有什么缺點呢，比如我要更改controller的參數，那么我需要改兩處地方，一處是自己的controller實現，一處是feign的接口。如果忘改了的話，就會產生未知的錯誤。如果更改了controller的路徑映射呢。同樣的，也需要改兩處位置。這是傳統形式的一種缺點。

feign的繼承特性

如果我們使用feign的繼承特性，就不會有上方的情況產生，繼承特性就是說，我們弄一個共用的接口，在接口上布置我們的requestMapping注解，規(guī)定我們的方法參數。然后通過controller實現這個接口。controller就可以針對接口中的方法進行一一的實現。然后針對于我們的feign接口，我們直接繼承共用的接口。這樣feign接口和controller方法是完全保持一致的，當需要修改的時候，完全不需要兩個地方一起修改，直接更改共用的接口即可。

feign的繼承特性的代碼實現

我們將上述的傳統方案的代碼進行一個改寫，通過對比，就可以看出好處。 先聲明一個共用的接口。這里面寫我們所有要提供給外面的方法。

public interface DemoInterface { @PostMapping("/demo/list") public String demo( @RequestBody DemoFeignQueryVO demoFeignQueryVO); }

有了接口后，我們的controller直接實現這個接口。

@RestControllerpublic class DemoController implements DemoInterface { @Override public String demo( @RequestBody DemoFeignQueryVO demoFeignQueryVO){ return "123"; }}

我們此時就可以看到，controller不用關心路徑映射了。而且針對于參數來說，如果接口一修改，controller必然會提示報錯，編譯不會通過，不會使你漏下改動。 接下來，實現一下我們的feign，feign是極其簡單的，只要繼承共用的接口即可。

@FeignClient(value = "user-system")public interface DemoFeign extends DemoInterface {}

看上面是不是覺得非常方便。feign和controller都不用關心路徑，通過共用端口保證了路徑一定一致，接口的參數檢查也保障了參數不會產生問題。

feign繼承特性帶來的requestMapping加載問題

在我們上述的提供方案中，如果requestMapping只是在注解上，是不會出現這種問題的。但是如果當requestMapping在controller的類上的時候，那么問題就來了。我們先看一下SpringMvc加載requestMapping到容器的邏輯是什么

@Overrideprotected boolean isHandler(Class> beanType) { return (AnnotatedElementUtils.hasAnnotation(beanType, Controller.class) || AnnotatedElementUtils.hasAnnotation(beanType, RequestMapping.class));}

這個是處理請求映射的判斷依據。從實現中我們看到，只要被掃描的類包含了@Controller或@RequestMapping注解，就會被springMVC加載，那么controller實現了接口具備了requestmapping。feignClient也繼承了接口，那么也就具備了requestMapping。兩個一模一樣的requstMapping，那么是必然會產生沖突的。那么我們的目的是什么呢。controller的正常加載，feignClient不應該進行加載。 我們重新修改下feign的配置類。

@Configuration@ConditionalOnClass({Feign.class})public class FeignConfiguration { @Bean public WebMvcRegistrations feignWebRegistrations() { return new WebMvcRegistrationsAdapter() { @Override public RequestMappingHandlerMapping getRequestMappingHandlerMapping() { return new FeignRequestMappingHandlerMapping(); } }; } private static class FeignRequestMappingHandlerMapping extends RequestMappingHandlerMapping { @Override protected boolean isHandler(Class> beanType) { return super.isHandler(beanType) && !AnnotatedElementUtils.hasAnnotation(beanType, FeignClient.class); } }}

上述代碼我們進行了一個排除，帶feignClint我們不進行加載。 至此feign繼承特性的一個隱藏的坑在這里已經沒了，大家可以放心使用了。

總結

feign的繼承特性是十分方便的一種方式，實實在在的減少了代碼編寫量，也保證了路徑映射和參數的一致性。十分好用。 文中難免有不足，歡迎大家批評指正。

作者：經典雞翅
鏈接：https://juejin.im/post/5ef00012e51d4574113a029a
來源：掘金

總結

以上是生活随笔為你收集整理的feign调用第三方接口_讲一个你不知道的事：SringCloud的feign的继承特性的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。