享学课堂特邀作者：老顾
转载请声明出处！

前言

之前介绍了Sentinel基本工作原理，以及Sentinel的监控，接下来老顾来注重介绍一下Sentinel的流控管理。

注：之前部署了Sentinel Dashboard在192.168.5.153服务器上

nohup java -jar sentinel-dashboard-1.6.3.jar &

整合Sentinel

首先我们创建一个spring boot项目，引入依赖

我们采用了最新版本boot 2.1.x 和 cloud的Greenwich.SR2，以及alibaba的2.1.0.RELEASE

我们只要在项目中引入spring-cloud-starter-alibaba-sentinel就可以了。这样就能获得限流熔断功能

扫描二维码关注公众号，回复： 9523135 查看本文章

配置

下面我们只需要在项目应用中配置一下dashboard服务器地址

spring.cloud.sentinel.transport.dashboard：配置Sentinel控制台的ip和端口

请求路径

我们再创建一个请求控制器，模拟请求接口

启动

启动后，请求接口http://localhost/test-b，http://localhost/test-a；查看sentinel控制台

表示应用整合Sentinel成功了。下面我们就介绍怎么进行流控设置

流控设置

在控制台的“簇点链路”菜单里面，就能看到请求接口（也叫端点）的层次关系，看到一些指标（通过QPS，拒绝QPS，线程数，平均RT，分钟通过，分钟拒绝），操作一栏有个【流控】按钮

资源名：默认的是请求路径，当然不一定是路径，只要是唯一的名称就行。

针对来源：针对调用同一个资源时，Sentinel是能够区分不同调用者，为不同的调用者设置不一样的流控规则；如：app-a设置QPS类型的流控，app-b设置线程数类型的流控。默认default，表示不区分调用者。

阈值类型：

 QPS：当调用这个api的时，QPS达到单机阈值时，就会限流

线程数：当调用这个api的时，线程数达到单机阈值时，就会限流

是否集群：这个以后再介绍

流控模式

直接模式

接着上面的流控设置，Sentinel的流控模式代表的流控的方式，默认【直接】，还有关联，链路。

Sentinel的流控效果：默认【快速失败】，还有WarmUp，排队等待。

Sentinel默认的流控处理就是【直接->快速失败】，我们做个案例：

我们设置一下/test-b接口的流控，QPS单机阀值为1，代表每秒请求不能超出1，要不然就做流控处理，处理方式直接调用失败。

我们调用/test-b，慢一点请求，正常返回；快速请求几次，超过阀值

接口返回了Blocked by Sentinel (flow limiting)，代表被限流了。

关联模式

关联是什么意思？

当关联的资源达到阀值，就限流自己

我们先来测试一下，我们现在有两个接口/test-a，/test-b；现在我们修改一下之前的流控规格，设置一个关联

设置了关联资源为/test-a，上图设置的效果就是当关联资源/test-a的qps阀值超过1时，就限流/test-b接口（是不是感觉很霸道，关联资源达到阀值，是本资源接口被限流了）。

我们来验证一下，这里老顾用了PostMan工具来调用/test-a，每隔300ms循环调用。这样就保证关联资源/test-a肯定超过了阀值。

我们再来请求/test-b，发现被限流了

这种关联模式有什么应用场景呢？

我们举个例子，订单服务中会有2个重要的接口，一个是读取订单信息接口，一个是写入订单信息接口。

在高并发业务场景中，两个接口都会占用资源，如果读取接口访问过大，就会影响写入接口的性能。业务中如果我们希望写入订单比较重要，要优先考虑写入订单接口。那就可以利用关联模式；

在关联资源上面设置写入接口，资源名设置读取接口就行了；这样就起到了优先写入，一旦写入请求多，就限制读的请求。

关联模式的核心就是保护关联资源的。

链路模式

只记录链路入口的流量

上面是解释，有点不是太清楚，我们来看个案例，我们改造一下代码

上面增加了一个服务，方法用@SentinelResource进行注解

@SentinelResource以后会解释，大家可以理解就是一个资源名

让/test-a和/test-b都调用这个服务；那我们就可以利用链路模式设置限制哪个入口的流量了

这样设置就起到了，请求接口/test-a会调用getOrder，会进行流量控制；但/test-b则不会。

这个和上面的针对来源很类似，但有区别的就是：

针对来源是微服务级别的，链路模式的入口资源是针对方法接口的。

流量效果

快速失败

就是流量达到阀值，直接返回报异常

WarmUp

也叫预热，根据codeFactor（默认3）的值，从（阀值/codeFactor）为初始阀值，经过预热时长，才到达设置的QPS的阀值

上面是什么意思呢？我们来举个案例，阀值为100，预热时长设置10秒。

代表的含义就是，系统初始化的阀值为 100/3 ，即阀值为33；然后过了10秒，阀值才恢复到100

这个预热的应用场景，如：秒杀系统在开启的瞬间，会有很多流量上来，很有可能把系统打死，预热方式就是把为了保护系统，可慢慢的把流量放进来，慢慢的把阀值增长到设置的阀值。

排队等待

从字面上面就能够猜到，匀速排队，让请求以均匀的速度通过，阀值类型必须设成QPS，否则无效。

上图的设置含义：/test-b的每秒1次请求，超过的话就排队等待，等待的超时时间为10000毫秒。

我们再次利用Postman工具，循环请求/test-b，我们看看控制台的日志输出

我们可以发现test-b的每隔1秒执行一次，这么多的请求没有被拒绝，而且进入的排队。

排队的应用场景是什么呢？

比如有时候系统在某一个时刻会出现大流量，之后流量就恢复稳定，可以采用这种排队模式，大流量来时可以让流量请求先排队，等恢复了在慢慢进行处理

总结

Sentinel的流控方式还是比较实用的，功能比较强大，也是阿里通过自己的实战总结提炼的。小伙伴们要去实战体验一下哦，谢谢！！！

对本文内容感兴趣的朋友, 欢迎大家在留言区进行交流讨论!

EnjoyEDU

发布了137 篇原创文章 · 获赞 26 · 访问量 1万+

私信关注

阿里解决方案SpringCloud Alibaba；详解Sentinel流控管理

前言