1.前言
Springcloud框架中,超时时间的设置通常有三个层面:
1.zuul网关
#默认1000
zuul.host.socket-timeout-millis=2000
#默认2000
zuul.host.connect-timeout-millis=4000
2.ribbon
ribbon:
OkToRetryOnAllOperations: false #对所有操作请求都进行重试,默认false
ReadTimeout: 5000 #负载均衡超时时间,默认值5000
ConnectTimeout: 3000 #ribbon请求连接的超时时间,默认值2000
MaxAutoRetries: 0 #对当前实例的重试次数,默认0
MaxAutoRetriesNextServer: 1 #对切换实例的重试次数,默认1
3.熔断器Hystrix
hystrix:
command:
default: #default全局有效,service id指定应用有效
execution:
timeout:
#如果enabled设置为false,则请求超时交给ribbon控制,为true,则超时作为熔断根据
enabled: true
isolation:
thread:
timeoutInMilliseconds: 1000 #断路器超时时间,默认1000ms
feign.hystrix.enabled: true
2.测试各个配置的效果
这里我开了一个Eureka服务中心
开了两个个服务eureka-client,端口分别为8087
和8088
,进行负载均衡
开了一个服务eureka-feign去调用eureka-client的方法,模拟eureka-client处理时间过长的时候出现的情况
eureka-client的方法:
/**
* 测试重试时间
*
* @return
*/
@RequestMapping("/timeOut")
public String timeOut(@RequestParam int mills) {
log.info("[client服务-{}] [timeOut方法]收到请求,阻塞{}ms", port, mills);
try {
Thread.sleep(mills);
} catch (InterruptedException e) {
e.printStackTrace();
}
log.info("[client服务-{}] [timeOut]返回请求",port);
return String.format("client服务-%s 请求ok!!!", port);
}
eureka-feign调用client的方法,通过传参数mills
来控制client线程休眠的时间
/**
* 测试重试时间
* @return
*/
@RequestMapping("/timeOut")
public String timeOut(@RequestParam int mills){
log.info("开始调用");
return feignService.timeOut( mills );
}
service:
/**
* 测试springcloud的超时机制
* @param mills
* @return
*/
@RequestMapping(value = "/timeOut",method = RequestMethod.GET)
String timeOut(@RequestParam(value = "mills") int mills);
熔断方法:
@Override
public String timeOut(int mills) {
System.out.println("熔断");
return "熔断了";
}
测试1
ribbon:
OkToRetryOnAllOperations: false #对所有操作请求都进行重试,默认false
ReadTimeout: 1000 #负载均衡超时时间,默认值5000
ConnectTimeout: 3000 #ribbon请求连接的超时时间,默认值2000
MaxAutoRetries: 0 #对当前实例的重试次数,默认0
MaxAutoRetriesNextServer: 1 #对切换实例的重试次数,默认1
hystrix:
command:
default: #default全局有效,service id指定应用有效
execution:
timeout:
#如果enabled设置为false,则请求超时交给ribbon控制,为true,则超时作为熔断根据
enabled: true
isolation:
thread:
timeoutInMilliseconds: 5000 #断路器超时时间,默认1000ms
测试 900ms
请求正常.
测试 2000ms
熔断
接着测试4000ms, 6000都熔断了
测试2
更换两个超时时间:
ReadTimeout: 3000 #负载均衡超时时间,默认值5000 ConnectTimeout: 1000
#ribbon请求连接的超时时间,默认值2000
ribbon:
OkToRetryOnAllOperations: false #对所有操作请求都进行重试,默认false
ReadTimeout: 3000 #负载均衡超时时间,默认值5000
ConnectTimeout: 1000 #ribbon请求连接的超时时间,默认值2000
MaxAutoRetries: 0 #对当前实例的重试次数,默认0
MaxAutoRetriesNextServer: 1 #对切换实例的重试次数,默认1
hystrix:
command:
default: #default全局有效,service id指定应用有效
execution:
timeout:
#如果enabled设置为false,则请求超时交给ribbon控制,为true,则超时作为熔断根据
enabled: true
isolation:
thread:
timeoutInMilliseconds: 5000 #断路器超时时间,默认1000ms
测试2000ms: 成功了
调用4000ms 熔断了
测试6000ms也是熔断
可见ReadTimeout
和ConnectTimeout
,当调用某个服务等待时间过长的时候, 对超时报错/熔断生效的是ReadTimeout
,ConnectTimeout
则表示连接服务的时间,一般不用配置太久,1~2秒左右就可以了
测试3
现在来测试ReadTimeout
和timeoutInMilliseconds
谁起作用
测试2中的配置如下:
ReadTimeout: 3000 #负载均衡超时时间,默认值5000 ConnectTimeout: 1000
#ribbon请求连接的超时时间,默认值2000
timeoutInMilliseconds: 5000 #断路器超时时间,默认1000ms
在4000ms熔断了,2000ms正常,说明是ReadTimeout
生效, 现在换成:
ReadTimeout: 5000 #负载均衡超时时间,默认值5000
ConnectTimeout: 1000 #ribbon请求连接的超时时间,默认值2000
timeoutInMilliseconds: 3000 #断路器超时时间,默认1000ms
ribbon:
OkToRetryOnAllOperations: false #对所有操作请求都进行重试,默认false
ReadTimeout: 5000 #负载均衡超时时间,默认值5000
ConnectTimeout: 1000 #ribbon请求连接的超时时间,默认值2000
MaxAutoRetries: 0 #对当前实例的重试次数,默认0
MaxAutoRetriesNextServer: 1 #对切换实例的重试次数,默认1
hystrix:
command:
default: #default全局有效,service id指定应用有效
execution:
timeout:
#是否开启超时熔断
enabled: true
isolation:
thread:
timeoutInMilliseconds: 3000 #断路器超时时间,默认1000ms
feign.hystrix.enabled: true
2000ms 正常
4000ms 熔断
说明熔断器timeoutInMilliseconds: 3000
起作用了
测试4
这里再测一个配置:
这个enable如果为false, 则表示熔断器不根据自己配置的超时时间进行熔断,这样的话就会收到ribbon的ReadTimeout
配置的影响了,超过这个时间,eureka-feign会抛出timeout
的异常,这个时候熔断器就会因为这个异常而进行熔断
hystrix:
command: default: #default全局有效,service id指定应用有效
execution:
timeout:
#是否开启超时熔断
enabled: false
测试4000ms 正常
测试6000ms 熔断. 此处是因为ribbon的ReadTimeout: 5000
3.总结
由上面的测试可以得出:
- 如果
hystrix.command.default.execution.timeout.enabled
为true
,则会有两个执行方法超时的配置,一个就是ribbon的ReadTimeout
,一个就是熔断器hystrix的timeoutInMilliseconds
,此时谁的值小谁生效 - 如果
hystrix.command.default.execution.timeout.enabled
为false
,则熔断器不进行超时熔断,而是根据ribbon的ReadTimeout
抛出的异常而熔断,也就是取决于ribbon - ribbon的
ConnectTimeout
,配置的是请求服务的超时时间,除非服务找不到,或者网络原因,这个时间才会生效 - ribbon还有
MaxAutoRetries
对当前实例的重试次数,MaxAutoRetriesNextServer
对切换实例的重试次数,如果ribbon的ReadTimeout
超时,或者ConnectTimeout
连接超时,会进行重试操作 - 由于ribbon的重试机制,通常熔断的超时时间需要配置的比
ReadTimeout
长,ReadTimeout
比ConnectTimeout
长,否则还未重试,就熔断了 - 为了确保重试机制的正常运作,理论上(以实际情况为准)建议hystrix的超时时间为:(
1 + MaxAutoRetries + MaxAutoRetriesNextServer) * ReadTimeout
ribbon:
OkToRetryOnAllOperations: false #对所有操作请求都进行重试,默认false
ReadTimeout: 10000 #负载均衡超时时间,默认值5000
ConnectTimeout: 2000 #ribbon请求连接的超时时间,默认值2000
MaxAutoRetries: 0 #对当前实例的重试次数,默认0
MaxAutoRetriesNextServer: 1 #对切换实例的重试次数,默认1
hystrix:
command:
default: #default全局有效,service id指定应用有效
execution:
timeout:
enabled: true
isolation:
thread:
timeoutInMilliseconds: 20000 #断路器超时时间,默认1000ms
转载自:https://blog.csdn.net/zzzgd_666/article/details/83314833