简单谈谈什么是Hystrix，以及SpringCloud的各种超时时间配
置效果，和简单谈谈。。。
1. 前⾔(以下的springcloud版本是Dalston.RC1)
以下的springcloud版本是Dalston.RC1
Springcloud框架中，超时时间的设置通常有三个层⾯:
zuul⽹关
1#默认1000
2zuul.host.socket-timeout-millis=2000
3#默认2000
t-timeout-millis=4000
ribbon
1ribbon:
2 OkToRetryOnAllOperations: false #对所有操作请求都进⾏重试，默认false
3 ReadTimeout: 5000 #负载均衡超时时间，默认值5000
4 ConnectTimeout: 3000 #ribbon请求连接的超时时间，默认值2000
5 MaxAutoRetries: 0 #对当前实例的重试次数，默认0
6 MaxAutoRetriesNextServer: 1 #对切换实例的重试次数，默认1
熔断器Hystrix
1hystrix:
2 command:
3 default: #default全局有效，service id指定应⽤有效
4 execution:
5 timeout:
6 #如果enabled设置为false，则请求超时交给ribbon控制，为true，则超时作为熔断根据
7 enabled: true
8 isolation:
9 thread:
10 timeoutInMilliseconds: 1000 #断路器超时时间，默认1000ms
11
abled: true
2.测试各个配置的效果
这⾥我开了⼀个Eureka服务中⼼
开了两个个服务eureka-client，端⼝分别为8087和8088，进⾏负载均衡
开了⼀个服务eureka-feign8080去调⽤eureka-client的⽅法，模拟eureka-client处理时间过长的时候出现的情况
⽣产者eureka-client的⽅法:
1/**
2 * 测试重试时间
3 *
4 * @return
5 */
6 @RequestMapping("/timeOut")
7 public String timeOut(@RequestParam int mills) {
8 log.info("[client服务-{}] [timeOut⽅法]收到请求，阻塞{}ms", port, mills);
9 try {
10 Thread.sleep(mills);
11 } catch (InterruptedException e) {
12 e.printStackTrace();
13 }
14 log.info("[client服务-{}] [timeOut]返回请求",port);
15 return String.format("client服务-%s 请求ok", port);
16 }
消费者eureka-feign调⽤client的⽅法，通过传参数mills来控制client线程休眠的时间
1 /**
2 * 测试重试时间
3 * @return
4 */
5 @RequestMapping("/timeOut")
6 public String timeOut(@RequestParam int mills){
7 log.info("开始调⽤");
8 return feignService.timeOut( mills );
retry是什么意思9 }
eureka-feign的service:
1 /**
2 * 测试springcloud的超时机制
3 * @param mills
4 * @return
5 */
6 @RequestMapping(value = "/timeOut",method = RequestMethod.GET)
7 String timeOut(@RequestParam(value = "mills") int mills);
eureka-feign的熔断⽅法:
1 @Override
2 public String timeOut(int mills) {
3 System.out.println("熔断");
4 return "熔断了";
5 }
访问8080端⼝, 调⽤eureka-feign的/timeOut接⼝, 然后eureka-feign再调⽤client的服务。下⾯的配置是eureka-feign的测试1
测试 900ms
请求正常.
测试 2000ms
熔断
接着测试4000ms, 6000都熔断了
测试2
更换两个超时时间:
1
ribbon:2
OkToRetryOnAllOperations: false #对所有操作请求都进⾏重试，默认false 3
ReadTimeout: 1000 #负载均衡超时时间，默认值50004
ConnectTimeout: 3000 #ribbon 请求连接的超时时间，默认值20005
MaxAutoRetries: 0 #对当前实例的重试次数，默认06
MaxAutoRetriesNextServer: 1 #对切换实例的重试次数，默认17
8
hystrix:9
command:10
default: #default 全局有效，service id 指定应⽤有效11
execution:12
timeout:13
#如果enabled 设置为false ，则请求超时交给ribbon 控制，为true，则超时作为熔断根据14
enabled: true 15
isolation:16 thread:17 timeoutInMilliseconds: 5000 #断路器超时时间，默认1000ms
测试2000ms:
成功了
调⽤4000ms
熔断了
测试6000ms也是熔断
可见ReadTimeout和ConnectTimeout，当调⽤某个服务等待时间过长的时候, 对超时报错/熔断⽣效的是ReadTimeout,ConnectTimeout 则表⽰连接服务的时间,⼀般不⽤配置太久,1~2秒左右就可以了
测试3
现在来测试ReadTimeout和timeoutInMilliseconds谁起作⽤
测试2中的配置如下:
1
ReadTimeout: 3000 #负载均衡超时时间，默认值50002ConnectTimeout: 1000 #ribbon 请求连接的超时时间，默认值2000
1
ribbon:2
OkToRetryOnAllOperations: false #对所有操作请求都进⾏重试，默认false 3
ReadTimeout: 3000 #负载均衡超时时间，默认值50004
ConnectTimeout: 1000 #ribbon 请求连接的超时时间，默认值20005
MaxAutoRetries: 0 #对当前实例的重试次数，默认06 MaxAutoRetriesNextServer: 1 #对切换实例的重试次数，默认1
1
hystrix:2
command:3
default: #default 全局有效，service id 指定应⽤有效4
execution:5
timeout:6
#如果enabled 设置为false ，则请求超时交给ribbon 控制，为true，则超时作为熔断根据7
enabled: true 8
isolation:9 thread:10 timeoutInMilliseconds: 5000 #断路器超时时间，默认1000ms
1
ReadTimeout: 3000 #负载均衡超时时间，默认值50002
ConnectTimeout: 1000 #ribbon 请求连接的超时时间，默认值20003 timeoutInMilliseconds: 5000 #断路器超时时间，默认1000ms
在4000ms熔断了,2000ms正常，说明是ReadTimeout⽣效, 现在换成:
1ReadTimeout: 5000 #负载均衡超时时间，默认值5000
2 ConnectTimeout: 1000 #ribbon请求连接的超时时间，默认值2000
3 timeoutInMilliseconds: 3000 #断路器超时时间，默认1000ms
也就是
1ribbon:
2 OkToRetryOnAllOperations: false #对所有操作请求都进⾏重试，默认false
3 ReadTimeout: 5000 #负载均衡超时时间，默认值5000
4 ConnectTimeout: 1000 #ribbon请求连接的超时时间，默认值2000
5 MaxAutoRetries: 0 #对当前实例的重试次数，默认0
6 MaxAutoRetriesNextServer: 1 #对切换实例的重试次数，默认1
7
8hystrix:
9 command:
10 default: #default全局有效，service id指定应⽤有效
11 execution:
12 timeout:
13 #是否开启超时熔断
14 enabled: true
15 isolation:
16 thread:
17 timeoutInMilliseconds: 3000 #断路器超时时间，默认1000ms
18
abled: true
2000ms 正常
在这⾥插⼊图⽚描述
4000ms 熔断
在这⾥插⼊图⽚描述
说明熔断器timeoutInMilliseconds: 3000起作⽤了
测试4
这⾥再测⼀个配置:
这个enable如果为false, 则表⽰熔断器不根据⾃⼰配置的超时时间进⾏熔断，这样的话就会收到ribbon的ReadTimeout配置的影响了，超过这个时间,eureka-feign会抛出timeout的异常，这个时候熔断器就会因为这个异常⽽进⾏熔断
1hystrix:
2 command:
3 default: #default全局有效，service id指定应⽤有效
4 execution:
5 timeout:
6 #是否开启超时熔断
7 enabled: false
测试4000ms 正常
在这⾥插⼊图⽚描述
测试6000ms 熔断. 此处是因为ribbon的ReadTimeout: 5000
在这⾥插⼊图⽚描述
3.总结
由上⾯的测试可以得出:
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论