文明农村建设网站,新沂网站开发,网页设计代码模板网站,外包小程序开发注意事项大家好#xff0c;今天我们要来学习阿里巴巴开源的流量控制和熔断降级框架 – Sentinel 。
1、雪崩问题及解决方案
首选我们来了解一下雪崩问题及其解决方案#xff0c;我们学习这个微服务保护#xff0c;其实就是为了去应对类似于雪崩问题这样的服务故障。
1.1 什么是雪…大家好今天我们要来学习阿里巴巴开源的流量控制和熔断降级框架 – Sentinel 。
1、雪崩问题及解决方案
首选我们来了解一下雪崩问题及其解决方案我们学习这个微服务保护其实就是为了去应对类似于雪崩问题这样的服务故障。
1.1 什么是雪崩问题
那什么是雪崩问题呢我们来看一下这个场景。 上面是我们微服务里面的部分服务我们知道微服务里面的业务往会比较复杂一个业务它可能会依赖多个其他的微服务。
比如在我们的服务 A 中有这样的一个业务它依赖于服务B。 而服务A 里面可能又有可能其他的业务比如说它依赖于服务D。 那现在假设说服务D出现了故障
那么我们在服务A内部依赖于服务D的这个业务请求还能正常访问吗
显然是不可能的因为它访问这个服务D就必然要等待服务D的结果,那因为服务D出现了故障那必然不能返回结果结果就是它会阻塞在这里。
那这就导致了服务A内部的这个业务是不是也会阻塞在这里阻塞就会导致它不会释放服务器的连接。
当然了这个时候服务A内部依赖的于服务b或c的业务还不受影响但是你想想看有第一个依赖服务D这样的业务请求那也会有第二个和第三个。
假以时日服务A内部依赖于服务D的这样的业务请求越来越多而它们都不会释放连接那后面是不是一定会把服务A所有的连接给占用了 那最后的结果就是tomcat资源耗尽因为tomcat 资源是有限的嘛此时再有新的请求进来哪怕我不是访问服务D的我依赖服务D的我是不是也进不来了
那这下是不是可以认为服务A也出现故障 那这不就是因为一个服务导致了什么
导致了依赖于它的服务也出现了故障。那我们就要知道在微服务里这种调用关系可不止这么简单而且会非常复杂 那如果因为服务A因为服务D被拖垮了那肯定也会有其他的服务也依赖于服务D最终是不是也会拖垮
假如说再有其他服务它们依赖于服务A那么这些依赖于服务A的这些业务是不是也会拖垮 到最后出现故障的服务越来越多那么整个微服务群都不可用了这不就是雪崩了吗
所以什么是雪崩问题 微服务调用链路中的某个服务故障引起整个链路中的所有微服务都不可用这就是雪崩。 这个非常恐怖的呀所以在微服务里边雪崩问题是一个必须要解决的问题
那么用什么来解决呢
1.2 雪崩问题解决方案
解决雪崩问题的常见方案有四种
1.2.1 超时处理 设定超时时间请求超过一定时间没有响应就返回错误信息不会无休止等待。 比方说现在有服务B和服务C还有服务A服务A中有一些业务依赖于服务B还有一些业务依赖于服务C。 随着服务C出现故障服务A内部依赖于服务C的所有业务都会阻塞日积月累服务A也就故障了。
那么超时处理会这么办呢它会在调用业务时加上一个超时的时间。例如一秒。 也就是说当服务A它的业务依赖于服务C时它最多等一秒。如果服务C故障以后这个等待超过了一秒
不好意思它会立即结束这个请求不再返回给用户一个提示信息。
就跟你说不好意思请求失败了。那这个请求是不是就释放了就不会导致一直占用Tomcat资源是不是一定程度上缓解这个雪崩问题
但为什么是缓解雪崩问题而不是100%解决了雪崩问题
我们想想它只是等待了一秒以后把资源释放那也就是说最长等待时间是不是一秒?我们可以理解成一秒钟释放一个那如果你释放请求的速度是一秒释放一个。
但现在假设说新的请求速度是每秒钟两个你释放的速度没有进入的速度快是不是终有一天服务A的资源也有可能会被耗尽所以你设置超时时间也只是起到了一个缓解作用并没有从根本上解决这个问题。
1.2.2 舱壁模式 限定每个业务使用的线程数避免耗尽整个Tomcat的资源因此也叫线程隔离。 舱壁模式是来自于我们现实生活中船舱的一个设计。 一些大型的轮船它都会把船体利用这种隔板分割成独立的小的空间隔板就相当于舱壁。
那么因为这些空间之间相互是隔离的现在假设说船体的某个部位撞上了冰山漏水了最多也是吧这个部分船舱给它填满水。
因为是隔离的所以其他的船舱是不收影响的那这样这个船是不是还可以承受啊它可以承受一定的船舱进水嘛其实也就提高了我们整整艘船的一个容灾能力。
那么这种模式延续到我们程序设计里面它是怎么来做的呢 还是刚刚的案例服务A可以看成整艘船然而我们该怎么避免整个Tomcat挂掉呢
我们就把Tomcat里面的资源也就是线程划分成一个一个的独立的线程池。
比方说给业务1分配10个线程池业务2分配10个。
那么现在业务1进来之后它依赖于服务B。 那它最多使用10个线程访问业务2它依赖于服务C。 它也最多使用10个线程。
那现在服务C出现故障了那这个业务就会阻塞占用我们的线程但是它最多占用10个。
那这个时候它能够使用的Tomcat 资源是不是有限呢是不是就把这个故障隔离到了10个线程内了
对此这个模式也叫线程隔离模式它其实啊就避免了整个Tomcat资源耗尽的这种情况。
当然这个模式它确实解决了超时处理方案所遗留的问题只不过资源可能会有一些浪费。
比如说服务C宕机挂了接下来你还是会尝试区请求这个服务C明知道它已经挂掉了你还要尝试访问还要暂用我10个线程是不是一种浪费
1.2.3 熔断降级 由断路器统计业务执行的异常比例如果超出阈值会熔断该业务拦截访问该业务的一切请求。 这种模式它里面会有一个断路器断路器它可以去统计业务执行的异常比例。
也就是说你这个业务里面出现故障的请求和正常的请求之间的一个比例是什么样子的如果超出了阈值则会熔断这个业务什么是熔断就是拦截访问该业务的一切请求。 我们还是用图来表示一下这也是我们之前说的出现雪崩的一个情况就是服务A里面所有的业务度卡在这里了然后把资源耗尽。
那熔断怎么去解决这个问题呢 它会去统计服务A里面的业务比方说再服务A里面有一个业务是来访问服务D的然后第一次是正常的
结果后面两次都出现了故障那这个时候我们的断路器就会统计了你这个异常比例这一看三个请求两个故障是不是异常比列达到了60%
那假设说我们的阈值是50%那是不是超出了阈值那么这个时候就会出现熔断。
一旦出现熔断那么再服务A内部还想访问服务D这个业务也就是依赖于服务D的这个业务就无法再去访问服务D了。
只要是看到你是请求服务D的就跟说“滚”资源快速释放那怎么可能会把它们耗尽呢这不就解决了资源耗尽问题而且既然知道立刻服务D是故障的我压根不让你去访问它是不是就不存在这种资源浪费的情况了
1.2.4 流量控制 限制业务访问的QPS避免服务因流量的突增而故障。 什么意思呢比如说这里有一个受保护的服务它能承受的最大QPS是2也就是每秒钟最多处理两个请求但是现在有无数的请求涌过来那你说他能承受得了吗那肯定是不行的呀这不被打成筛子了。
而一旦这个服务出现了故障那依赖于这个服务的其他服务是不是也都跟着会出现故障那岂不是也会出现雪崩状况所以我们一定要尽可能的避免服务因为流量过高而引起故障。
那我们该怎么办呢这就用到了我们的 Sentinel 了。 现在呢假如真的有无数个请求融入过来而Sentinel它可以按照这个服务所能够承受的一个频率去释放请求这个时候我们的微服务不久能从容应对这些请求了吗 那就避免了它出现故障如果它不出现故障那就不会把故障进行传递了就不会出现雪崩问题了。
所以你看是不是把雪崩问题扼杀在了摇篮当中。因此流量控制是预防雪崩控制。
2、服务保护技术对比
好的各位在上面我们已经学习了雪崩问题以及常见的解决方案而要实现这些解决方案最好的方式肯定是使用现有的框架。
所以现在我们就要去对比一下实现服务保护的常见框架及其差别这里呢我们主要是对比一下Sentinel 和 Hystrix。
因为Hystrix是Spring Cloud 刚刚流行的这几年推荐大家使用的。它是由Netflix 公司出品的只不过随着Netflix公司宣布停止对Hystrix的升级和维护现在就逐渐没落了。
人们也在尝试去寻找一个新的方案而在这个时候阿里巴巴就开源了一个项目叫Sentinel 并且已经成为SpringCloudAlibaba 当中的一个服务保护组件现在已经被广泛的应用在国内的互联网公司。 看上面的表格我们主要关注红色的部分即可。
2.1 隔离策略
Sentinel 和 Hystrix 都支持 信号量来隔离而Hystrix还支持线程池隔离但默认情况下都是用线程池来隔离的。 这两种隔离有什么差别呢 线程池大家可能会比较熟悉一点因为我们说雪崩问题解决方案舱壁模式举的就是线程池隔离的例子。
我们讲了在一个业务请求进入TomCat以后它会给每一个被隔离的业务创建一个独立的 线程池每有一个被隔离的业务都会有一个独立的线程池那自然也会有独立线程。
因此它会比TomCat直接处理的这种方式会多出很多很多线程那么可以认为线程池数量会成倍增长那这种方式虽然隔离性比较好但是随着线程数量增长我们知道CPU它会带来一些额外的一个 上下文切换的消耗所以整个服务的性能是会有一定的损失的。 而信号量隔离采用了的方案是什么呢 当业务请求进入 TomCat 以后我不会给你创建独立的线程池而是去做一个统计统计当前业务已经使用多少个线程了然后我给你限制一下说你只能使用10个当你已经使用10个线程以后再有新的业务需要去获取线程时我就会阻止你了。
也就是说它会限制每个业务能使用的线程数量池子也就是那一个池子TomCat默认的线程池不去创建新线程也不创建新的线程池。
这样就减少了线程的创建在隔离的基础上并没有影响性能。但是它这样的隔离性相比于线程池来讲会差一点因为它毕竟是在同一个池子里面只不过现在一个大锅饭每个人拿个碗单独盛了。
这是两种隔离方式的差别。
2.2 熔断降级
熔断降级其实就是其实就是统计异常的比例然后触发了异常比例的阈值我就给你熔断只不过在Sentinel里它可以除了统计异常请求的比例它还可以统计慢调用的比例。
何为慢调用
就是一个业务它大多数情况下耗时都比较久那它这个业务可能就会有问题可能会拖慢我整个服务有可能把我拖垮了所以我可以把它熔断了。
但是在Hystrix 里默认都是基于这种异常的方式进行熔断降级的所以Sentinel里面的这种熔断策略会更丰富一些。
2.3 限流
限流就是我们讲的流量控制在Sentinel里它支持基于QPS,还有调用关系的这种限流甚至还可以针对热点的参数去做限流。这限流的方式多种多样。
而Hystrix里面它没有专门的一个限流的控制它其实就是基于这个线程池的你的线程池设置成10那你最多不就是10了嘛是基于这种方式来限流的。所以这种限流的能力相对比较弱一点。
2.4 流量整形
流量整形就是让突发流量变成稳定的匀速的流量。那怎么做到的呢
它可以支持慢启动也就是预热模式还有匀速排队等等。
所以这种方式让波动的请求变成匀速的请求那我微服务处理起来就会更加的轻松。
在Hystrix里是不支持这样的功能的。
2.5 控制台
控制台就是我们所谓的UI界面给你弄一个可视化的界面方便你去查看操作。
在Sentinel 里它有开箱即用的控制台在里面你不仅仅可以去监控微服务查看微服务运行状态还可以去配置我们的降级规则配完就立即动态生效了。
而在Hystrix 里它的控制台只支持服务状态的功能不具备动态修改规则这样的功能。
3、认识Sentinel 和 安装
接下来我们就去认识一下Sentinel 并且去安装一下它的控制台。
3.1.初识Sentinel
首先我们都知道Sentinel是阿里巴巴开源的一款微服务流量控制组件。
官网地址https://sentinelguard.io/zh-cn/index.html 然后下面就是介绍了Sentinel 的一些特征 •丰富的应用场景Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景例如秒杀即突发流量控制在系统容量可以承受的范围、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。 •完备的实时监控Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据甚至 500 台以下规模的集群的汇总运行情况。 •广泛的开源生态Sentinel 提供开箱即用的与其它开源框架/库的整合模块例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。 •完善的 SPI 扩展点Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。 3.2 安装Sentinel
1、下载
sentinel官方提供了UI控制台方便我们对系统做限流设置。大家可以在[Releases · alibaba/Sentinel (github.com)](https://github.com/alibaba/Sentinel/releases)下载。 2、运行
将jar包放到任意非中文目录打开终端执行命令 java -jar sentinel-dashboard-1.8.6.jar如果要修改Sentinel的默认端口、账户、密码可以通过下列配置
配置项默认值说明server.port8080服务端口sentinel.dashboard.auth.usernamesentinel默认用户名sentinel.dashboard.auth.passwordsentinel默认密码
例如修改端口
java -Dserver.port8090 -jar sentinel-dashboard-1.8.6.jar3.3 访问
访问http://localhost:8080页面就可以看到sentinel的控制台了账号密码都是 sentinel 4、微服务整合Sentinel
要使用Sentinel肯定要结合微服务这里我们使用以前用过的SpringCloud工程。有需要的小伙伴可以下载这个工程
springCloud案例演示: springcloud学习演示 (gitee.com)
项目结构如下 然后大家记得启动一下Nacos 然后启动这三个项目 现在我们的微服务已经准备好了那下一步就可以去整合Sentinel了。
我们基于order-service去讲解。
4.1 引入依赖
!--sentinel--
dependencygroupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-sentinel/artifactId
/dependency4.2 配置控制台
修改application.yaml文件添加下面内容 弄完之后重启服务 4.3 访问order-service的任意端点(接口)
打开浏览器访问http://localhost:8088/order/101这样才能触发sentinel的监控。
然后再访问sentinel的控制台查看效果 5、限流规则
接下来我们就要去学习Sentinel的用法去解决我们之前说到的雪崩问题。
之前我们在讲解雪崩问题的时候提到了4种解决方案而Sentinel主要是实现了其中的三种。
分别是
限流线程隔离降级熔断
5.1 快速入门
首先我们通过一个快速入门了解一下Sentinel它的限流基本用法。
我们先来了解一个概念。 簇点链路: 当请求进入微服务时首先会访问DispatcherServlet然后进入Controller、Service、Mapper这样的一个调用链就叫做簇点链路。簇点链路中被监控的每一个接口就是一个资源。 默认情况下sentinel会监控SpringMVC的每一个端点Endpoint也就是controller中的方法因此SpringMVC的每一个端点Endpoint就是调用链路中的一个资源。 例如我们刚才访问的order-service中的OrderController中的端点/order/{orderId} 流控、熔断等都是针对簇点链路中的资源来设置的因此我们可以点击对应资源后面的按钮来设置规则
流控流量控制降级降级熔断热点热点参数限流是限流的一种授权请求的权限控制
那也就是说我们将来可以去给资源去做降级等等各种各样的操作。
那具体怎么去做呢
比如我们点击资源/order/{orderId}后面的流控按钮就可以弹出表单。 这个表单有几个需要你去填写的东西。
第一是资源名称因为你点的是 /order/{orderId} 这个资源所以默认资源名称就是它也就说这个流控规则是针对这个请求的。
第二个是针对来源就是说从哪访问过来的请求需要被限流default 就是一切进来的请求都要被限流那一般情况下限流我们不需要去制定来源就是所有请求都要限流。
第三个是阈值类型一般都选择QPS, QPS就是指并发量嘛也就是说每秒钟的请求数量而后面指定的单击阈值就是指这个QPS的上限。1就代表即每秒只允许1次请求超出的请求会被拦截并报错。至于将来这个单击阈值设置多少呢就设置你的这个接口它最大的一个并发量就行了。怎么知道自己的这个服务的并发量是多少呢做压力测试。
5.1.1演示
接下来我们给 /order/{orderId}这个资源设置流控规则QPS不能超过 5然后利用Jemeter进行压力测试。 使用Jemeter。 我们可以看到请求发出了但是每次通过只有五个另外的就失败了。
我们还可以看看Sentinel控制台。 5.2 流控模式
通过快速入门我们已经学习Sentinel 的基本用法我们接下来就来看一下限流里面的高级配置。
在添加限流规则时点击高级选项可以选择三种流控模式 直接统计当前资源的请求触发阈值时对当前资源直接限流也是默认的模式关联统计与当前资源相关的另一个资源触发阈值时对当前资源限流也就是说 我现在有A和B两个资源a触发了阈值但我却对B做限流。链路统计从指定链路访问到本资源的请求触发阈值时对指定链路限流不是对当前资源做限流例如现在我有ABC三个资源A和B都要访问资源C但是我在统计资源C的时候只统计从A过来的请求B的我不管。
直接模式我们就不做过多介绍我们主要来看关联模式和链路模式它们在什么情况下选择去用呢?
5.2.1 关联模式 使用场景我们有一个用户支付的业务用户支付完了要修改订单状态同时另外一边可能还会有用户要去查询订单那大家都知道查询和修改的动作他们会去争抢数据库的锁那因此会产生竞争关系。写的操作过于频繁自然会影响读的操作反之亦然。 但是我们知道在业务里面支付业务更新订单这个业务肯定优先级更高我们肯定要用户优先支付呀那查询业优先级相对较低所以我们希望当更新订单的这个业务触发阈值时说明它有更高的要求那我们就要对查询业务做限流防止它影响到我们的修改业务。 案例
接下来我们通过一个案例来演示一下关联模式如何使用。
我们先在代码中增加两个接口。 重启服务查看sentinel控制台的簇点链路 重启之后所有东西都消失了我们得重新访问一下接口。
localhost:8082/order/query
localhost:8082/order/update 现在我们得query 和 update 已经出现在Sentinel 控制台中了现在我们的需求是当update的QPS 达到 5时对Query 做限流处理。
请问我要给谁添加流控规则
我们要记住给谁限流我们就要给谁添加规则。
那我们就要给query 增加流控规则。 我们接下来就使用Jmeter 去做一下测试。 Jmeter 正常请求没有没有限流我们看看query。 确实被限流了。
总结一下
满足以下两个条件我们可以使用关联模式。
两个有竞争关系的资源一个优先级较高一个优先级较低
5.2.2 链路模式
接下里我们来了解链路模式。这里我们直接通过一个例子来学习
例如我有两条请求链路 /test1 -- /common /test2 -- /common
一个是从test1 来访问 common一个是test2访问common。、
而我们下面有这么一个配置。 配置的资源名称是common,而流控的方式呢是链路方式。入口资源是test2。
那入口资源这个配置的意思是什么呢
就是我在做限流统计时只统计从test2进入common的请求那test1进来的我就不管了。
所以这种统计是对请求来源的一种统计。
问题来了什么情况下我们要用到这种模式呢
我有一个查询订单和创建订单的业务而这俩业务都需要查询商品。那这不就形成了两个链路了吗
从查询订单到查商品和创建订单到查商品。而我们知道查询订单业务的并发往往会比较高但是查询商品这个业务肯定会有自己的并发上限如果查询业务的并发过高势必会影响到创建订单的业务那因此我们应该把查询业务的并发做一个限制怎么做呢 步骤 在OrderService中添加一个queryGoods方法不用实现业务 在OrderController中改造/order/query端点调用OrderService中的queryGoods方法 在OrderController中添加一个/order/save的端点调用OrderService的queryGoods方法 给queryGoods设置限流规则从/order/query进入queryGoods的方法限制QPS必须小于2 知道了步骤我们就去实现一下
首先在order-service服务中给OrderService类添加一个queryGoods方 在order-service的OrderController中修改/order/query端点的业务逻辑 然后在order-service的OrderController中修改/order/save端点模拟新增订单 默认情况下OrderService中的方法是不被Sentinel监控的需要我们自己通过注解来标记要监控的方法。
给OrderService的queryGoods方法添加SentinelResource注解 链路模式中是对不同来源的两个链路做监控。但是sentinel默认会给进入SpringMVC的所有请求设置同一个root资源会导致链路模式失效。
我们需要关闭这种对SpringMVC的资源聚合修改order-service服务的application.yml文件 重启服务访问/order/query和/order/save可以查看到sentinel的簇点链路规则中出现了新的资源 我们可以看到order/save 和 order/query 变成了两个独立的链路在这之前没有关闭context 整合的时候它俩还是属于同一个根链路下的两个子链路。
解下来我们就可以给这个 goods 去添加流控规则上面有两个我们可以随意选择一个这两个goods 其实是同一个。 这样链路规则就配置好了接下来我们就利用Jmeter 去做测试。现在我们只对query做限制 可以看到这里200个用户50秒内发完QPS为4超过了我们设定的阈值2
一个http请求是访问/order/save 一个http请求是访问/order/query 运行的结果
sava: query: 我们可以看到save不受任何影响query 都是俩个俩个失败的这就是根据来源请求做限流。
5.3 流控效果
前面我们已经学习完了流控模式接下来我们学习流控效果。什么是流控效果呢 流控效果是指请求达到流控阈值时应该采取的措施包括三种 快速失败达到阈值后新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。所以我们之前在做测试的时候会发现一旦服务触发了限流那就会得到一个异常状态码429抛出的信息就是flow limiting 就是被限流了。 warm up预热模式与快速失败相似都是对超出阈值的请求同样是拒绝并抛出异常。但它们不同的地方在于这种模式阈值会动态变化预热模式从一个较小值逐渐增加到最大阈值。 排队等待它前面的模式不一样它不会立即抛出异常而是让所有的请求按照先后次序排队执行两个请求的间隔不能小于指定时长如果大于就会被拒绝并抛出异常。 5.3.1 warm up预热模式
我们先来学习 warm up预热模式。
这个预热模式它同样会把超出阈值的请求直接拒绝并且抛出异常但特殊之处在于它的阈值不是一成不变的。这种方案是来应对服务冷启动的方案那什么是服务冷启动呢
这就像一个人你要去做一些剧烈的运动之前你肯定得先做一些拉伸的运动给你的身体做一个预热如果不做你很容器在运动中拉伤自己的肌肉。
那服务器也一样服务器它的最大QPS 能够达到 比如说是10但是它刚刚启动你立马就直接把QPS打满它可能还没有反应过来呢就被你打懵了。它挂了所以说呀我们的服务刚刚启动时不能上来就把QPS打满。
怎么办呢
在预热模式中初始的请求阈值初始值 maxThreshold最大阈值 / coldFactor冷启动因子持续指定时长后逐渐提高到maxThreshold值。而coldFactor的默认值是3。
预热模式就是为了避免冷启动那一刻避免过高并发导致故障。
例如我设置QPS的maxThreshold为10预热时间为5秒那么初始阈值就是 10 / 3 也就是3然后在5秒后逐渐增长到10. 案例
我们给/order/{orderId}这个资源设置限流最大QPS为10利用warm up效果预热时长为5秒 Jmeter测试 QPS为10. 刚刚启动时大部分请求失败成功的只有3个说明QPS被限定在3
随着时间推移成功比例越来越高 到Sentinel控制台查看实时监控 一段时间后 5.3.2 排队等待
我们之前讲的快速失败和warm up 会拒绝新的请求并抛出异常而排队等待则是让所有请求进入一个队列中然后按照阈值允许的时间间隔依次执行。
后来的请求必须等待前面执行完成如果请求预期的等待时间超出最大时长则会被拒绝。
举个栗子 QPS等于5一秒钟5个请求意味着每200ms处理一个队列中的请求那Sentinel 就会严格去执行这个时间间隔前面一个请求执行完第二个请求一定要等够200毫秒。 比如说前面的请求执行小于200毫秒不管那么多第二个一定要等够200毫秒才行。所以这个200毫秒叫预期等待时间。 那我们就可以换算一下我的前面已经有5个请求了我要等待多久1秒。这个就叫预期等待时长。 timeout 2000意味着预期等待超过2000ms的请求会被拒绝并抛出异常。 现在第1秒同时接收到10个请求但第2秒只有1个请求此时QPS的曲线这样的 如果使用队列模式做流控所有进入的请求都要排队以固定的200ms的间隔执行QPS会变的很平滑 平滑的QPS曲线对于服务器来说是更友好的。
我们接下来去实现一个案例给/order/{orderId}这个资源设置限流最大QPS为10利用排队的流控效果超时时长设置为5s。 然后我们利用Jmeter进行测试 QPS为15已经超过了我们设定的10。
如果是之前的 快速失败、warmup模式超出的请求应该会直接报错。
但是我们看看队列模式的运行结果 全部都通过了。
再去sentinel查看实时监控的QPS曲线 看后面那一段QPS中间非常平滑一致保持在10我们发的明明是15但通过的却是10那多余的请求到哪里去了是不是到队列里面等待执行去了因此你可以看到响应时间等待时间会越来越长。
当队列满了以后才会有部分请求失败。
5.4 热点参数限流
5.4.1.全局参数限流
这一章节我们来学习一个特殊的限流热点参数限流。那它特殊在哪里呢
我们前面所学习的限流在去统计资源的QPS的时候会统计进入该资源的所有请求然后判断它有没有超过QPS阈值。
而热点参数限流是分别统计参数值相同的请求判断它有没有超过阈值。什么意思
比方说我现在有一个资源是根据ID查询商品。 现在有4个请求过来了。 如果是按照原来的统计方式那我的QPS就是4而按照热点参数它会根据参数值来去判断那前三个的请求的ID都为1.而最后一个传递ID为2。 那QPS就会分开统计了ID为1的统计一下为3ID为2的统计一下为1。
配置示例
在这里比较关键的就是这三个配置第一是参数索引这里给了0代表的是当前这个资源的参数列表中的第0索引就是第一个参数。
单机阈值为5还有统计窗口时长1这两合在一起就是指一秒钟最多五个请求。
那整个配置的含义就是给hot这个资源的0号参数第一个参数做统计每1秒相同参数值的请求数不能超过5。
5.4.2.热点参数限流
刚才的配置中对查询商品这个接口的所有商品一视同仁QPS都限定为5.
而在实际开发中可能部分商品是热点商品例如秒杀商品我们希望这部分商品的QPS限制与其它商品不一样高一些。那就需要配置热点参数限流的高级选项了 结合上一个配置这里的含义是对0号的long类型参数限流每1秒相同参数的QPS不能超过5有两个例外
•如果参数值是100则每1秒允许的QPS为10
•如果参数值是101则每1秒允许的QPS为15
案例
给/order/{orderId}这个资源添加热点参数限流规则如下 默认的热点参数规则是每1秒请求量不超过2 给102这个参数设置例外每1秒请求量不超过4 给103这个参数设置例外每1秒请求量不超过10 注意事项热点参数限流对默认的SpringMVC资源无效需要利用SentinelResource注解标记资源 所以我们要做的第一件事不是来配置规则而是去修改代码添加注解。
我们先给给order-service中的OrderController中的/order/{orderId}资源添加注解。 重启一下服务。
访问该接口可以看到我们标记的hot资源出现了 这里不要点击hot后面的按钮页面有BUG
点击左侧菜单中热点规则菜单 点击新增 填写表单 点击新增打开jenkins。 包含3个http请求
普通参数QPS阈值为2 运行结果 例外项QPS阈值为4 运行结果 例外项QPS阈值为10 运行结果
