Sentinel专门用来解决服务雪崩问题
1. 服务雪崩问题
随着微服务的流行,服务和服务之间的稳定性变得越来越重要,通常一个业务调用需要经过多个后端微服务,假设在整个调用链路上,某个服务不可用的话,则有可能造成整个调用链路上的多个微服务不可用,这种效应称为**服务雪崩(级联故障/失效)**。
2. 雪崩问题发生的原因
1) 依赖服务I的业务请求被阻塞,用户不会得到响应,则tomcat的这个线程不会释放,于是越来越多的用户请求到来,越来越多的线程会阻塞。
2) 服务器支持的线程和并发数有限,请求一直阻塞,会导致服务器资源耗尽,从而导致所有其它服务都不可用,那么当前服务也就不可用了。
于是依赖于当前服务的其它服务随着时间的推移,最终也都会变的不可用,形成级联失败,雪崩就发生了
1. 服务雪崩问题的解决方式
1) 超时处理 :
设定超时时间,请求超过一定时间没有响应就返回错误信息,不会无休止等待
2)仓壁模式 :
船舱都会被隔板分离为多个独立空间,当船体破损时,只会导致部分空间进入,将故障控制在一定范围内,避免整个船体都被淹没。
于此类似,我们可以限定每个业务能使用的线程数,避免耗尽整个tomcat的资源,因此也叫线程隔离。
3)断路器
由*断路器*统计业务执行的异常比例,如果超出阈值则会*熔断*该业务,拦截访问该业务的一切请求
4)限流
限制业务访问的QPS,避免服务因流量的突增而故障
备注 : 从原理上说,其中前三种方式是解决雪崩问题,第四种限流方式是*组止*雪崩的发生
相关概念:
1. QPS: 每秒的请求数
2. RT : 响应时间(response time)
2. 服务保护的技术栈的对比
3. 服务保护---流量控制(限流)
雪崩问题虽然有四种方案,但是限流是避免服务因突发的流量而发生故障,是对微服务雪崩问题的预防。我们这里先介绍这种模式。
4.1 簇点链路
簇点链路是什么:
当请求进入微服务时,首先会访问DispatcherServlet,然后进入Controller、Service、Mapper,这样的一个调用链就叫做**簇点链路**
簇点链路中被监控的每一个接口就是一个**资源**
举例:
比如我们访问的controller层中的方法接口**/order/{orderId},**这就是一个链路
**注意:**
sentinel默认只对controller层的簇点实施监控,其他层需要手动监控
4.2 流控模式
4.2.1 流控模式的种类(三种)
- 直接:统计当前资源的请求,触发阈值时对当前资源直接限流,也是默认的模式
- 关联:统计与当前资源相关的另一个资源,触发阈值时,对当前资源限流
- 链路:统计从指定链路访问到本资源的请求,触发阈值时,对指定链路限流
4.2.2 直接-流控模式
在簇点链路中点击**流控**
设置以下信息
阈值类型:
QPS : 每秒请求数量
单机阈值: 每台机器每秒接收请求的数量
4.2.3 关联-流控模式
统计与当前资源相关的另一个资源,触发阈值时,对当前资源限流(拎一个资源达到阈值时,把当前资源限流)
query达到阈值时,对update进行限流
**注意**: 需要对谁限流,就要给谁加流控
4.2.4 链路-流控模式
如果有多个链路需要调用goods链路,那么当goods链路达到阈值时,对调用goods的链路进行限流
**/order/query**和**/order/sava**都调用了**goods**链路,当**goods**链路达到阈值2时,对**/order/query**进行了限流,进而确保了**/order/save**的正常使用
4.3 流控效果
4.3.1 流控效果的种类(三种)
- 快速失败:达到阈值后,新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。
- warm up:预热模式,对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化,从一个较小值逐渐增加到最大阈值。
- 排队等待:让所有的请求按照先后次序排队执行,两个请求的间隔不能小于指定时长
4.3.2 快速失败-**流控**效果
没什么好讲的,上述都是这个效果
4.3.3 warm up(预热)-流控效果
预热模式,对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化,从一个较小值逐渐增加到最大阈值。
为什么要使用这种流控效果?
阈值一般是一个微服务能承担的最大QPS,但是一个服务刚刚启动时,一切资源尚未初始化(**冷启动**),如果直接将QPS跑到最大值,可能导致服务瞬间宕机。
测试:
4.3.4 排队等待-流控效果
例如:QPS = 5,意味着每200ms处理一个队列中的请求;timeout = 2000,意味着**预期等待时长**超过2000ms的请求会被拒绝并抛出异常。
每秒请求量为5,说明每秒处理5个请求,处理每个请求的时间位200毫秒,超时时间2000毫秒,可以容纳11个请求
当队列充超过11个请求时,后面的请求就会拒绝
现在我们每秒发10个请求,预期是前两秒不会拒绝,会连续成功10个请求,之后会接收5个拒绝5个
4.3.5 热点参数限流
之前的限流是统计访问某个资源的所有请求,判断是否超过QPS阈值。而热点参数限流是**分别统计参数值相同的请求**,判断是否超过QPS阈值。
即对指定的参数进行阈值判断并限流