这篇文章介绍一下阿里开源的流量防卫兵Sentinel，一款非常优秀的开源项目，经过近10年的双十一的考验，非常成熟的一款产品。

sentinel顾名思义：卫兵；在Redis中叫做哨兵，用于监控主从切换，但是在微服务中叫做流量防卫兵。

Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

• 丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
• 完备的实时监控：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。
• 广泛的开源生态：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Apache Dubbo、gRPC、Quarkus 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。同时 Sentinel 提供 Java/Go/C++ 等多语言的原生实现。
• 完善的 SPI 扩展机制：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。

• 核心库（Java 客户端）不依赖任何框架/库，能够运行于所有 Java 运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。
• 控制台（Dashboard）基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等应用容器。

流控模式总共分为三种，对应元素strategy，分别如下：

• 直接拒绝：接口达到限流条件时，直接限流
• 关联：当关联的资源达到阈值时，就限流自己
• 链路：只记录指定链路上的流量（指定资源从入口资源进来的流量，如果达到阈值，就可以限流）

下面来详细介绍下以上三种流控模式。

顾名思义：默认的流量控制方式，当QPS超过任意规则的阈值后，新的请求就会被立即拒绝，拒绝方式为抛出FlowException。上面的几个例子都是配置了直接拒绝这个模式，这里不再详细介绍。

典型的使用场景：一个是支付接口，一个是下单接口，此时一旦支付接口达到了阈值，那么订单接口就应该被限流，不然这边还在下单，消费者等待或者直接被拒绝支付将会极大的影响用户体验。

简而言之：A关联B，一旦B达到阈值，则A被限流

演示一下效果，创建以下两个接口：

此时的流控规则配置如下图：

注意：关联之后，这里设置的限流规则是对被关联资源，也就是/sentinel/pay这个资源，但是真正被限流则是/sentinel/order。

如何演示效果呢？很简单，只需要不断的请求/sentinel/pay达到阈值，然后在请求/sentinel/order。

流控分为两种统计类型，分别是QPS，并发线程数，很多人不太明白这两种统计类型有什么区别？

举个栗子：陈某带了一个亿去银行存钱，但是银行大门保安要查健康码，每秒最多只能同时进入4个人，并且银行中只有两个工作人员工作，如下图：

此时的QPS含义：从保安到银行这一段，即是保安放行进入银行的人数。

此时并发线程数的含义：银行只有两个工作人员在工作，那么最多只能同时处理两个任务，这里并发线程数的阈值就是2。

8、降级规则如何配置？

熔断降级在日常生活中也是比较常见的，场景如下：

• 股票市场的熔断，当价格触发到了熔点之后，会暂停交易一段时间，或者交易可以继续进行，但是报价会限制在一定的范围。
• 电压过高导致保险丝触发熔断保护

在大型的分布式系统中，一个请求的依赖如下图：

如果这个时候，某个服务出现一些异常，比如：

• 服务提供者不可用(硬件故障、程序bug、网络故障、用户请求量较大)
• 服务调用者使用同步调用，产生大量的等待线程占用系统资源，一旦线程资源被耗尽，调用者提供的服务也会变成不可用状态

那么将会导致整个服务不可用，用古话来讲就是：千里之堤毁于蚁穴。

所谓编程源于生活，架构师们根据生活的经验设计出了服务的熔断降级策略，很好的解决了这类问题。

熔断降级规则对应sentinel控制台的降级规则这一栏，如下图：

熔断降级涉及到的几个属性如下表：

在控台为这个接口设置平均响应时间为200毫秒，时间窗口为1秒，大致意思：平均的响应时间大于200毫秒之后，在接下来的1秒时间内将会直接熔断，如下图：

使用Jmeter开启10个线程循环跑，然后在浏览器中访问这个接口，返回结果如下图：

为什么呢？由于的接口中休眠了3秒，平均响应时间肯定大于200毫秒，因此直接被熔断了。

注意：这里熔断后直接返回默认的信息，后面会介绍如何定制熔断返回信息。

9、热点参数如何限流？

顾名思义：热点就是经常访问的数据，很多时候肯定是希望统计某个访问频次Top K数据并对其进行限流。

比如秒杀系统中的商品ID，对于热点商品那一瞬间的并发量是非常可怕的，因此必须要对其进行限流。

Sentinel 利用 LRU 策略统计最近最常访问的热点参数，结合令牌桶算法来进行参数级别的流控。

注意：热点参数限流只针对QPS。

系统规则的配置比较简单，这里以入口QPS为例进行演示，为了演示真实情况，清掉所有的限流规则，添加系统规则，如下图：

可以看到已经被限流了，不仅是这个接口，所有接口都会生效。

注意：系统规则中的入口QPS这个规则不建议配置，一旦配置上了可能导致整个服务不可用。

11、如何自定义限流返回的异常信息？

很显然默认的异常信息并不能满足我们的业务需求，因此我们需要根据前后端规则制定自己的异常返回信息。

这里将会用到一个注解@SentinelResource，这个在上文也是提到过，这个注解中有两个关于限流兜底方法的属性，如下：

• blockHandler： 对应处理 BlockException 的函数名称。blockHandler 函数访问范围需要是 public，返回类型需要与原方法相匹配，参数类型需要和原方法相匹配并且最后加一个额外的参数，类型为

下面定义一个创建订单的接口，手动制造一个1/0异常，代码如下：

上述接口并没有进行异常降级处理，因此调用该接口直接返回了异常信息，非常不友好，如下图：

我们可以使用fallback指定异常降级的兜底方法，此时业务方法改造如下：

使用fallbackClass属性指定单独一个类处理异常降级，降低了代码的耦合度，fallback属性指定了降级兜底的方法，代码如下：

此时再次访问接口，虽然有异常，但是返回的确实降级兜底方法中的返回信息，如下图：

到了这里基本满足了异常降级的处理需求，但是仍然有个疑问：能否只用一个方法处理全部的异常？

答案是：能，必须能，此时就要用到defaultFallback这个属性了，指定默认的降级兜底方法，此时的业务方法变成如下代码：

defaultFallback属性指定了默认的降级兜底方法，这个方法代码如下：

好了，异常降级处理到这儿已经介绍完了，但是仍然有一个问题：若 blockHandler 和 fallback 都进行了配置，那么哪个会生效？

此时不配置任何规则，直接访问接口，可以看到这里直接进入了异常降级处理，如下图：

我们对createOrder这个资源配置降级规则：60秒内如果出现2个以上的异常直接限流，如下图：

此时我们再次访问这个接口，可以看到前两次直接进入了fallback指定的方法中（并未达到限流的异常数阈值），两次之后就被限流了，进入了blockHandler方法中，效果如下图：

13、sentinel的黑白名单如何设置？

顾名思义，黑名单就是拉黑呗，拉黑就是不能访问了呗，sentinel能够针对请求来源进行是否放行，若配置白名单则只有请求来源位于白名单内时才可通过；若配置黑名单则请求来源位于黑名单时不通过，其余的请求通过。

sentinel控制台对应得规则配置如下图：

这里有个问题：请求来源是什么，怎么获取？

Sentinel提供了一个接口RequestOriginParser，我们可以实现这个接口根据自己业务的规则解析出请求来源名称。

下面我以IP作为区分请求来源，代码如下：

15、限流规则如何推送到Nacos进行持久化？

sentinel默认的持久化只能从nacos推送到sentinel控制台，但是实际生产中肯定是双向修改都能推送的，这个如何解决呢？

其实sentinel官方文档就有说到解决方法，不过需要自己修改sentinel控制台的源码来实现。

这个还是比较复杂的，sentinel只帮我们实现了流控规则的demo，其他的还是要自己修改，这点不太人性化....

17、网关限流如何配置？

这一块内容在后续介绍到网关的时候会详细讲，这里就不再细说了，有想要了解的可以看官方文档。

最近面试BAT，整理一份面试资料《Java面试BATJ通关手册》，覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。
获取方式：点“在看”，关注公众号并回复 Java 领取，更多内容陆续奉上。

文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*)