前言
說起SpringChoud的feign大家用過的都說好。Feign是Netflix開發的聲明式、模板化的HTTP客戶端。對於我們微服務來說，微服務之間的api調用，使用feign來說是再方便不過的。本文先介紹一下，傳統的feign的調用寫法方式，再介紹我們的重點feign的繼承特性。
feign的繼承特性有很多的好處，可以進行參數和方法的統一管理，一次修改，feign和具體的controller都變了。
總之好處還是不少的。
傳統的feign的實現方式
傳統的feign是怎樣的實現的呢，我們先通過springmvc搞了一個controller，在controller里面實現我們代碼。此時另一個微服務想直接調用這個請求，那么被調用的微服務就可以聲明一個feign的客戶端，將自身要提供給外部調用的方法，feign提供的方法的requestMapper路徑映射和controller中的保持一致即可訪問的到。
傳統feign的代碼實現
我們先寫一個傳統的controller。我們的目的很簡單，這個controller來返回123。
@RestController
public class DemoController {
@PostMapping("/demo/list")
public String demo(
@RequestBody DemoFeignQueryVO demoFeignQueryVO){
return "123";
}
}
有了controller，我們來寫feign。feign的代碼是十分簡單的，只要保證feignClint的值是我們要調用的微服務的值，然后其中的postMapping的值和上方controller的一樣即可調用到。
@FeignClient(value = "user-system")
@Component
public interface IDemoFeign {
@PostMapping("/demo/list")
public String demo(
@RequestBody DemoFeignQueryVO demoFeignQueryVO);
}
傳統feign的缺點
由上方的代碼來看，有什么缺點呢，比如我要更改controller的參數，那么我需要改兩處地方，一處是自己的controller實現，一處是feign的接口。如果忘改了的話，就會產生未知的錯誤。如果更改了controller的路徑映射呢。同樣的，也需要改兩處位置。這是傳統形式的一種缺點。
feign的繼承特性
如果我們使用feign的繼承特性，就不會有上方的情況產生，繼承特性就是說，我們弄一個共用的接口，在接口上布置我們的requestMapping注解，規定我們的方法參數。然后通過controller實現這個接口。controller就可以針對接口中的方法進行一一的實現。然后針對於我們的feign接口，我們直接繼承共用的接口。這樣feign接口和controller方法是完全保持一致的，當需要修改的時候，完全不需要兩個地方一起修改，直接更改共用的接口即可。
feign的繼承特性的代碼實現
我們將上述的傳統方案的代碼進行一個改寫，通過對比，就可以看出好處。
先聲明一個共用的接口。這里面寫我們所有要提供給外面的方法。
public interface DemoInterface {
@PostMapping("/demo/list")
public String demo(
@RequestBody DemoFeignQueryVO demoFeignQueryVO);
}
有了接口后，我們的controller直接實現這個接口。
@RestController
public 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到容器的邏輯是什么
@Override
protected 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的繼承特性是十分方便的一種方式，實實在在的減少了代碼編寫量，也保證了路徑映射和參數的一致性。十分好用。
文中難免有不足，歡迎大家批評指正。