随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 把流量作为切入点，从流量控制，熔断降级，系统负载保护等多个维度保护服务的稳定性。
- 2013年，Sentinel 诞生。它的功能主要集中在控制入口流量控制
- 2014-2017年，Sentinel 在阿里巴巴集团内部迅速发展，成为了基础的模块，覆盖了所有的核心场景。在这段时间，Sentinel 积累了大量的流量归整场景以及生产实践
- 2018年，Sentinel 开始开源
随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 把流量作为切入点，来保护服务的稳定性。其中主要的功能包括:
资源是Sentinel的关键概念。 它可以是Java应用程序中的任何内容，例如，由应用程序提供的服务; 或由应用程序调用的其它应用提供的服务，甚至可以是一段代码。
只要通过[Sentinel API]定义的代码，就是资源，能够被sentinel保护起来。 大部分情况下，可以使用方法签名，或者URL，甚至服务名称作为资源名来标示资源。
在接下来的文档中，我们都会用资源来描述这个代码块。
流量控制在网络传输中是一个常用的概念，它用于调整网络包的发送数据。然而，从系统的稳定性的角度考虑，在处理请求的速度上，也有非常多的讲究。任意时间到来的请求往往是随机不可控的，而系统的处理能力是有限的。我们需要根据系统的处理能力对流量进行控制。
Sentinel 就是这样一个调配器，根据需要，把随机到来的请求调整成合适的形状。
流量控制有下面几个角度:
- 资源的调用关系，例如资源的调用链路，资源和资源之间的关系
- 运行指标，例如 QPS，线程池，系统负载等
- 控制的效果: 直接限流，冷启动，排队等等
Sentinel 的设计理念是让用户自由的选择控制的角度，灵活组合，达到想要的效果
除了流量控制以外，降低调用链路中的不稳定资源，也是 Sentinel 的使命之一。由于调用的关系复杂性，如果调用链路中的某个资源出现了不稳定，最终会导致请求发生堆积。这个问题和 Hystrix 里面描述的问题是一样的。
Sentinel和Hystrix的原则是一致的: 当调用链路中某个资源出现不稳定，例如，表现为timeout，异常比例升高的时候，则对这个不稳定的资源的调用进行限制，并让请求快速失败，而不让这个不稳定的资源影响到其它的资源，最终产生雪崩的效果。
然而在限制的手段中，Sentinel和Hystrix采取了完全不一样的方法:
Hystrix通过线程池的方式，来对依赖(在我们的概念中对应资源)进行了隔离。这样做的好处是，资源和资源之间做到了最彻底的隔离；缺点则是除了增加了线程切换的成本，还需要预先给各个资源做线程池大小的分配。
Sentinel是对这个问题，采取了两种手段:
-
通过并发线程数对进行限制 和资源池隔离的方法不同，Sentinel通过限制资源并发线程的数量，来减少不稳定资源对其它资源的影响。这个不但没有线程切换的损耗，也不需要用户去预先分配线程池的大小。当某个资源出现不稳定的情况下，例如相应时间变长，对资源的直接影响就是会造成线程数的逐步堆积，当线程数在特定资源上堆积到一定的数量之后，对该资源的新的请求就会被拒绝，直到堆积的线程完成任务，则开始接收请求。
-
通过响应时间对资源进行降级 除了对并发线程数进行控制以外,Sentinel还可以通过相应时间来快速的降级不稳定的资源。当依赖的资源出现相应时间过长的之后，所有对该资源的访问都会被直接拒绝，直到指定的时间窗口之后重新恢复。
Sentinel同时还在系统的维度提供保护。防止雪崩，是系统防护中重要的一环。当系统负载较高的时候，如果还持续让请求进入，最后导致系统崩溃，无法相应；在集群环境下，网络负载均衡会把本应这台机器承载的流量转发到其它的机器上去；如果这个时候其它的机器也处在一个边缘状态的时候，这个增加的流量就会导致这台机器也崩溃；就这样，最后导致整个集群不可用。
Sentinel对于这种维度，也提供了保护措施。让系统的入口流量和系统的负载达到一个平衡，保证系统在能力范围之内处理最多的请求。
- 对主流框架提供适配或者显示的API,来对需要保护的代码块进行实时统计，调用链路分析
- 根据预设的规则，结合上面的统计信息，来对流量进行控制，同时，Sentinel也提供开放的接口，让用户方便的定义，改变规则
- Sentinel提供实时的监控系统，可以让用户最快的了解目前系统的状态
相关联接: