java限流中间件,阿里巴巴宣布开源限流降级中间件——Sentinel

近日，阿里巴巴中间件团队宣布开源Sentinel，并发布了首个社区版本。GitHub地址为：https://github.com/alibaba/Sentinel 。

关于Sentinel，阿里巴巴给出的描述比较简单：

A lightweight flow-control library providing high-available protection and monitoring (高可用防护的流量管理框架)。

Sentinel是什么？

随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。说的简单一点，Sentinel是一个对资源调用的控制组件，主要涵盖限流、降级、负载保护等功能模块。

Sentinel于2012年诞生，第一个版本的主要功能为入口流量控制。在之后的6年里，Sentinel 在阿里巴巴集团内部迅速发展，成为基础技术模块，覆盖了所有的核心场景。Sentinel 也因此积累了大量的流量归整场景以及生产实践。

如今，阿里巴巴决定把Sentinel开源，可以说是对开源社区的一个重大贡献。

在开源的同时，阿里巴巴还宣布把 Sentinel 的适配器捐给了Dubbo，进一步完善了 Dubbo 生态。

在复杂的生产环境下可能部署着成千上万的 Dubbo 服务实例，流量持续不断地进入，服务之间进行相互调用。但是分布式系统中可能会因流量激增、系统负载过高、网络延迟等一系列问题，导致某些服务不可用，如果不进行相应的控制可能导致级联故障，影响服务的可用性，因此如何对流量进行合理的控制，成为保障服务稳定性的关键。随着Sentinel的开源，对于使用Dubbo构建微服务的企业和开发团队来说是一大福音。

Sentinel 的特征

丰富的应用场景： Sentinel承接了阿里巴巴近10年的双十一大促流量的核心场景，例如秒杀，即突发流量控制在系统容量可以承受的范围；消息削峰填谷；实时熔断下游不可用应用，等等。

完备的监控功能： Sentinel同时提供最实时的监控功能，您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。

简单易用的扩展点： Sentinel提供简单易用的扩展点，您可以通过实现扩展点，快速的定制逻辑。例如定制规则管理，适配数据源等。

Sentinel分为两个部分:

服务端基于Spring Boot开发，打包后可以直接运行，不需要额外安装Tomcat等应用容器。

Java客户端不依赖任何框架，能够运行于所有Java运行时环境，同时对Spring/Spring Boot环境也有较好的支持。 服务端基于Spring Boot和Spring Cloud开发，打包后可以直接运行，不需要额外安装Tomcat等应用容器。

Sentinel 的功能

限流

当我们设计了一个函数，准备上线，这时候这个函数会消耗一些资源，处理上限是1秒服务3000个QPS，但如果实际情况遇到高于3000的QPS该如何解决呢？Sentinel提供了两种流量统计方式，一种是统计并发线程数，另外一种则是统计 QPS，当并发线程数超出某个设定的阈值，新的请求会被立即拒绝，当QPS超出某个设定的阈值，系统可以通过直接拒绝、冷启动、匀速器三种方式来应对，从而起流量控制的作用。

降级

接触过Spring Cloud、Service Mesh的同学，都知道熔断降级的概念。服务之间会有相互依赖关系，例如服务A做到了1秒上万个QPS，但这时候服务B并无法满足1秒上万个QPS，那么如何保证服务A在高频调用服务B时，服务B仍能正常工作呢？一种比较常见的情况是，服务A调用服务B时，服务B因无法满足高频调用出现响应时间过长的情况，导致服务A也出现响应过长的情况，进而产生连锁反应影响整个依赖链上的所有应用，这时候就需要熔断和降级的方法。Sentinel通过并发线程数进行限制和响应时间对资源进行降级两种手段来对服务进行熔断或降级。

塑形

通常我们遇到的流量具有随机性、不规则、不受控的特点，但系统的处理能力往往是有限的，我们需要根据系统的处理能力对流量进行塑形，即规则化，从而根据我们的需要来处理流量。Sentinel通过资源的调用关系、运行指标、控制的效果三个维度来对流量进行控制，开发者可以自行灵活组合，从而达到理想的效果。

负载保护

平时系统运行都没问题，但遇到大促的时候，发现机器的load非常高，这时候对系统的负载保护就显得非常重要，以防止雪崩。Sentinel 提供了对应的保护机制，让系统的入口流量和系统的负载达到一个平衡，保证系统在能力范围之内处理最多的请求。需要注意的是，Sentinel在系统负载保护方面的判断机制是根据系统能够处理的请求，和允许进来的请求，来做平衡，而不是根据一个间接的指标(系统load)来做限流。因为我们最终追求的目标是在系统不被拖垮的情况下，提高系统的吞吐率，而不是load一定要到低于某个阈值。