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

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

前言

之前介绍了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就可以了。这样就能获得限流熔断功能

配置

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

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

请求路径

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

启动

启动后,请求接口http://localhost/test-bhttp://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的流控方式还是比较实用的,功能比较强大,也是阿里通过自己的实战总结提炼的。小伙伴们要去实战体验一下哦,谢谢!!!

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

往期推荐:
第一篇:SpringCloud Alibaba之Nacos
第二篇:SpringCloud Alibaba之Nacos配置中心
第三篇:SpringCloud Alibaba之Nacos多环境多项目管理
第四篇:SpringCloud Alibaba之Nacos共享配置、灰度配置
第五篇:SpringCloud Alibaba之Nacos集群、持久化
第六篇:SpringCloud Alibaba之Sentinel工作原理

推荐阅读更多精彩内容