文章目录
微服务中的雪崩现象
首先,我们介绍一下微服务中雪崩现象:因为微服务中服务是互相调用的,错综复杂,当一个服务D出现问题时,那么调用D的服务请求就会失败,当请求累积到一定的量时,请求D的服务也会出问题------>(因为我们内置的tomcat连接数是有限制的,如果一直请求那个失败的服务,当请求达到一定的数量),服务A也会炸掉,从而引起整个链路服务不可用;
解决办法:
1. 超时处理
我们可以设置超时时间,超过了就会返回错误信息,释放tomcat资源
劣势:起到了缓解雪崩问题,当服务请求的时间比超时时间短,假设1s内多个请求,而你超时时间是1s,那么还是会出现雪崩
2. 舱壁模式
将每个业务隔离开(有一个线程池),限定每个业务能够使用的线程数,就算这个服务挂了,也就损失这一部分的线程,从而避免了损失整个tomcat资源------>也就是线程隔离
3. 熔断降级
根据异常请求的比例,比如说你异常请求达到了1/2,超过了这个阈值就会熔断该业务,拒绝一切请求访问该业务
4.流量控制
首先我们了解一下QPS------>每秒能够处理的请求数;流量控制------>限制服务访问的QPS,避免服务因为流量突然增大而挂掉;
它是一种预防的功能,给大量请求进行限流,以一定数量请求进行访问
Sentinel
1.介绍
首先我们来说一下信号量隔离和线程池隔离之间的区别:
信号量隔离:用的还是tomcat池子,只是我们每一个业务都被限定了能够用多少个线程去访问,当请求数超过这个限定的数量时,就会拒绝访问了------>也就是说它会限制每个业务能使用的线程数量
好处
:不用创建线程池,节省资源,轻量级;
坏处
:隔离性较差,相当于吃大锅饭,每个规定了盛多少饭;
线程池隔离:就跟我们上面的舱壁模式一样,每个业务分配一个线程池,线程池里面限定了一定的线程数,起到了隔离作用,当服务挂了也就浪费这个池子
好处
:隔离性好,方便控制,可以异步调用,毕竟每个服务都有线程池,我们请求给到线程池中处理,用户就可以干自己的事情了;
坏处
:浪费了资源;
控制台:
Sentinel
支持开箱即用,那些第三方配置都可以直接用,比如:查看监控,配置规则等等
熔断降级策略:
除了根据失败的请求比例来判断是否熔断,是否拒绝其他的请求请求该业务之外;还可以根据请求服务的时间来进行熔断降级------>因为请求服务时间可能太长了,拖垮我们的服务,我们进行熔断;
限流:
可以让突发的流量平稳运行------>进行一种流量控制,支持慢启动和匀速排队模式
2.使用操作
文件目录cmd打开小黑窗口然后运行代码
java
java -jar sentinel-dashboard-1.8.x.jar //启动sentinel
修改配置(启动有效)
:
java
java -jar sentinel-dashboard-1.8.x.jar -Dserver.port=8090//修改端口配置
然后我们后台启动服务,Sentinel进行监控
yaml
cloud:
nacos:
discovery:
server-addr: localhost:8848 # nacos服务地址
cluster-name: Hangzhou # 实例集群
ephemeral: false # 非临时实例
sentinel:
transport:
dashboard: localhost:8080 #sentinel控制台版本
html
<!-- sentinel依赖-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
<version>0.9.0.RELEASE</version>
</dependency>
3.限流规则
点击服务资源查看流量监控,就可以弹出表单,添加流控规则
这个单机阈值就是每秒能够请求的次数,资源名就是请求的资源
当超过单机阈值,就会报错;
4.实战:流量监控
点击流控设置流量控制
针对来源
:意思就是从哪里来的,限流
QPS
:每秒请求数量
我们要模拟1s超过5次请求,可以利用jmeter
发现限流成功
可以修改响应风格,看到响应失败
5.高级选项功能的使用
# 流控模式
流控模式强调的是对哪个资源进行限流
1.关联模式
场景
:比如某个用户支付时候,需要修改订单状态,那么用户需要查询订单,查询和修改订单的操作会争抢数据库锁------>从而产生竞争;
业务需求是:有限支付和更新订单的业务,以此当修改订单业务触发阈值时,我们这里需要对查询订单业务限流;
当/write资源访问(修改订单)量触发阈值时,就会对/read资源限流,从而避免影响/write资源
那么我们的阈值就是对限流的资源(被关联的)使用;
当你访问query时发现被限流------>访问update次数过多,又因为update与query关联
2.链路模式
Sentinel默认只会标记Controller中的方法,如果要标记其他的需要@SentinelResource注解
谁优先级低就对谁的goods进行限流
阈值为 6
save是成功的
查看监控
3.总结
链路
:是对资源的来源进行一个限流
关联
:强调的是一个优先级,比如修改调用查询,触发阈值对查询限流
流控效果
流控效果强调的是对请求的处理,效果
1.预热模式
意思就是服务器一开始不会应对那么多的请求QPS,如果一下应对那么多,可能一上来就给打懵了,会有个预热------>防止一下高并发导致服务器宕机
2.排队等待模式
案例:给order/{id}限流,最大QPS为10,每s处理10个请求,利用排队的流量监控,超时时间设置为5s------>超过5s的请求直接拒绝
请求进入队列,按照阈值运行的时间间隔依次执行请求;如果请求预期等待时间>超时间就会拒绝,然后处理的请求资源放出来平稳
3.总结
各有各的好处:一个直接让你失败不让你久等,对用户体验比较好;warm up防止高并发导致的服务器宕机,相对更加安全;而排队等待的话能够使流量平稳运行,只有超过整个队列时长才会拒绝,更加综合一点;
4.热点参数限流
之前的的限流是统计访问某个资源的所有请求,判断是否超过QPS阈值,而判断是否拒绝;
而热点参数限流------>是根据参数值是否相同来判断拒绝
参数索引是第x个参数,判断含有这个参数的请求数是否超过QPS阈值
5.实战
给order/{id}进行热点参数限流
注意:热点参数限流对默认SPringMVC资源无效,只有通过@SentinelResource注解的才行
在这里插入图片描述
对我们设置@SentinelResource的控制器进行参数限流