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

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，你没有紧迫感吗？做了这么多年还不如一个应届生，真的非常尴尬！

进了这个行业就不要把没时间学习当借口，这个行业就是要不断学习，不然就只能被裁员。所以，抓紧时间投资自己，多学点技术，眼前困难，往后轻松！

【关注】+【转发】+【点赞】支持我！创作不易！
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！