问题描述
在之前发布的《Spring Cloud实战小贴士:Feign的继承特性(伪RPC模式)》一文中,我们介绍了如果使用Feign的继承特性来完成服务的提供以及服务的消费,实现了类似RPC的编程模式。但是,仔细一些的读者可能已经发现一个问题:当我们将服务消费者运行起来的时候,定义在服务提供方的那些请求映射关系也被加载到了服务消费者中,这就会带来两个问题:
- 由于服务消费者并不提供这些接口,对于开发者来说容易造成误解
- 由于加载了一些外部服务的接口定义,还存在与自身接口定义冲突的潜在风险
问题分析
那么这些外部请求接口定义是如何被加载到消费端的呢?我们先来看看Spring MVC处理请求映射的RequestMappingHandlerMapping
实现片段:
@Override protected boolean isHandler(Class<?> beanType) { return (AnnotatedElementUtils.hasAnnotation(beanType, Controller.class) || AnnotatedElementUtils.hasAnnotation(beanType, RequestMapping.class)); }
我们可以发现如上的这段实现,该函数用来判断是否要处理请求映射的判断依据。从实现中我们看到,只要被扫描的类包含了@Controller
注解或@RequestMapping
注解,那么就会被加载进来。虽然@FeignClient
定义修饰的服务消费端没有声明这些注解,但是当我们使用了继承特性的时候,那么这些注解就也会被服务消费者解析和加载,所以出现了上面所描述的现象。
解决方法
既然已经找到了问题所在,那么我们可以针对性的扩展处理:扩展RequestMappingHandlerMapping
的isHandler
函数。
@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); } } }
如上实现的isHandler
函数继承了原来的实现,同时增加了一个条件:不能被@FeignClient
注解修饰的类才会进行解析加载。