微服务系列：Spring Cloud 之 Feign、Ribbon、Hystrix 三者超时时间配置

Feign 和 Ribbon

1. 设置 OpenFeign 的超时时间

我们首先来看一下 OpenFeign 自己的请求超时配置，直接在 yml 文件中配置：

feign:
  # 设置 feign 超时时间
  client:
    config:
      # default 设置的全局超时时间，指定服务名称可以设置单个服务的超时时间
      default:
        connectTimeout: 5000
        readTimeout: 5000
复制代码

default 默认是全局的，将 default 换成某个服务的名称可以设置单个服务的超时时间

2. 设置 Ribbon 的超时时间

ribbon:
  # 建立链接所用的时间，适用于网络状况正常的情况下， 两端链接所用的时间
  ReadTimeout: 5000
  # 指的是建立链接后从服务器读取可用资源所用的时间
  ConectTimeout: 5000
复制代码

注意这两个参数设置的时候没有智能提示

ConnectTimeout：

指的是建立连接所用的时间，适用于网络状况正常的情况下，两端连接所用的时间。
在java中，网络状况正常的情况下，例如使用 HttpClient 或者 HttpURLConnetion 连接时设置参数 connectTimeout=5000 即5秒，如果连接用时超过5秒就是抛出 java.net.SocketException: connetct time out 的异常。

ReadTimeout：

指的是建立连接后从服务器读取到可用资源所用的时间。
在这里我们可以这样理解ReadTimeout：正常情况下，当我们发出请求时可以收到请求的结果，也就是页面上展示的内容，但是当网络状况很差的时候，就会出现页面上无法展示出内容的情况。另外当我们使用爬虫或者其他全自动的程序时，无法判断当前的网络状况是否良好，此时就有了ReadTimeout的用武之地了，通过设置ReadTimeout参数，例：ReadTimeout=5000，超过5秒没有读取到内容时，就认为此次读取不到内容并抛出Java.net.SocketException: read time out的异常。

3. 源码追踪

配置都比较简单，接下来我们来追踪一下相关的源码。

首先从 @EnableFeignClients 进去，再到 FeignClientsRegistrar 类中

跟踪到 FeignClientsRegistrar 类中的 registerFeignClient 方法

接着到 FeignClientFactoryBean 类中的 configureUsingProperties 方法

最后一直跟到 feign.Request 中的这里

可以发现 OpenFeign 的默认的 connectTimeout 是 10 秒，readTimeout 是 60 秒。

接下来我们来验证一下，修改我们测试用的那个接口，让它睡个 5 秒

@GetMapping("/getUserInfo")
public Map<String, Object> getUserInfo(int userId){
    Map<String, Object> map = new HashMap<String, Object>();
    User user = new User(1, "小黑", 26);
    map.put("code", 200);
    map.put("data", user.toString());
    try {
        Thread.sleep(5000);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    return map;
}
复制代码

OpenFeign 默认超时时间

此时，我们是要验证 OpenFeign 的默认超时时间，所以在 application.yml 中 feign 和 ribbon 的超时时间都没有设置。

启动项目再次调用我们的老接口：http://localhost:9203/test/getUserInfo?userId=2

what? 报错了，连接超时，可是我们代码里睡 5 秒，明明还在超时时间范围内，怎么就连接超时了呐？

其实 OpenFeign 集成了 Ribbon，Ribbon 的默认超时连接时间、读超时时间都是 1 秒，源码在 org.springframework.cloud.openfeign.ribbon.FeignLoadBalancer#execute()方法中，如下图：

断点打到这里（需要访问上面接口才会进断点）会发现：如果 OpenFeign 没有设置对应得超时时间，那么将会采用 Ribbon 的默认超时时间

设置 OpenFeign 超时时间

feign:
  client:
    config:
      default:
        connectTimeout: 8000
        readTimeout: 8000
复制代码

然后我们重启项目后再访问接口进入上面那个断点看看，发现超时时间变成我们配置的了

接口也返回了正常的结果：

设置 Ribbon 超时时间

ribbon:
  ReadTimeout: 7000
  ConectTimeout: 7000
复制代码

重复上面步骤，断点进去一看？？？怎么还是 8000

原因是 OpenFeign 和 Ribbon 的超时时间只会有一个生效两者是二选一的，且 OpenFeign 优先

注掉 OpenFeign 超时时间配置之后，就变成了使用设置的 Ribbon 的超时时间

4. 结论

Feign 和 Ribbon 的超时时间只会有一个生效，规则：如果没有设置过 feign 超时，也就是等于默认值的时候，就会读取 ribbon 的配置，使用 ribbon 的超时时间和重试设置。否则使用 feign 自身的设置。两者是二选一的，且 feign 优先。

Ribbon 和 Hystrix

1. Hystrix 设置超时时间

# 设置 hystrix 超时时间
feign:
  hystrix:
    enabled: true
hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 6000
复制代码

配置好 fallback

@FeignClient(contextId = "remoteUserService", value = "cloud-system", fallbackFactory = RemoteUserFallbackFactory.class)
复制代码

注意：如果没有配置 fallback，那么 hystrix 的超时就不会生效，而是由 ribbon 来控制。

hystrix 的默认超时时间是 1s，这个配置在 HystrixCommandProperties 类中：

private static final Integer default_executionTimeoutInMilliseconds = 1000;
复制代码

设置 hystrix 超时时间比 ribbon 大（OpenFign 的超时时间注掉）

ribbon:
  ReadTimeout: 2000
  ConectTimeout: 2000
复制代码

访问地址 http://localhost:9203/test/getUserInfo?userId=2 发现请求 2s 左右就返回了，这个值刚好是 ribbon.ReadTimeout 的时间。表示此时 ribbon 超时触发了。然后进入了 hystrix 的熔断过程。

2. 结论：

如果请求时间超过 ribbon 的超时配置，会触发重试；
在配置 fallback 的情况下，如果请求的时间(包括 ribbon 的重试时间)，超出了 ribbon 的超时限制，或者 hystrix 的超时限制，那么就会熔断。

一般来说，会设置 ribbon 的超时时间 < hystrix，这是因为 ribbon 有重试机制。(这里说的 ribbon 超时时间是包括重试在内的，即，最好要让 ribbon 的重试全部执行，直到 ribbon 超时被触发)。

由于 connectionTime 一般比较短，可以忽略。那么，设置的超时时间应该满足：

(1 + MaxAutoRetries) * (1 + MaxAutoRetriesNextServer)* ReadTimeOut < hystrix 的 *timeoutInMilliseconds

原文链接：https://juejin.cn/post/7056218823514390564