ribbon 和 hystrix 超时时间的联系

现象

最近在测试项目Zuul层性能的时候发现了后台日志提示

2018-12-03 16:22:30.306  WARN [apigateway,7447152c2c5cc400,7447152c2c5cc400,true] 20024 --- [nio-8102-exec-3] o.s.c.n.z.f.r.s.AbstractRibbonCommand    : The Hystrix timeout of 3000ms for the command serviceA is set lower than the combination of the Ribbon read and connect timeout, 28000ms.

字面意思就是 hystrix 的超时时间小于ribbon的读超时时间和连接超时时间的组合

hystrix 和 ribbon 的作用

hystrix: 熔断器，当zuul网关调用具体的业务的时候可能受到网络，代码执行时间等影响长时间无响应，这个时候就需要配置hystrix，避免线程长时间占用内存，造成内存泄露，服务挂掉.

Ribbon：负载均衡，是针对服务的多实例负载均衡的配置

为什么会有这个警告呢

因为在生产环境我们的服务器一般都是集群部署,ribbon不仅有负载均衡的作用,还会有失败重试,但实例1宕机或者读超时,ribbon会把请求转发到另外一台实例,如果hystrix的熔断时间小于ribbon的超时时间的话,就有可能hystrix在ribbon进行重试的时候就熔断了,所以ribbon的重试配置就没有实际作用了

hystrix 和 ribbon 的超时时间怎么来的

hystrix

hystrix的熔断时间根据如下配置:

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds

ribbon

由上文可知,ribbon的超时时间是于ribbon的读超时时间和连接超时时间的一个组合,查阅源码可知

protected static int getHystrixTimeout(IClientConfig config, String commandKey) {
  int ribbonTimeout = getRibbonTimeout(config, commandKey);
  DynamicPropertyFactory dynamicPropertyFactory = DynamicPropertyFactory.getInstance();
  // 获取默认的hytrix超时时间
  int defaultHystrixTimeout = dynamicPropertyFactory.getIntProperty("hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds", 0).get();
  // 获取具体服务的hytrix超时时间，这里应该是hystrix.command.serviceA.execution.isolation.thread.timeoutInMilliseconds
  int commandHystrixTimeout = dynamicPropertyFactory.getIntProperty("hystrix.command." + commandKey + ".execution.isolation.thread.timeoutInMilliseconds", 0).get();
  int hystrixTimeout;
  // hystrixTimeout的优先级是 具体服务的hytrix超时时间 > 默认的hytrix超时时间 > ribbon超时时间
  if (commandHystrixTimeout > 0) {
    hystrixTimeout = commandHystrixTimeout;
  } else if (defaultHystrixTimeout > 0) {
    hystrixTimeout = defaultHystrixTimeout;
  } else {
    hystrixTimeout = ribbonTimeout;
  }
  // 如果默认的或者具体服务的hytrix超时时间小于ribbon超时时间就会警告
  if (hystrixTimeout < ribbonTimeout) {
    LOGGER.warn("The Hystrix timeout of " + hystrixTimeout + "ms for the command " + commandKey + " is set lower than the combination of the Ribbon read and connect timeout, " + ribbonTimeout + "ms.");
  }

  return hystrixTimeout;
}

由第二行代码可知,ribbonTimeout是通过getRibbonTimeout()方法获取的

protected static int getRibbonTimeout(IClientConfig config, String commandKey) {
  int ribbonTimeout;
  // 默认为 2s
  if (config == null) {
    ribbonTimeout = 2000;
  } else {
    // 这里获取了四个参数，ReadTimeout，ConnectTimeout，MaxAutoRetries， MaxAutoRetriesNextServer,优先级：具体服务 > 默认
    // 1. 请求处理的超时时间,默认 1s
    int ribbonReadTimeout = getTimeout(config, commandKey, "ReadTimeout", Keys.ReadTimeout, 1000);
    // 2. 请求连接的超时时间,默认 1s
    int ribbonConnectTimeout = getTimeout(config, commandKey, "ConnectTimeout", Keys.ConnectTimeout, 1000);
    // 3. 对当前实例的重试次数.默认 0
    int maxAutoRetries = getTimeout(config, commandKey, "MaxAutoRetries", Keys.MaxAutoRetries, 0);
    // 4. 切换实例的重试次数,默认 1
    int maxAutoRetriesNextServer = getTimeout(config, commandKey, "MaxAutoRetriesNextServer", Keys.MaxAutoRetriesNextServer, 1);
    // ribbonTimeout的计算方法
    ribbonTimeout = (ribbonReadTimeout + ribbonConnectTimeout) * (maxAutoRetries + 1) * (maxAutoRetriesNextServer + 1);
  }

  return ribbonTimeout;
}

由此可见,

ribbonTimeout = (ribbonReadTimeout + ribbonConnectTimeout) * (maxAutoRetries + 1) * (maxAutoRetriesNextServer + 1);

其中

ribbonReadTimeout 由 ribbon.ReadTimeout 配置决定
ribbonConnectTimeout 由 ribbon.ConnectTimeout 配置决定
maxAutoRetries 由 ribbon.MaxAutoRetries 配置决定
maxAutoRetriesNextServer 由 ribbon.MaxAutoRetriesNextServer 配置决定

我们项目的配置为

"hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds": 3000
"ribbon.ReadTimeout": 3000,
"ribbon.ConnectTimeout": 1000,
"ribbon.MaxAutoRetries": 0,
"ribbon.MaxAutoRetriesNextServer": 0,

所以ribbonTimeout=(3000+1000)(1+0)(1+0)=4000ms

PS

为什么我们项目的 MaxAutoRetries 和 MaxAutoRetriesNextServer 配置为零呢

其实就是基于幂等性的考虑了.

基于不同的场景来决定是否开启失败重试.

一句话,脱离业务的设计都是耍流氓,沈剑老师说的.