Feign：调用方与被调用方集成的对比及Feign继承的应用
在构建微服务架构时，服务之间的通信是一个核心问题。Spring Cloud 提供了多种解决方案，其中 Feign 是一种声明式的Web服务客户端，它使得编写HTTP客户端变得更加简单。本文将探讨 Feign 放置在调用方和被调用方的优缺点，并介绍为什么使用 Feign 继承是一种更优的选择。
一、Feign 放在调用方 vs. 被调用方
（一）放在调用方
优点
- 职责分离：调用方负责定义如何调用远程服务，而服务提供者专注于业务逻辑实现。
- 灵活性：调用方可以根据需要自定义请求配置（如超时设置、重试策略等），而不受限于服务提供者的实现。
- 减少耦合：通过接口定义独立模块，调用方和服务提供者之间保持低耦合度，便于维护和扩展。
缺点
- 额外的工作量：需要为每个调用的服务手动创建接口定义，可能增加一些初始开发工作。
（二）放在被调用方
优点
- 快速集成：可以直接引用服务提供者已经定义好的 Feign 接口，简化了集成过程。
缺点
- 高耦合性：调用方直接依赖于服务提供者的具体实现细节，任何变更都会影响到调用方。
- 灵活性差：调用方无法根据自身需求调整 Feign 客户端的行为，必须遵循服务提供者的配置。
- 维护成本高：当服务提供者更新接口时，所有依赖该接口的调用方都需要同步更新。
二、Feign 继承
（一）案例分析
假设我们有两个服务 A 和 B，A 需要调用 B 的 API 来获取资源信息。我们可以创建一个 api-common 公共模块来定义公共接口 ServiceBApi。
//api-common/src/main/java/com/example/api/common/ServiceApi.java
public interface ServiceApi {@GetMapping("/api/resource/{id}")Resource getResourceById(@PathVariable("id") Long id);
}然后，在服务 B 中实现这个接口：
//service-b/src/main/java/com/example/service/b/controller/ServiceBController.java
@RestController
@RequestMapping("/api")
public class ServiceBController implements ServiceApi {@Overridepublic Resource getResourceById(Long id) {return new Resource(id, "Sample Resource");}
}最后，在服务 A 中引入api-common，使用 FeignClient 注解来继承 ServiceBApi：
//service-a/src/main/java/com/example/service/a/client/ServiceBClient.java
@FeignClient(name = "service-b", url = "${service.b.url}", contextId = "serviceBApi")
public interface ServiceBClient extends ServiceApi {}（二）编码时的好处
- 代码清晰：通过提取公共接口，减少了重复代码，同时明确了服务间的契约。
- 易于维护：集中管理接口定义，一旦接口发生变化，只需修改一处即可，降低了维护成本。
- 提高团队协作效率：允许调用方和服务提供方并行开发，只要双方遵循相同的接口定义。
- 灵活配置：调用方可以根据自己的需求对 Feign 客户端进行定制化配置，提高了系统的灵活性。
三、总结
虽然将 Feign 放在被调用方可以快速集成，但从长远来看，这会导致较高的耦合度和较低的灵活性。相比之下，采用 Feign 继承的方式能够有效地降低系统间的耦合度，提高代码的可维护性和扩展性，结合了将Feign放在调用端和被调用端的优点。因此，在设计微服务架构时，推荐使用 Feign 继承作为最佳实践，以确保系统的健壮性和灵活性。