SpringCloud 从入门到精通 16---Sentinel 流控
上节中,我们已经搭建了sentinel
的web
管理界面,并且cloud-sentinel-service-8010
已经被sentinel
监控了起来,接下来,我们通过几个简单的例子,来了解下sentinel
常见的限流方式
阈值流控
QPS 限流
顾名思义,QPS 限流
对于接口的访问进行限制,当访问的频率高于我们限制的频率之后,对接口进行限流,现在我们有两个接口/testA
和/testB
,正常访问的情况下,两个接口都可以正常的返回数据,接下来,我们对接口/testA
进行 QPS限流
,当访问频次超过1
时,进行限流
我们在簇点链路
下,点击列表视图
,然后选中/testA
的流控
,这里我们直接针对/testA
接口进行阈值类型
为 QQPSQ 的限流,单机阈值
设置为1
,流控模式
和流控效果
均保持默认
这样,我们就创建了一个针对/testA
接口的QPS限流
,当QPS
大于1
的话,就会快速失败
接下来,尝试访问http://localhost:8010/testA
结果正常,然后,快速刷新界面,使得对于接口/testA
的QPS
大于1
,就会出现如下的信息
当 QPS
大于1
的时候,就会被我们设置的QPS 限流
进行限流,并返回对应的限流信息
线程限流
线程限流也就是限制当前接口处理的线程数,我们新增一个接口/testC
接口/testC
中,使线程进行5S
的休眠,已保证在5S
内,我们可以让另一个客户端进行请求,从而触发限流效果.首先给接口/testC
增加线程限流
此时流控规则如下图
这时,先打开浏览器访问http://localhost:8010/testC,在浏览器加载的过程中也就是 5S 内,打开新的窗口访问http://localhost:8010/testC即可触发线程限流,由于浏览器缓存的原因,测试此项存在问题,所以我采用postman
来测试
正常请求结果
触发限流后的结果
流控模式
关联流控
举例来讲,当我们访问/testA
接口的时候,/testA
接口依赖于/testC
接口的逻辑,那么假如/testC
接口触发了限流的策略,也就是/testC
无法提供业务服务的时候,与之关联的/testA
接口也同样会被限流.
我们针对/testA
新建一个流控规则
这里/testA
的流控模式采用关联
模式,关联资源为/testC
,也就是当/testC
触发了限流规则后,/testA
也同样会由于关联了/testC
从而触发限流
我们先访问http://localhost:8010/testC,触发5S
的线程等待,在此期间访问http://localhost:8010/testA,查看结果
当/testC
整处于业务处理中的时候
/testA
将会被限流
等到/testC
业务处理完毕之后,/testA
的响应进入正常状态
链路流控
在各个微服务中,微服务间的调用错综复杂,比如/testA
调用了/testC
,/testD
调用了/testC
,/testE
调用了/testA
同时/testA
又调用了/testC
(/testE
间接调用了/testC
),假如我想针对所有对于/testC
的直接/间接调用进行流控,那么就需要采用链路流控
.
首先删除刚才新增的对于/testC
接口的流控规则,然后新建一个流控规则
这里流控模式选择链路
,入口资源为接口/testC
所在的资源下
这样,当我们无论直接/间接调用/testC
,都会触发此限流.大家可以创建一个新的服务cloud-sentinel-service-8011
,采用openFeign
进行进行微服务的调用
我这里通过8011
端口的/testD
接口访问/testC
,在5S
内,如果重复访问了/testD
,那么就会触发限流规则,接口/testD
返回信息如下
再看控制台输出,其实就是触发了限流
流控效果
快速失败
顾名思义,当触发了流控规则之后,直接返回限流信息给客户端,这也是我们之前一直采用的模式,这里就不再进行详细示例了
预热
预热的目的,就是给系统一个缓冲的时间,防止突发流量/冷启动时造成系统崩溃.官方描述如下
当系统长期处于低水位的情况下,当流量突然增加时,直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动",让通过的流量缓慢增加,在一定时间内逐渐增加到阈值上限,给冷系统一个预热的时间,避免冷系统被压垮。
拿QPS限流
来讲,我们可以对初始的QPS
进行限流,随着时间的增长(给定的预热时间),让QPS
达到正常的水平,接下来对/testA
接口进行预热
上面的规则,表示当系统启动后,/testA
接口的初始QPS
为10 / 3 = 3
(冷启动因子固定为 3),随着时间的增长,10S
后,QPS
的阈值就变成了 10
,这里我们可以通过快速多次访问http://localhost:8010/testA查看结果,会发现刚开始可能会有
但是 10S
过后,快速访问http://localhost:8010/testA都不再会出现限流信息了,因为此时QPS 限流
的阈值已经变成了 10
排队等待
字面上很容易理解,当过来多个请求后,不再直接进行限流,而是采用排队的形式,依次处理请求,客户端可以等待结果返回,也可以重新发起新的请求,这种流控主要是削峰填谷.需要注意的是,此流控只针对QPS限流
有用
我们针对/testA
新建一个流控规则,限制QPS
阈值为1
,超时时间为60S
这里我们使用jmeter
模拟 20 个线程,同时发起请求访问/testA
可见,线程都在17:21:31
进行了创建,按时结果数据是每秒返回一个,也就是我们限流策略中设置的每秒处理1
个请求,其他的请求都进行排队处理
版权声明: 本文为 InfoQ 作者【Felix】的原创文章。
原文链接:【http://xie.infoq.cn/article/df6aa68d6e857ec638d48e57e】。文章转载请联系作者。
评论