转自：听风是雨，
链接：cnblogs.com/july-sunny/p/12221931.html

在一个项目中（数据产品），需要对接企业微信中第三方应用。在使用 Feign 的去调用微服务的用户模块用微信的 code 获取 access_token 以及用户工厂信息时出现 Feign 重试超时报错的情况，通过此篇文章记录问题解决的过程。

一、问题重现

1. Spring Cloud 部分依赖如下

    org.springframework.boot    spring-boot-starter-parent    1.5.3.RELEASE                        org.springframework.cloud            spring-cloud-dependencies            Dalston.SR1            pom            import                        org.springframework.boot        spring-boot-starter-web                org.springframework.cloud        spring-cloud-starter-eureka                org.springframework.cloud        spring-cloud-starter-feign

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: 5000        readTimeout: 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: 1000        readTimeout: 1000

配置二、只配置 Ribbon

注意：这里有个坑，MaxAutoRetriesNextServer 这个参数如果不配置为 0，即使在单实例部署的情况下，仍然会发生重试 1 次。因此如果不想发生重试，则需要手动配置 MaxAutoRetriesNextServer=0和MaxAutoRetries=0。

ribbon:  ReadTimeout: 4000  ConnectionTimeout: 4000  OkToRetryOnAllOperations: true  MaxAutoRetriesNextServer: 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;

转自：听风是雨，
链接：cnblogs.com/july-sunny/p/12221931.html

记录一次生产上的 Spring Cloud Feign 的重试问题