SpringCloud——服务容错——Hystrix

本文探讨了大型微服务项目中服务间调用存在的问题,重点介绍了服务降级、服务熔断的概念与应用场景,以及如何通过HystrixCommand和Sentinel进行服务限流,同时提到了监控工具HystrixDashboard的使用。
摘要由CSDN通过智能技术生成

1.现在的微服务存在哪些问题?

        在大型的微服务项目中,肯定少不了服务之间多条链路调用,如果调用中有一个服务出现了问题,如果不做任何的处理,就会造成大量的阻塞,可能会导致整个服务雪崩。

2.要解决的问题

3.服务降级(fallback)

什么情况下需要服务降级:

  • 程序运行异常或者宕机。

  • 超时。

  • 服务熔断触发服务降级(断路器打开)。

  • 线程池/信号量打满也会导致服务降级(利用Jmeter进行了压测,tomcat的默认的工作线程数被打满了,没有多余的线程来分解压力和处理,其他的接口也会卡顿)。

如果出现问题,要返回一个提示或者状态,不要傻等,一般最好在订单服务800处配置兜底方法。

3.1服务降级的配置

        我们要在服务方法上面@HystrixCommand设置一个最长的执行时间,还要设置一个超时或异常之后要执行的兜底的方法。

        但是这样会产生一个新的问题,每个业务方法对应一个兜底的方法,会导致代码膨胀,我们的优化思路是统一的和自定义的分开。在800端的controller层定义全局的服务降级(DefaultProperties)。

        为了防止8001端宕机异常,我们的在所有的方法处配置降级,这样也会和业务逻辑混乱在一起,我们可以在800端的Service层的Feign调用处配置通配的服务降级(FeignFallback)。

注意

        OpenFeign的服务调用默认只等待1秒钟,这里的等待和在controller的方法上配置的timeoutInMilliseconds是不一样的,比如timeoutInMilliseconds=5秒,意思是从我调用到返回到我controller时,我能等待5s,但是人家Service层的OpenFeign还是默认只能等1s。

4.服务熔断

        需要注意的是服务熔断和服务降级完全是两个不同的概念。

4.1熔断机制概述

        熔断机制是应对雪崩效应的一种微服务链路保护机制。当调用链路中的某个微服务出异常或者响应时间太长时,会进行服务降级执行兜底方法,然后可通过其机制判断可能会熔断该节点微服务的调用,等到检测到该节点微服务调用响应正常后,恢复调用链路。

4.2对开启熔断机制过程的梳理

        首先在一定的时间窗口期(默认10s)内,只有当请求的个数满足一定的阈值(默认20个)后,并且其请求失败率超过一定的阈值(默认50%),此时断路器将会开启(open),调用此接口的主逻辑都不能正常执行,会服务降级去调用兜底方法, 一段时间之后(默认5s),会暂时信任一下(openhalf),让一个请求进行执行主逻辑,如果成功,则断路器会关闭(close),如果失败,则断路器继续开启,等待下一次信任。

5.服务限流(后面使用Sentinel解决)

        秒杀高并发等操作时,严禁一窝蜂的过来拥挤,大家排队,一个一个来。

6.HystrixDashboard图形监控的使用

        

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值