Sentinel之流控规则

在上文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-Agenttest2进行测试

可以看到,我这里只请求了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的限流,之前的方式就是直接配置一个FooServiceqps阈值为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/Sentinel/wiki/%E9%9B%86%E7%BE%A4%E6%B5%81%E6%8E%A7

本文案例代码:https://gitee.com/lzj960515/my-micro-service-demo

评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×