Feign的最佳实践并非抽离到一个公共模块

本篇文章分享Feign的最佳实践并非抽离到一个公共模块，对你有帮助的话记得收藏一下，看极客资料网收获更多编程知识

多数博文,网上资料推荐将Feign调用相关dto,client统一抽离至一个模块,如此使用更加方便,可便捷复用代码

但是 Feign 的本质是调用方的基础设施组件，而非服务提供方的 API 定义载体

实践方式	核心问题	风险表现
抽离到提供方公共模块	双向耦合	提供方改接口，所有调用方必须同步升级；版本管理混乱，维护成本高
调用方内部定义	职责清晰	调用方自主控制客户端定义，不受提供方变更影响；符合微服务服务自治原则

在小团队中,抽离至一个模块确实便于复用代码,编写feign调用更加顺手,并且一旦发生接口变更,新增或删除接口
也可以顺手将Feign模块中的接口一并修改

但是在大团队中,这种抽离方式相当于将Feign模块当成了基础设施模块了,各团队发生接口变动,频繁打包发布,频繁修改版本号
其他调用方团队需要频繁修改pom.xml来保证Feign模块依赖版本号同步,若使用流水线还需额外维护依赖,
极易引发版本冲突回归问题,更何况各团队水平不一,云端私服依赖和maven本地缓存,IDEA缓存与依赖冲突BUG
这些问题导致依赖管理维护成本很高

抽象地讲,服务提供方的职责是实现 API,而 Feign 是调用方的客户端映射
将 Feign 接口放在提供方模块，会混淆 "API 定义" 与 "客户端调用" 的边界,违背模块单一职责原则

具体地讲,这样会形成"提供方→调用方"的依赖,调用方依赖于提供方提供的API定义,提供方一旦发生接口变更发版,
下游由于引入了Feign接口模块,导致拉一下git就直接爆红,连项目启动都做不到,需要同步变更代码,
破坏了各个模块服务的独立性,从"可以主动改代码"->"被迫要跟着改代码"
如果不抽离成公共模块,上游发生接口变更,下游拉取代码发现接口变更了,但是这只是Feign接口契约发
生了变更,并不是代码上的爆红(是运行时报错，而非编译爆红),顶多只是这个变更的接口会调用报错罢了,还是能正常启动正常开发的
等后期排期适配时间,且每个服务都有自己的client,选择想调用哪个接口就写哪个接口即可,不会引入所有client方法

只有当接口稳定了不频繁变动,提供方已经走人了去维护下一个项目了,调用方就可以考虑抽离为一个公共模块
调用方去维护此公共模块,复用代码

总结就是:Feign 作为调用方的声明式 HTTP 客户端，不应抽离到服务提供方维护的公共模块，更推荐在调用方内部定义；
仅在多调用方共享、接口稳定的场景下，可抽离为独立的调用方共享模块，但是要严格控制依赖与版本

 

文章来源:https://www.cnblogs.com/lxl-233/p/19841828
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！