在一个项目中（数据产品），需要对接企业微信中第三方应用。在使用 Feign 的去调用微服务的用户模块用微信的 code 获取 access_token 以及用户工厂信息时出现 Feign 重试超时报错的情况，通过此篇文章记录问题解决的过程。
一、问题重现
1. Spring Cloud 部分依赖如下
<parent><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-parent</artifactId><version>1.5.3.RELEASE</version></parent><dependencyManagement><dependencies><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-dependencies</artifactId><version>Dalston.SR1</version><type>pom</type><scope>import</scope></dependency></dependencies></dependencyManagement><dependencies><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-eureka</artifactId></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-feign</artifactId></dependency>
2.微信相关的接口文档
前端通过企业 id，配置好回调域名之后，调用微信的 API 去获取 code。见文档：
https://work.weixin.qq.com/api/doc/90000/90135/91022
注意：code只能用一次，见文档，因此获取到的 access_token 需要缓存起来，项目中是缓存到redis中的，用于后续的消息推送等等功能。
3.请求流程图
二、原因分析
首先，整个请求的链路中，阶段 2 是 feign 请求的位置，但是 yml 配置文件中并没有配置 feign。因此可以断定，feign 使用了默认的配置。问题发生时，查看 feign 的文档发现，feign 重试默认超时时间是 1s。
因此现在重新配置 feign 的超时时间，现有 feign 的配置如下：
feign:client:config:organization:connectTimeout: 5000readTimeout: 5000
其中，
-
organization 表示的就是 feign 所调用的服务名称。
-
connectTimeout表示建立请求连接的连接的时间（这里面包括获取请求 Eureka 中保存的服务列表——推测）
-
readTimeout表示连接建立以后请求调用的时间。
其次，在上述配置中，通过查看 organization 和 data 服务的请求日志，发现请求都能顺利建立。但是，当阶段三去请求微信的接口一旦延迟，则会触发 feign 的重试进行第二次调用。
由于阶段三请求微信的接口并不是没有调用，而是由于网络或者其他原因导致的微信没有响应，但是 code 又已经被消费了，当阶段二携带同样的 code 去调用微信的接口，这时就会出现 code 已经被消费。
最后，此时有另外一个问题就是，项目中的服务都是单实例部署，Spring Cloud 组件中 Feign 和 Ribbon 都有重试的功能。 Spring Cloud 中 Feign 整合了 Ribbon，但 Feign 和 Ribbon 都有重试功能。Spring Cloud为了统一两者的行为，在 C 版本以后，将 Feign 的重试策略默认设置为 feign.Retryer#NEVER_RETRY（即永不重试）。因此 Feign 的调用本质还是通过 Ribbon 去实现。
三、相关配置测试
经过测试后，发现 Feign 和 Ribbon 的配置都能实现超时熔断。
版本号：SpringCloud Greenwich.SR1
配置一、只配置 Feign 相关配置，即 Feign 覆盖了 Ribbon 默认的超时时间配置
但是注意，该配置会触发 Ribbon 重试。
feign:client:config:eureka-client:connectTimeout: 1000readTimeout: 1000
配置二、只配置 Ribbon
注意：这里有个坑，MaxAutoRetriesNextServer 这个参数如果不配置为 0，即使在单实例部署的情况下，仍然会发生重试 1 次。因此如果不想发生重试，则需要手动配置 MaxAutoRetriesNextServer=0和MaxAutoRetries=0。
ribbon:ReadTimeout: 4000ConnectionTimeout: 4000OkToRetryOnAllOperations: trueMaxAutoRetriesNextServer: 0 # 当前实例全部失败后可以换1个实例再重试，MaxAutoRetries: 1 # 在当前实例只重试2次
配置三、Feign和 Ribbon 都不配置
注意：经过测试后发现这里使用的是ribbon默认的超时配置，配置如下。
MaxAutoRetriesNextServer=1MaxAutoRetries=0
public LoadBalancerContext(ILoadBalancer lb) {this.clientName = "default";this.maxAutoRetriesNextServer = 1;this.maxAutoRetries = 0;this.defaultRetryHandler = new DefaultLoadBalancerRetryHandler();this.okToRetryOnAllOperations =DefaultClientConfigImpl.DEFAULT_OK_TO_RETRY_ON_ALL_OPERATIONS;this.lb = lb;}
版本号：SpringCloud Dalston.SR1 与 Greenwich.SR1 的测试结论一致
注意：Dalston.SR1 ribbon 组件默认的超时时间
public static final int DEFAULT_READ_TIMEOUT = 5000;public static final int DEFAULT_CONNECT_TIMEOUT = 2000;
Greenwich.SR1 Ribbon 组件默认的超时间
public static final int DEFAULT_CONNECT_TIMEOUT = 1000;public static final int DEFAULT_READ_TIMEOUT = 1000;
