为什么要选择Spring cloud Sentinel

🍎对比Hystrix

在SpringCloud当中支持多种服务保护技术：

早期比较流行的是Hystrix框架，但目前国内实用最广泛的还是阿里巴巴的Sentinel框架，这里我们做下对比：

	Sentinel	Hystrix	Resilience4J
隔离策略	信号量隔离	线程池隔离/信号量隔离	信号量隔离
熔断降级策略	基于慢调用比例或异常比例	基于失败比率	基于异常比例,响应时间
实时指标实现	滑动窗口	滑动窗口（基于 RxJava）	Ring Bit Buffer
规则配置	支持多种数据源	支持多种数据源	有限支持
扩展性	多个扩展点丰富的SPI接口	插件的形式	接口形式
基于注解的支持	支持	支持	支持
限流	基于 QPS，支持基于调用关系的限流	有限的支持	Rate Limiter
流量整形	支持慢启动、匀速排队模式	不支持	简单的Rate Limiter 模式
系统自适应保护	支持	不支持	不支持
控制台	开箱即用，可配置规则、查看秒级监控、机器发现等	不完善	不提供控制台,可对接其它监控系统
常见框架的适配	Servlet、Spring Cloud、Dubbo、gRPC 等	Servlet、Spring Cloud Netflix	Servlet、Spring Cloud Netflix
开源社区状态	活跃	停止维护	较活跃

从这张对比图可以看到Sentinel 所占的优势

微服务中，服务间调用关系错综复杂，一个微服务往往依赖于多个其它微服务。

在这里插入图片描述

如图，如果服务提供者I发生了故障，当前的应用的部分业务因为依赖于服务I，因此也会被阻塞。此时，其它不依赖于服务I的业务似乎不受影响。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

但是，依赖服务I的业务请求被阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：

在这里插入图片描述

服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，那么当前服务也就不可用了。

那么，依赖于当前服务的其它服务随着时间的推移，最终也都会变的不可用，形成级联失败，雪崩就发生了：

在这里插入图片描述

解决雪崩问题的常见方式有四种：

•超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待

在这里插入图片描述

方案2：仓壁模式

仓壁模式来源于船舱的设计：

在这里插入图片描述

船舱都会被隔板分离为多个独立空间，当船体破损时，只会导致部分空间进入，将故障控制在一定范围内，避免整个船体都被淹没。

于此类似，我们可以限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离。

在这里插入图片描述

断路器模式：由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。

断路器会统计访问某个服务的请求数量，异常比例：

在这里插入图片描述

当发现访问服务D的请求异常比例过高时，认为服务D有导致雪崩的风险，会拦截访问服务D的一切请求，形成熔断：

在这里插入图片描述

流量控制：限制业务访问的QPS，避免服务因流量的突增而故障。

在这里插入图片描述

什么是雪崩问题？

可以认为：

限流是对服务的保护，避免因瞬间高并发流量而导致服务故障，进而避免雪崩。是一种预防措施。

超时处理、线程隔离、降级熔断是在部分服务故障时，将故障控制在一定范围，避免雪崩。是一种补救措施。