现象最近在测试项目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 的超时时间怎么来的hystrixhystrix的熔断时间根据如下配置: 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 配置为零呢 其实就是基于幂等性的考虑了. 基于不同的场景来决定是否开启失败重试. 一句话,脱离业务的设计都是耍流氓,沈剑老师说的. |
|