什么是Hystrix、SpringCloud的各种超时时间配置及微服务优化措施(1)

1. 前言(以下的springcloud版本是Dalston.RC1)

以下的springcloud版本是Dalston.RC1

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-feign8080去调用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 );

}

eureka-feign的service:

/**

* 测试springcloud的超时机制

* @param mills

* @return

*/

@RequestMapping(value = “/timeOut”,method = RequestMethod.GET)

String timeOut(@RequestParam(value = “mills”) int mills);

eureka-feign的熔断方法:

@Override

public String timeOut(int mills) {

System.out.println(“熔断”);

return “熔断了”;

}

访问8080端口, 调用eureka-feign的/timeOut接口, 然后eureka-feign再调用client的服务。下面的配置是eureka-feign的。推荐:Java进阶视频资源

测试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秒左右就可以了。推荐:Java进阶视频资源

测试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:

最后

自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数Java工程师,想要提升技能,往往是自己摸索成长,自己不成体系的自学效果低效漫长且无助。

因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,不论你是刚入门Android开发的新手,还是希望在技术上不断提升的资深开发者,这些资料都将为你打开新的学习之门!

如果你觉得这些内容对你有帮助,需要这份全套学习资料的朋友可以戳我获取!!

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
。**

深知大多数Java工程师,想要提升技能,往往是自己摸索成长,自己不成体系的自学效果低效漫长且无助。

因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。

[外链图片转存中…(img-UszVSrdJ-1715208097536)]

[外链图片转存中…(img-D5OTvSXr-1715208097537)]

[外链图片转存中…(img-cqOVGAfr-1715208097537)]

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,不论你是刚入门Android开发的新手,还是希望在技术上不断提升的资深开发者,这些资料都将为你打开新的学习之门!

如果你觉得这些内容对你有帮助,需要这份全套学习资料的朋友可以戳我获取!!

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值