注意:本Sentinel与Redis服务Sentinel是两回事,压根不是一个概念,请大家不要混肴。
Sentinel是由阿里巴巴中间件团队开发的开源项目,是一种面向分布式微服务架构的轻量级高可用流量控制组件。
(资料图片仅供参考)
Sentinel(哨兵)是 Redis 的高可用性解决方案:由一个或多个 Sentinel 实例组成的 Sentinel 系统可以监视任意多个主服务器,以及这些主服务器属下的所有从服务器,并在被监视的主服务器进入下线状态时,自动将下线主服务器属下的某个从服务器升级为新的主服务器。
所以加下来我们介绍的都是【Alibaba的Sentinel】,所以请大家不要理解错误哦!好 我们接下来进入正题。
伴随微服务的的越来越成熟和稳定发展,服务和服务之间的稳定性变得越来越重要。Sentinel以流量为切入点,从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
首先针对于Sentinel进行梳理一下对应的发展史,看看Sentinel是如何一步一步的发展起来的,Sentinel是2012年创立出来的,距今已经成长了10个年头了,接下来我们看看每个它阶段的成长经历吧!如下图所示。
根据上面介绍的对应的发展历程,我大概给Sentinel的发展经历划分为三个大阶段,如下所示。
本节内容主要针对于Sentinel的优点和具有的较为不错的特性进行分析,如以下图所示。
Sentinel承接了阿里巴巴近10年的"双十一”大促流量的核心场景,例如,秒杀(将突发流量控制在系统可以承受的范围)、消息削峰填谷、集群流量控制、实时熔断下游不可用服务等。
Sentinel提供了实时监控功能。用户可以在控制台中看到接入应用的单台机器的秒级数据,甚至是500台以下规模集群的汇总运行情况。
Sentinel提供了开箱即用的与其它开源框架或库(例如:Spring Cloud、Apache Dubbo、gRPC、Quarkus)的整合模块。我们只要在项目中引入相应的依赖并进行简单的配置即可快速地接入Sentinel。此外,Sentinel还提供Java、Go 以及 C++ 等多语言的原生实现。
Sentinel提供简单易、完善的SPI扩展接口,可以通过实现这些扩展接口快速地定制逻辑。
例如,定制规则管理、适配动态数据源等。
SPI ,全称为 Service Provider Interface,是一种服务发现机制。它可以在 ClassPath 路径下的 META-INF/services 文件夹查找文件,并自动加载文件中定义的类。
Sentinel与Spring Cloud Netfilx—Hystrix类似,但Sentinel要比Hystrix更加强大。例如,Sentinel提供了流量控制功能、比Hystrix更加完善的实时监控功能等等。
服务框架功能点 | Hystrix | Sentinel |
熔断能力 | 好 | 好 |
资源隔离 | 很好 | 不太好 |
服务限流 | 好 | 很好 |
实时监控 | 一般 | 很好 |
资源(Resource)是Sentinel的关键概念,它可以是Java应用程序中的任何内容,例如,由应用程序提供的服务,或由应用程序调用的其它应用提供的服务,甚至可以是一段代码。
通过Sentinel API定义的代码,就是资源,能够被Sentinel保护起来。大部分情况下,可以使用方法签名,URL,甚至服务名称作为资源名来标示资源。
围绕资源的实时状态设定的规则,可以包括,流量控制规则、熔断降级规则以及系统保护规则。所有规则可以动态实时调整。
graph LRA1[服务请求] -- 调用 --> B(资源)A2[服务请求] -- 调用 --> B{资源}B[申请资源] --> C(流量控制规则)B[申请资源] --> D{熔断降级规则}B[申请资源] --> E{系统保护规则}C(流量控制规则) --> F[请求执行] D(熔断降级规则) --> F[请求执行]E(系统保护规则) --> F[请求执行]
流量控制在网络传输中是一个常用的概念,它用于调整网络包的发送数据,主要用于处理服务调用、接口调用及相关的调用流量速度控制和限制的规则。偏向于QPS维度的概念。
对于以上的三点流量控制的要求,Sentinel作为一个流量调配器,可以根据需要把随机的请求调整成合适的形状,如下图所示:
Sentinel的设计理念是让您自由选择控制的角度,并进行灵活组合,从而达到想要的效果。
资源的调用链路,资源和资源之间的关系
指标名称 | 备注 |
QPS | 每秒的服务调用量 |
线程池 | 服务线程调用计数器/资源隔离 |
系统负载 | 在动态化调整容器化负载能力 |
指标名称 | 备注 |
直接限流 | 流量控制 |
冷启动 | 如何分配对应的规则给 ,调用了较少的服务或者接口 |
排队 | 请求排队机制 |
主要用于当服务宕机或者此接口一直处于调用失败后的,方式进行控制是否进行熔断降级规则的开关控制。
流量控制以外,降低调用链路中的不稳定资源也是Sentinel的使命之一。由于调用关系的复杂性,如果调用链路中的某个资源出现了不稳定,最终会导致请求发生堆积。这个问题和Hystrix里面描述的问题是一样的。如下图所示
从上面的两个图可以看出来Sentinel和Hystrix的原则是一致的: 当调用链路中某个资源出现不稳定,例如,表现为 timeout,异常比例升高的时候,则对这个资源的调用进行限制,并让请求快速失败,避免影响到其它的资源,最终产生雪崩的效果。
为了实现资源的隔离以及服务的熔断控制,Sentinel和Hystrix采取了完全不一样的方法。
如果通过线程池的方式,来对依赖(资源之间的依赖或者资源服务之间的调用链路)进行了隔离。好处资源和资源之间做到了最彻底的隔离,并且还可以支持超时时间的控制缺点是除了增加了线程切换的成本,还需要预先给各个资源做线程池大小的分配。如果通过信号量方式进行资源隔离,则只能运行控制调用资源的总量,这与【通过并发线程数进行限制】有点类似。Hystrix采用的是线程池(默认)和信号量两种方案去实现。
Sentinel采取了两种手段去实现。
通过并发线程数进行限制资源池隔离的方法不同,Sentinel通过限制资源并发线程的数量,来减少不稳定资源对其它资源的影响。这样不但没有线程切换的损耗,也不需要您预先分配线程池的大小。
当某个资源出现不稳定的情况下,例如,响应时间变长,对资源的直接影响就是会造成线程数的逐步积。当线程数在特定资源上堆积到一定的数量之后,对该资源的新请求就会被拒绝。堆积的线程完成任务后才开始继续接收请求。
通过响应时间对资源进行降级对并发线程数进行控制以外,Sentinel还可以通过响应时间来快速降级不稳定的资源。当依赖的资源出现响应时间过长后,所有对该资源的访问都会被直接拒绝,直到过了指定的时间窗口之后才重新恢复。
主要用于当服务系统的保护规则能力,觉得是否接收该服务的请求的处理模式机制。
Sentinel 同时提供系统维度的自适应保护能力。防止雪崩,是系统防护中重要的一环。当系统负载较高的时候,如果还持续让请求进入,可能会导致系统崩溃,无法响应。在集群环境下,网络负载均衡会把本应这台机器承载的流量转发到其它的机器上去。如果这个时候其它的机器也处在一个边缘状态的时候,这个增加的流量就会导致这台机器也崩溃,最后导致整个集群不可用。
针对这个情况,Sentinel 提供了对应的保护机制,让系统的入口流量和系统的负载达到一个平衡,保证系统在能力范围之内处理最多的请求。
具体细节功能会在后面的专题文章讲述,谢谢大家多指正