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