微服务保护-流控效果


个人名片:

博主:酒徒ᝰ.
个人简介:沉醉在酒中,借着一股酒劲,去拼搏一个未来。
本篇励志:三人行,必有我师焉。

本项目基于B站黑马程序员Java《SpringCloud微服务技术栈》,SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式

【SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式,系统详解springcloud微服务技术栈课程|黑马程序员Java微服务】 点击观看

目录

二、流量控制

雪崩问题虽然有四种方案,但是限流是避免服务因突发的流量而发生故障,是对微服务雪崩问题的预防。我们先学习这种模式。

4. 流控效果

在流控的高级选项中,还有一个流控效果选项:

流控效果是指请求达到流控阈值时应该采取的措施,包括三种:

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

阈值一般是一个微服务能承担的最大QPS,但是一个服务刚刚启动时,一切资源尚未初始化(冷启动),如果直接将QPS跑到最大值,可能导致服务瞬间宕机。
warm up也叫预热模式,是应对服务冷启动的一种方案。请求阈值初始值是 maxThreshold / coldFactor,持续指定时长后,逐渐提高到maxThreshold值。而coldFactor的默认值是3.

案例

需求:给/order/{orderId}这个资源设置限流,最大QPS为10,利用warm up效果,预热时长为5秒

1)配置流控规则:

2)Jmeter测试

选择《流控效果,warm up》:
刚刚启动时,大部分请求失败,成功的只有3个,说明QPS被限定在3,随着时间推移,成功比例越来越高:

刚刚启动,大部分请求失败

一段时间后,成功的请求数目增多

最后请求全部成功

到Sentinel控制台查看实时监控:

  1. 排队等待

当请求超过QPS阈值时,快速失败和warm up 会拒绝新的请求并抛出异常。
而排队等待则是让所有请求进入一个队列中,然后按照阈值允许的时间间隔依次执行。后来的请求必须等待前面执行完成,如果请求预期的等待时间超出最大时长,则会被拒绝。

如果使用队列模式做流控,所有进入的请求都要排队,以固定的间隔执行,QPS会变的很平滑。

平滑的QPS曲线,对于服务器来说是更友好的。

案例

需求:给/order/{orderId}这个资源设置限流,最大QPS为10,利用排队的流控效果,超时时长设置为5s

1)添加流控规则

2)Jmeter测试

选择《流控效果,队列》:
QPS为15,已经超过了我们设定的10。

如果是之前的 快速失败、warmup模式,超出的请求应该会直接报错。

但是我们看看队列模式的运行结果:

全部都通过了。

再去sentinel查看实时监控的QPS曲线:

QPS非常平滑,一致保持在10,但是超出的请求没有被拒绝,而是放入队列。因此响应时间(等待时间)会越来越长。

当队列满了以后,才会有部分请求失败:

总结

流控效果有哪些?

  • 快速失败:QPS超过阈值时,拒绝新的请求
  • warm up: QPS超过阈值时,拒绝新的请求;QPS阈值是逐渐提升的,可以避免冷启动时高并发导致服务宕机。
  • 排队等待:请求会进入队列,按照阈值允许的时间间隔依次执行请求;如果请求预期等待时长大于超时时间,直接拒绝
相关推荐
JohnYan2 分钟前
模板+数据的文档生成技术方案设计和实现
javascript·后端·架构
Da_秀16 分钟前
软件工程中耦合度
开发语言·后端·架构·软件工程
用户21960094442851 小时前
利用布隆过滤器设计亿级用户视频浏览历史过滤系统:方案详解与内存预估
架构
Kookoos2 小时前
ABP VNext + Tye:本地微服务编排与调试
微服务·云原生·架构·tye
秋千码途3 小时前
小架构step系列06:编译配置
架构
打好高远球4 小时前
如何用AI破解相亲信息不对称
架构
泊浮目5 小时前
未来数据库硬件-网络篇
数据库·架构·云计算
鹏程十八少5 小时前
8.Android 设计模式 适配器模式 在商业项目中的落地
架构
不骞5 小时前
5.solidity的数据结构
架构
星辰大海的精灵5 小时前
使用Docker和Kubernetes部署机器学习模型
人工智能·后端·架构