1.初识Sentinel
1.1.雪崩问题及解决方案
微服务中,服务间调用关系错综复杂,一个微服务往往依赖于多个其它微服务.
那么,依赖于当前服务的其它随着时间的推移,最终也都会变的不可用,形成级联失败,雪崩就发生了:
1.1.2.超时处理
解决雪崩问题的常见方式有四种:
超时处理:设定超时时间,请求超过一定时间没有响应就返回错误信息,不会无休止等待
1.1.3.仓壁模式
仓壁模式
仓壁模式来源于船舱设计:
船舱都会被隔板分离为多个独立空间，当船体破损时，只会导致部分空间进入，将故障控制在一定范围内，避免整个船体都被淹没。
与此类似,我们可以限定每个业务能使用的线程数,避免耗尽整个tomcat的资源,因此也叫线程隔离
断路器模式:由断路器统计业务执行的异常比例,如果超出阈值则会熔断该业务,
拦截访问该业务的一切请求.
1.1.5.限流
流量控制:限流业务访问的QPS,避免服务因流量的突增而故障.
1.1.6.总结
什么是雪崩问题
微服务之间相互调用,因为调用链中的一个服务故障,引起整个链路都无法访问的情况.
可以认为:
限流是对服务的保护,避免因瞬间高并发流量而导致服务故障,进而避免雪崩.是一种预防措施.
超时处理、线程隔离、降级熔断 是在部分服务故障时,将故障控制在一定范围,避免雪崩.是一种补救措施.
2.2.流控模式
在添加限流规则时,点击高级选项,可以选择三种流控模式:
直接:统计当前资源的请求,触发阈值时对当前资源直接限流,也是默认的模式
关联:统计与当前资源相关的另一个资源,触发阈值时,对当前资源限流
链路:统计从指定链路访问到本资源的请求,触发阈值时,对指定链路限流
2.2.1.关联模式
关联模式:统计与当前资源相关的另一个资源,触发阈值时,对当前资源限流.
2.2.2.链路模式
链路模式:只针对从指定链路访问到本资源的请求做统计,判断是否超过阈值.
2.2.3.总结
流控模式有哪些?
直接:对当前资源限流
关联:高优先级资源触发阈值,对低优先级资源限流.
链路:阈值统计时,只统计从指定资源进入当前资源的请求,是对请求来源的限流.
2.3.1.warm up
阈值一般是一个微服务能承担的最大QPS，但是一个服务刚刚启动时，一切资源尚未初始化（冷启动），如果直接将QPS跑到最大值，可能导致服务瞬间宕机。
warm up也叫预热模式，是应对服务冷启动的一种方案。请求阈值初始值是 maxThreshold / coldFactor，持续指定时长后，逐渐提高到maxThreshold值。而coldFactor的默认值是3.
2.3.2.排队等待
当请求超过QPS阈值时，快速失败和warm up 会拒绝新的请求并抛出异常。
而排队等待则是让所有请求进入一个队列中，然后按照阈值允许的时间间隔依次执行。后来的请求必须等待前面执行完成，如果请求预期的等待时间超出最大时长，则会被拒绝。
2.3.3.总结
流控效果有哪些？
- 快速失败：QPS超过阈值时，拒绝新的请求
- warm up： QPS超过阈值时，拒绝新的请求；QPS阈值是逐渐提升的，可以避免冷启动时高并发导致服务宕机。
- 排队等待：请求会进入队列，按照阈值允许的时间间隔依次执行请求；如果请求预期等待时长大于超时时间，直接拒绝
3.1.FeignClient整合Sentinel
SpringCloud中，微服务调用都是通过Feign来实现的，因此做客户端保护必须整合Feign和Sentinel。
3.1.3.总结
Sentinel支持的雪崩解决方案：
- 线程隔离（仓壁模式）
- 降级熔断
Feign整合Sentinel的步骤：
- 在application.yml中配置：feign.sentienl.enable=true
- 给FeignClient编写FallbackFactory并注册为Bean
- 将FallbackFactory配置到FeignClient
3.2.线程隔离（舱壁模式）
3.2.1.线程隔离的实现方式
线程隔离有两种方式实现：
- 线程池隔离
- 信号量隔离（Sentinel默认采用）
线程池隔离：给每个服务调用业务分配一个线程池，利用线程池本身实现隔离效果
信号量隔离：不创建线程池，而是计数器模式，记录业务使用的线程数量，达到信号量上限时，禁止新的请求
3.2.2.sentinel的线程隔离
线程数：是该资源能使用用的tomcat线程数的最大值。也就是通过限制线程数量，实现线程隔离（舱壁模式）。
3.2.3.总结
线程隔离的两种手段是？
- 信号量隔离
- 线程池隔离
信号量隔离的特点是？
- 基于计数器模式，简单，开销小
线程池隔离的特点是？
- 基于线程池模式，有额外开销，但隔离控制更强
若有收获，就点个赞吧
0 人点赞
