Feign Client能否结合AWS API Gateway使用？微服务调用选型咨询

完全可以，不要被网上大部分Feign搭配Eureka、Spring Cloud LoadBalancer的教程误导——那些服务发现、负载均衡能力只是Feign的可选集成项，不是运行必选依赖，你的架构里完全可以直接把Feign和AWS API Gateway搭配使用，核心配置要点如下：

• 不需要引入服务发现、客户端负载均衡相关的Starter依赖，也不需要开启服务发现相关注解，直接在定义Feign客户端时，将固定调用地址配置为AWS API Gateway的访问域名即可。示例配置：

@FeignClient(
    name = "aws-api-gateway-client",
    url = "${aws.api-gateway.base-endpoint}",
    configuration = GwAuthConfig.class
)
public interface UserServiceClient {
    @GetMapping("/users/{id}")
    UserDTO getUserById(@PathVariable("id") Long userId);
}

• 所有请求会统一发往API Gateway，由网关本身完成路由转发、负载均衡逻辑，和你用RestTemplate直接调用网关接口的链路完全一致。
• 如果API Gateway侧配置了访问鉴权（比如AWS SigV4签名、API Key校验、自定义JWT校验），只需要在Feign的自定义配置类（比如上面示例里的GwAuthConfig）中注册请求拦截器，统一在请求发出前注入签名、鉴权请求头即可，适配逻辑和普通HTTP调用没有区别。

完全不合理，属于典型的决策短视行为，核心原因如下：

• 组件迁移本身的成本远高于编写RestTemplate单元测试的成本：Feign和RestTemplate的请求参数序列化规则、异常抛出逻辑、超时重试配置、请求日志打印逻辑都存在差异，全量替换后需要做所有接口的回归验证，还要适配新的异常处理、配置规则，花的时间远超过给现有RestTemplate写单测的时间。
• 替换为Feign根本达不到省去单元测试的目的：使用Feign后你依然需要验证接口路径、请求方法、参数序列化规则是否配置正确，降级、容错逻辑是否符合预期，该写的测试用例一点不会少。甚至因为Feign是声明式注解驱动的配置，很多路径写错、参数名不匹配的问题不会在编译期暴露，反而会提高测试排查的成本。
• RestTemplate的单元测试编写成本极低：直接用MockRestServiceServer或者WireMock就可以快速模拟下游服务返回，不需要启动完整Spring上下文，单测运行速度快，单测代码的编写量非常小，完全没必要为了逃避这部分工作引入额外的技术复杂度。

技术组件选型永远要围绕架构实际需求决策，不要为了规避一项极低的短期成本，引入长期的维护负担。

内容的提问来源于stack exchange，提问作者Harsh Kanakhara