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:
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
4.微服务优化
4.1 什么是hystrix
我们先来看这么一个图,假如订单服务需要调用积分服务,库存服务,仓储服务,订单服务的线程池有100个线程,这个时候积分服务突然挂了.这时候同时有大量的请求来访问订单服务,最终的结果是这100个线程都会卡在积分服务这里,这时候订单服务也没有多余的线程处理请求了,所以订单服务也差不多挂了.
这就是微服务中的服务雪崩问题.
而这时你会发现,如果我只是看看这个商品还有多少库存,那么订单服务就只需要调用库存服务就可以了,并不受积分服务的影响.
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Java工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注Java获取)
最后如何让自己一步步成为技术专家
说句实话,如果一个打工人不想提升自己,那便没有工作的意义,毕竟大家也没有到养老的年龄。
当你的技术在一步步贴近阿里p7水平的时候,毫无疑问你的薪资肯定会涨,同时你能学到更多更深的技术,交结到更厉害的大牛。
推荐一份Java架构之路必备的学习笔记,内容相当全面!!!
成年人的世界没有容易二字,前段时间刷抖音看到一个程序员连着加班两星期到半夜2点的视频。在这个行业若想要拿高薪除了提高硬实力别无他法。
你知道吗?现在有的应届生实习薪资都已经赶超开发5年的程序员了,实习薪资26K,30K,你没有紧迫感吗?做了这么多年还不如一个应届生,真的非常尴尬!
进了这个行业就不要把没时间学习当借口,这个行业就是要不断学习,不然就只能被裁员。所以,抓紧时间投资自己,多学点技术,眼前困难,往后轻松!
【关注】+【转发】+【点赞】支持我!创作不易!
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!
自己一步步成为技术专家
说句实话,如果一个打工人不想提升自己,那便没有工作的意义,毕竟大家也没有到养老的年龄。
当你的技术在一步步贴近阿里p7水平的时候,毫无疑问你的薪资肯定会涨,同时你能学到更多更深的技术,交结到更厉害的大牛。
推荐一份Java架构之路必备的学习笔记,内容相当全面!!!
[外链图片转存中…(img-zSD72dqn-1713470910846)]
成年人的世界没有容易二字,前段时间刷抖音看到一个程序员连着加班两星期到半夜2点的视频。在这个行业若想要拿高薪除了提高硬实力别无他法。
你知道吗?现在有的应届生实习薪资都已经赶超开发5年的程序员了,实习薪资26K,30K,你没有紧迫感吗?做了这么多年还不如一个应届生,真的非常尴尬!
进了这个行业就不要把没时间学习当借口,这个行业就是要不断学习,不然就只能被裁员。所以,抓紧时间投资自己,多学点技术,眼前困难,往后轻松!
【关注】+【转发】+【点赞】支持我!创作不易!
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!