在上文Sentinel流量防卫兵中讲到了Sentinel入门以及流控规则一小部分,而Sentinel还有以下规则:
- 熔断降级规则
- 热点参数规则
- 系统规则
- 黑白名单规则
本文要讲的是流控规则
流量控制规则
原理
监控应用流量的 QPS 或并发线程数等指标,当达到指定的阈值时对流量进行控制,以避免被瞬时的流量高峰冲垮,从而保障应用的高可用性。
QPS限流
这里我们访问一下/foo/test
接口,触发Sentinel控制台初始化,就可以看到在簇点链路
中刷新出了该接口的资源
然后我们点击+流控
添加流控规则,选择QPS,并且限流为2
在高级选项中还有流控模式和流控效果两个选择,默认为直接和快速失败,具体含义见下面解释
新增之后,在页面上快速点击几次,就会看到我们之前预设好的限流提示
流控效果
流控效果只针对于QPS的流量控制
快速失败
当QPS超过任意规则的阈值后,新的请求就会被立即拒绝,拒绝方式为抛出FlowException
。这种方式适用于对系统处理能力确切已知的情况下,比如通过压测确定了系统的准确水位时。
案例见上
Warm Up
预热/冷启动方式,当系统长期处于低水位的情况下,当流量突然增加时,直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动",让通过的流量缓慢增加,在一定时间内逐渐增加到阈值上限,给冷系统一个预热的时间,避免冷系统被压垮。
在控制台中删除到刚刚测试的快速失败
规则,新增一个Warm up
效果的规则
这里我设置的qps阈值为10,预热3秒,等效于想要达到10qps,需要预热3秒。
这里测试需要用到一些压测工具,比如我用的是jmeter,毕竟在3秒内每秒连点10下我是做不到,认为自己行的可以自己试试。
以10qps进行压测之后,可以实时监控中看到这么一张效果图
在左边的线性图中可以看到通过的qps(绿线)是在匀速上升状态,直到3秒后达到10变为平稳状态,具体的数值可以从右边的表格看到。
排队等待
排队等待即为匀速排队,该方式会严格控制请求通过的间隔时间,也即是让请求以均匀的速度通过,对应的是漏桶算法。
同样的,在控制台新增规则
排队等待的阈值最高只能配1000哦,至于为什么小伙伴就自己想啦
以12qps进行压测,查看实时监控面板
qps一直保持在10, 规则生效了
流控模式
流控模式和调用关系有关,调用关系包括调用方、被调用方;一个方法又可能会调用其它方法,形成一个调用链路的层次关系。
直接
根据调用来源进行限流,默认为default,即针对所有的来源,这里面还可以配置自定义的来源。
1.自定义来源
自定义来源需要修改我们的配置代码,更改方式如下
private void addSpringMvcInterceptor(InterceptorRegistry registry) {
SentinelWebMvcConfig config = new SentinelWebMvcConfig();
config.setBlockExceptionHandler(new MyBlockExceptionHandler());
// 区分请求方式
config.setHttpMethodSpecify(true);
// 请求来源解析
config.setOriginParser(request -> request.getHeader("User-Agent"));
registry.addInterceptor(new SentinelWebInterceptor(config)).addPathPatterns("/**");
}
在原来的配置中增加来源解析的配置,比如我这里就是获取请求头中的User-Agent
作为请求来源,你也可以根据自己的需求决定,比如获取客户端的ip
修改完毕后,重启服务,在控制台新增一个来源为test
的规则
然后在请求上加上User-Agent的header,测试
这里如果把User-Agent换成其他的,则不会被限流
2. 其他
其他的意思除了指定的来源都会被限流,看到这里的就会让人有所疑问
- 控制台增加了
other
来源的配置,之前的test
来源就不会限流了吗?
其实它的意思是这样的:除了test
来源的请求,其他来源的qps都不能超过其他这条配置,举个例子
test
来源限流的qps为2,other
来源限流的qps为1,那么此时如果是来自test2
来源的请求,qps超过1则会提示已被限流,test
来源的请求仍旧是超过2之后才会提示被限流。
在控制台增加一条其他
来源的配置
设置User-Agent
为test2
进行测试
可以看到,我这里只请求了1次就被限流了
关联
关联这个模式指的是如果一个资源被两个接口所访问,那么在一个接口超过qps阈值时,可以对另一个接口进行限流。
举个例子来说,FooService
同时被A接口和B接口所访问,由于FooService
总体能够接受的qps是恒定的,如果A接口qps过高,那么B接口的就会受到影响,如果我们想要B接口优先,此时我们就可以配置一条当B接口超过qps阈值时,就把A接口限流。
听起来是不是特别别扭😂, 如果这俩接口有思考能力,我自行脑补出了以下场景:
B接口:我超速了,警察,快把A接口逮捕了,它影响到我超速了。
A接口:???
在代码里面新增一个foo/test2
接口,重启服务
在控制台增加配置
以上配置表示:当/foo/test
接口达到qps为10的阈值时,就对/foo/test2
进行限流
测试方式:使用jmeter对/foo/test
接口进行压测,然后再请求/foo/test2
看看是否被限流了
假装已经开始对/foo/test
接口进行压测了,请求/foo/test2
可以看到,这里随便请求了一下就返回了限流提示
链路
链路模式和关联模式有点像,但是不再是我影响你这种关系了。而指的是如果一个资源被两个接口所访问,那么我们可以指定只对其中某个接口进行限流。
还是那个例子,FooService
同时被A接口和B接口所访问,此时如果想对UserService
作qps为10的限流,之前的方式就是直接配置一个FooService
qps阈值为10的规则,这样A,B两个接口都会被限制访问,但是如果我只想对A接口的访问进行限流,B接口的不管,那么就需要使用链路模式了。
但是但是,在目前最新的版本(1.8.2)里,这个规则不生效!
并发线程数
概念
不同于qps,并发线程数限定的是某个资源的线程数并发上线,用于保护业务线程池不被慢调用耗尽。
前段时间我的同事就刚好遇上了这样的问题:
某个接口因为一个bug,线程被阻塞了, 导致所有打到这个接口的请求全部陷入阻塞状态。我们知道tomcat的总线程数是有限的,出现这个问题之后的一小会,这个服务的所有线程都阻塞在这个接口上了,tomcat线程池直接耗尽,所有接口502
如果当时该接口的并发数存在一个阈值,那这个bug所涉及的范围就可以控制在很小的范围内了。
演示
新增一个接口,用于模拟线程并发情况
public String test3() throws InterruptedException {
// 线程停顿1秒,
TimeUnit.SECONDS.sleep(1);
return "ok";
}
重启服务,访问/foo/test3
接口触发初始化
在控制台添加配置
开启jmeter进行压测该接口,然后在其他地方访问一下(为了好观察)
规则生效了。
其他的流控模式与qps方式相同,这里就不演示了
小结
本文介绍了Sentinel的流控规则,其中根据场景分为QPS
限流以及并发线程数
限流。
这两个限流策略的共同点为:可以对来源进行针对限流,支持直接
,关联
,链路
三种流控模式。
而QPS
限流还包含了三种流控效果: 快速失败、预热、排队等待。
至于是否集群
那个选项小伙伴就当没看到哈,我搞不定这个,我认怂
实在想研究,官方文档在此:https://github.com/alibaba/Se...
本文案例代码:https://gitee.com/lzj960515/m...
追更,想要了解更多精彩内容,欢迎关注公众号:程序员阿鉴
个人博客空间:https://zijiancode.cn
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。