Sentinel通过限流对微服务进行掩护

目录
雪崩问题
办理雪崩问题的方法：
我们利用sentinel组件实现微服务的掩护
 一：下载sentinel
二.启动sentinel
三.访问：localhost:8080 默认的账号和密码都是sentinel
 微服务整合sentinel
一.导入sentinel依赖
二.在application.yml设置文件中编写设置sentinel控制台的地点
第三步：启动微服务项目，并访问微服务的某一个接口
Sentinel设置流控
利用jmeter工具测试接口
jmeter先容
jmeter安装
 启动
​编辑 利用
测试计划添加线程组
添加http请求行为​编辑
​编辑 添加响应结果监听器
 启动线程组
查看结果树，有一个乐成，因为设置了sentinel流控设置了一秒只能访问一次这个接口
查看聚合报告
​编辑 流控模式
直接模式
关联模式
链路模式 
总结：
流控效果 
warm up
排队等待
热门参数限流 
 1.给接口利用@SentinelResource注解，标记为资源
2.设置热门参数限流规则​编辑

---

雪崩问题

微服务调用链路中的某一个服务故障，引起整个链路中全部微服务都不可用，就会造成雪崩
举个例子：一个微服务就是一个tomcat服务器，而一个tomcat服务器只有几百个线程可用，这个A服务在访问另一个B微服务时，须要60秒才能响应，那么这个A服务的全部线程都会因为B服务的长时间不响应而壅闭，最后导致A服务不可用，进而导致调用A微服务的全部微服务都不可用，这就是雪崩问题
办理雪崩问题的方法：

1.超时处理：设置超时时间，请求超过肯定时间没有响应就直接返回错误信息，如许一来就不会无休止等待
2.舱壁模式：限定每一个微服务能使S用的线程数，从而制止耗尽整个tomcat的资源，因此也叫做线程隔离
3.熔断降级：由断路器统计业务执行的异常比例，假如超出阈值则会熔断该服务，拦截访问该业务的一切请求。就是一个微服务出现内部异常，一旦超过肯定比例，就会有一段时间其他服务都不能访问整个出现问题的微服务，过了一段时间后才实验进行访问，假如照旧不行就继续熔断
4.流量控制：限制业务访问的QPS（每秒的访问数目）,制止服务因为流量激增而故障。就是假如有几万个请求同时访问一个服务，须要把这些请求分批次少量的发送服务
我们利用sentinel组件实现微服务的掩护

 一：下载sentinel

下载地点
Release v1.8.1 · alibaba/Sentinel
下载sentinel的jar包
二.启动sentinel

java -jar sentinel-dashboard-1.8.1.jar 
三.访问：localhost:8080 默认的账号和密码都是sentinel

假如想改端口号
   java -Dserver.port=9090 -Dcsp.sentinel.dashboard.server=localhost:9090 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard-1.8.1.jar
   微服务整合sentinel

一.导入sentinel依赖

1. <!--        导入sentinel依赖-->
2.         <dependency>
3.             <groupId>com.alibaba.cloud</groupId>
4.             <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
5.         </dependency>

复制代码

这里我没有指定版本号，因为我在父工程已经导入了spring-cloud-alibaba的父工程来管理spring-cloud-alibaba的全部组件的版本号

1. <!--            SpringCloudAlibaba的父工程，管理依赖-->
2.             <dependency>
3.                 <groupId>com.alibaba.cloud</groupId>
4.                 <artifactId>spring-cloud-alibaba-dependencies</artifactId>
5.                 <version>${spring-cloud-alibaba}</version>
6.                 <type>pom</type>
7.                 <scope>import</scope>
8.             </dependency>

复制代码

二.在application.yml设置文件中编写设置sentinel控制台的地点

1. spring:
2.   cloud:
3.     sentinel:
4.       transport:
5.         dashboard: localhost:9090 #控制台地址

复制代码

第三步：启动微服务项目，并访问微服务的某一个接口

可以发现sentinel已经监控到了这个order-service微服务

簇点链路：就是项目内的调用链路，链路中被监控的每一个接口就是一个资源。默认情况下sentinel会监控SpringMVC的每一个端点(Endpoint)，一个端点就是一个接口，因此SpringMVC的每一个端点就是调用链路中的每一个资源。流控，熔断等都是针对簇点链路中的资源来设置的，因此我们可以点击背面的按钮来设置规则

Sentinel设置流控

流控设置：点击接口背面的流控按钮
选择阈值类型未QPS（每秒中的访问次数）,然后阈值设置为1
如许一来这个接口的流控为：每秒中只能访问一次

 效果
一秒内访问多次就会显示被sentinel壅闭，直接报错

利用jmeter工具测试接口

jmeter先容

JMeter是由Apache构造开发的一款基于Java的压力测试工具。它最初计划用于Web应用测试，但随着时间的推移，JMeter的功能已经扩展到了其他的测试领域。JMeter能够模拟大量用户对服务器、网络或对象进行负载测试，从而测试它们在不同压力下的性能，并进行团体性能分析。 
jmeter安装

官网下载链接Apache JMeter - Download Apache JMeter 

 启动

解压以后进入bin目录，打开jmeter.properties文件，修改语言为中文

点击jmeter.bat文件启动jemter工具 

 利用

测试计划添加线程组

在线程组中设置线程数为200，ramp-up为在多长时间内创建这200个线程，时间越短越高并发
循环次数为每个线程的执行次数 

添加http请求行为

设置请求路径和编码格式 (utf8)

 添加响应结果监听器

 启动线程组

查看结果树，有一个乐成，因为设置了sentinel流控设置了一秒只能访问一次这个接口

查看聚合报告

 流控模式

• 直接模式：统计当前资源的请求，触发阈值对当前资源直接限流，也就是默认的模式
  
• 关联模式：统计与当前资源相干的另一个资源，触发阈值时，对当前资源限流
  
• 链路模式：统计从指定链路访问到本资源的请求，触发阈值时，对指定的链路限流
  

直接模式

对这个接口每秒钟只能访问五次 

设置在2秒内创建20个线程，即一秒10个线程，盼望的结果就是每秒钟有五个线程访问这个接口乐成 
 

关联模式

 统计与当前资源相干的另一个资源，触发阈值时，对当前资源限流
利用场景：比如用户付出时须要修改订单状态，同时用户要查询订单。查询和修改会争抢数据库锁，就会产生竞争。业务需求是优先付出和更新订单的业务，因此当修改订单业务触发阈值时，须要对查询订单业务进行限流
 写资源优先，一旦写资源达到阈值，就会对读资源的操作进行限流，因为写资源优先
例子：
写两个接口，一个查询，一个更新

1. @GetMapping("query")
2.     public String query() {
3.         return "查询订单";
4.     }
5.     @GetMapping("update")
6.     public String update(){
7.         return "更新订单";
8.     }

复制代码

 设置流控规则：当/order/update 资源被访问的QPS超过5时，对/order/query资源进行限流
在/order/query的流控按钮中编写 

 在jmeter中测试，一秒创建10个线程去访问/order/update,如许一来已经超过了QPS阈值(一秒只能访问5次)，最后sentinel对/order/query进行限流

 

链路模式 

链路模式：只针对从指定链路访问到本资源的请求做统计，判断是否超过阈值。
设置示例：
例如有两条请求链路：

• /test1 --> /common
  
• /test2 --> /common
  

假如只希望限制从/test2进入到/common的请求，而限制从/test1开始的，则可以如许设置：

实战案例
需求：有查询订单和创建订单业务，两者都须要查询商品。针对从查询订单进入到查询商品的请求统计，并设置限流。
步骤：

• 在OrderService中添加一个queryGoods方法，不消实现业务
  
• 在OrderController中，改造/order/query端点，调用OrderService中的queryGoods方法
  
• 在OrderController中添加一个/order/save的端点，调用OrderService的queryGoods方法
  
• 给queryGoods设置限流规则，从/order/query进入queryGoods的方法限制QPS必须小于2
  

 注意：须要给queryGoods方法利用SentinelResourse注解，让sentinel知道这个方法也是一个资源，sentinel默认只会把利用SpringMVC注解的方法看成资源

1.   //让sentinel知道这个方法也是一个资源，因为sentinel默认只会把使用SpringMVC注解的方法当作资源
2.     @SentinelResource("goods")
3.     public void queryGoods(){
4.         System.out.println("查询商品");
5.     }

复制代码

在链路模式中，是对不同泉源的两个链路做监控。但是sentinel默认会给进入SpringMVC的全部请求设置同一个root资源，会导致链路模式失效。
我们须要关闭这种对SpringMVC的资源聚合，修改order-service服务的application.yml文件：

1. spring:
2.   cloud:
3.     sentinel:
4.       web-context-unify: false # 关闭context整合

复制代码

 给/order/query的goods资源做链路限制

 结果：
通过/order/save访问的goods资源不受限制

通过/order/query访问的goods资源每一秒只能访问2次

总结：

直接：直接当前资源进行限流
关联：假如高优先级资源 触发阈值，就对低优先级资源进行限制
链路：阈值统计时，只统计从指定资源进入当前资源的请求，是对请求泉源的限流
流控效果 

流控效果是指请求达到流控阈值时应该接纳的步伐，包括三种：

• 快速失败：达到阈值后，新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。
  
• warm up：预热模式，对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化，从一个较小值逐渐增长到最大阈值（自己规定的）。
  
• 排队等待：让全部的请求按照先后序次排队执行，两个请求的间隔不能小于指定时长
  

warm up

阈值一样寻常是一个微服务能负担的最大QPS，但是一个服务刚刚启动时，一切资源尚未初始化（冷启动），假如直接将QPS跑到最大值，可能导致服务瞬间宕机。
warm up也叫预热模式，是应对服务冷启动的一种方案。请求阈值初始值是 maxThreshold / coldFactor，连续指定时长后，逐渐提高到maxThreshold值。而coldFactor的默认值是3.
例如，我设置QPS的maxThreshold为10，预热时间为5秒，那么初始阈值就是 10 / 3 ，也就是3，然后在5秒后逐渐增长到10.

 设置流控规则：

排队等待

当请求超过QPS阈值时，快速失败和warm up 会拒绝新的请求并抛出异常。
而排队等待则是让全部请求进入一个队列中，然后按照阈值允许的时间间隔依次执行。后来的请求必须等待前面执行完成，假如请求预期的等待时间超出最大时长，则会被拒绝。
工作原理
例如：QPS = 5，意味着每200ms（阈值的时间间隔）处理一个队列中的请求；timeout = 2000，意味着预期等待时长超过2000ms的请求会被拒绝并抛出异常。
那什么叫做预期等待时长呢？
比如现在一下子来了12 个请求，因为每200ms执行一个请求，那么：

• 第6个请求的预期等待时长 = 200 * （6 - 1） = 1000ms
  
• 第12个请求的预期等待时长 = 200 * （12-1） = 2200ms
  

现在，第1秒同时吸收到10个请求，但第2秒只有1个请求，此时QPS的曲线如许的：
 

假如利用队列模式做流控，全部进入的请求都要排队，以固定的200ms的间隔执行，QPS会变的很平滑：

案例
需求：给/order/{orderId}这个资源设置限流，最大QPS为10，利用排队的流控效果，超时时长设置为5s
QPS设置为每秒处理十个请求，并设置超时时间为5s

 jmeter测试为每秒创建15个线程去请求接口，假如是之前的流控效果，那么每一秒就会有五个请求是直接失败的。而我们当前利用的是排队等待模式，这个模式会把全部请求返到一个队列中，然后按照先后顺序处理队列中的请求（设置的QPS阈值为10，即可以1s处理10个请求，那么就是100ms处理队列中一个请求），当然这个队列也是有长度限制的，假设这个长度n,那么(n-1)*100=5000,n=499,因为最大延时延时等待的时间为5000ms，以是这个队列最多只能存499个请求，超过499个就会不处理这个请求
总结：
快速失败：QPS超过阈值时，直接拒绝新的请求
warm upPS超过阈值时，也是直接拒绝新的请求 ；但是QPS的阈值时逐渐提升的，可以制止冷启动时高并发导致服务宕机
排队等待：请求会进入队列，按照阈值允许的时间间隔依次执行请求；假如请求预期等待时间大于超时时间，直接拒绝。队列的长度为 (n-1)*时间间隔=超时时间，n为长度
热门参数限流 

之前的限流是统计访问某个资源的全部请求，判断是否超过QPS阈值。而热门参数限流是分别统计参数值相同的请求，判断是否超过QPS阈值。
之前的限流是直接通过访问某一个接口资源的请求数来判断是否到达阈值的，而热门参数限流是通过同一个路径下的不同路径参数（如/order/{orderId}）来分别判断是否到达阈值 
案例需求：给/order/{orderId}这个资源添加热门参数限流，规则如下：
•默认的热门参数规则是每1秒请求量不超过2
•给102这个参数设置例外：每1秒请求量不超过4
•给103这个参数设置例外：每1秒请求量不超过10
注意事项：热门参数限流对默认的SpringMVC资源无效，须要利用@SentinelResource注解标记资源
 1.给接口利用@SentinelResource注解，标记为资源

1. //要在这个接口设置热点资源限流，需要使用@SentinelResource,不然不成功
2.     @SentinelResource("hot")
3.     @GetMapping("{orderId}")
4.     public Order queryOrderByUserId(@PathVariable("orderId") Long orderId) {
5.        System.out.println(commonName);
6.         // 根据id查询订单并返回
7.         return orderService.queryOrderById(orderId);
8.     }

复制代码

2.设置热门参数限流规则

 进行热门参数限流的资源叫hot,参数索引就是资源路径中须要进行限流的参数所在路径中的路径（从0开始），如/order/{orderId},orderId就是索引为0，单机阈值设置为2就是其他默认的参数置QPS都是2，然后选择高级选项，参数类型设置为long,因为orderId类型为Long，然后参数值为103的QPS单独设置为10，参数为102的QPS单独设置为4

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。