目录
1:Feign使用优化
2:最佳实践
2.4.1:继承方式
2.4.2:抽取方式
2.4.3:实现基于抽取的最佳实践
1):抽取
2):在中使用feign-api
3):重启测试
4):解决扫描包问题
5):重新进行重启请求测试
1:Feign使用优化
Feign底层发起http请求,依赖于其它的框架。其底层客户端实现包括:
•URLConnection:默认实现,不支持连接池
•Apache HttpClient :支持连接池
•OKHttp:支持连接池
Feign底层默认使用的是URLConnection客户端,该客户端不支持连接池,不支持连接池在建立的过程中可是相当费时的。
优化1:因此提高Feign的性能主要手段就是使用**连接池**代替默认的URLConnection。
优化2:日志的级别,尽量使用basic或者是none,不开日志效率更好
这里我们用Apache的HttpClient来演示。
1)引入依赖
在nacos-consumer的pom文件中引入Apache的HttpClient依赖:
2)配置连接池
在order-service的application.yml中添加配置
接下来,在FeignClientFactoryBean中的loadBalance方法中打断点:
Debug方式启动nacos-consumer服务,可以看到这里的client,底层就是Apache HttpClient:
2:最佳实践
所谓最近实践,就是使用过程中总结的经验,最好的一种使用方式。
自习观察可以发现,Feign的客户端与服务提供者的controller代码非常相似:
feign客户端:
controller:
有没有一种办法简化这种重复的代码编写呢?
2.4.1:继承方式
一样的代码可以通过继承来共享:
1)定义一个API接口,利用定义方法,并基于SpringMVC注解做声明。
2)Feign客户端和Controller都集成改接口
优点:
- 简单
- 实现了代码共享
缺点:
- 服务提供方、服务消费方紧耦合(统一API更改时,服务端客户端都要进行修改,耦合度提高了)
- 参数列表中的注解映射并不会继承,因此Controller中必须再次声明方法、参数列表、注解(springMVC不支持将注解,参数列表中的注解也依次进行继承依次需要重新)
- 但这种方式其实利用了一种面向锲约的思想,还是有可实现性价值的存在
2.4.2:抽取方式
这种方式主要为了方便:多个服务如果都需要调用user服务的暴露的登录接口,那么多个服务都需要书写feign的客户端进行调用,那么就会很麻烦
将Feign的Client抽取为独立模块,并且把接口有关的POJO、默认的Feign配置都放到这个模块中,提供给所有消费者使用。
例如,将UserClient、User、Feign的默认配置都抽取到一个feign-api包中,所有微服务引用该依赖包,即可直接使用。
2.4.3:实现基于抽取的最佳实践
1):抽取
首先创建一个module,命名为feign-api:
项目结构:
在feign-api中然后引入feign的starter依赖
然后,nacos_consumer中编写的Feign客户端、DefaultFeignConfiguration都复制到feign-api项目中
2):在中使用feign-api
首先,删除nacos_consumer中的feign客户端、DefaultFeignConfiguration等类或接口。
在nacos_consumer的pom文件中中引入feign-api的依赖:
修改nacos_consumer中的所有与上述两个组件有关的导包部分,改成导入feign-api中的包
3):重启测试
重启后,发现服务报错了:
Description:
A component required a bean of type 'com.tudou.feign.clients.EchoFeign' that could not be found.
Action:
Consider defining a bean of type 'com.tudou.feign.clients.EchoFeign' in your configuration.
原因不在同一个包,无法扫描到EchoFeign。 是spring没有找到EchoFeign这个类
4):解决扫描包问题
当定义的FeignClient不在SpringBootApplication的扫描包范围时,这些FeignClient无法使用。有两种方式解决
方式一:
指定Feign应该扫描的包:
方式二:
指定需要加载的Client接口:
推荐使用第二种:指定类扫描,如果扫包会将其他用不到也一起加载到容器中造成多余的浪费
5):重新进行重启请求测试
测试成功