医院门户网站建设,做网站必须要dreamever,市场营销比较好写的论文题目,网站建设规划书实训报告文章目录 微服务中的雪崩现象解决办法#xff1a;1. 超时处理2. 舱壁模式3. 熔断降级4.流量控制 Sentinel1.介绍2.使用操作3.限流规则4.实战#xff1a;流量监控5.高级选项功能的使用1.关联模式2.链路模式3.总结 流控效果1.预热模式2.排队等待模式3.总结4.热点参数限流5.实战… 文章目录 微服务中的雪崩现象解决办法1. 超时处理2. 舱壁模式3. 熔断降级4.流量控制 Sentinel1.介绍2.使用操作3.限流规则4.实战流量监控5.高级选项功能的使用1.关联模式2.链路模式3.总结 流控效果1.预热模式2.排队等待模式3.总结4.热点参数限流5.实战 微服务中的雪崩现象
首先我们介绍一下微服务中雪崩现象因为微服务中服务是互相调用的错综复杂当一个服务D出现问题时那么调用D的服务请求就会失败当请求累积到一定的量时请求D的服务也会出问题——(因为我们内置的tomcat连接数是有限制的如果一直请求那个失败的服务当请求达到一定的数量)服务A也会炸掉从而引起整个链路服务不可用 解决办法
1. 超时处理
我们可以设置超时时间超过了就会返回错误信息释放tomcat资源
劣势起到了缓解雪崩问题当服务请求的时间比超时时间短假设1s内多个请求而你超时时间是1s那么还是会出现雪崩 2. 舱壁模式
将每个业务隔离开有一个线程池限定每个业务能够使用的线程数就算这个服务挂了也就损失这一部分的线程从而避免了损失整个tomcat资源——也就是线程隔离 3. 熔断降级
根据异常请求的比例比如说你异常请求达到了1/2超过了这个阈值就会熔断该业务拒绝一切请求访问该业务 4.流量控制
首先我们了解一下QPS——每秒能够处理的请求数流量控制——限制服务访问的QPS避免服务因为流量突然增大而挂掉
它是一种预防的功能给大量请求进行限流以一定数量请求进行访问 Sentinel
1.介绍
首先我们来说一下信号量隔离和线程池隔离之间的区别
信号量隔离用的还是tomcat池子只是我们每一个业务都被限定了能够用多少个线程去访问当请求数超过这个限定的数量时就会拒绝访问了——也就是说它会限制每个业务能使用的线程数量
好处不用创建线程池节省资源轻量级
坏处隔离性较差相当于吃大锅饭每个规定了盛多少饭
线程池隔离就跟我们上面的舱壁模式一样每个业务分配一个线程池线程池里面限定了一定的线程数起到了隔离作用当服务挂了也就浪费这个池子
好处隔离性好方便控制可以异步调用毕竟每个服务都有线程池我们请求给到线程池中处理用户就可以干自己的事情了;
坏处浪费了资源
控制台
Sentinel支持开箱即用那些第三方配置都可以直接用比如查看监控配置规则等等
熔断降级策略:
除了根据失败的请求比例来判断是否熔断是否拒绝其他的请求请求该业务之外还可以根据请求服务的时间来进行熔断降级——因为请求服务时间可能太长了拖垮我们的服务我们进行熔断
限流
可以让突发的流量平稳运行——进行一种流量控制支持慢启动和匀速排队模式 2.使用操作
文件目录cmd打开小黑窗口然后运行代码
java -jar sentinel-dashboard-1.8.x.jar //启动sentinel修改配置启动有效
java -jar sentinel-dashboard-1.8.x.jar -Dserver.port8090//修改端口配置然后我们后台启动服务Sentinel进行监控 cloud:nacos:discovery:server-addr: localhost:8848 # nacos服务地址cluster-name: Hangzhou # 实例集群ephemeral: false # 非临时实例sentinel:transport:dashboard: localhost:8080 #sentinel控制台版本!-- sentinel依赖--dependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-starter-alibaba-sentinel/artifactIdversion0.9.0.RELEASE/version/dependency3.限流规则
点击服务资源查看流量监控就可以弹出表单添加流控规则 这个单机阈值就是每秒能够请求的次数资源名就是请求的资源 当超过单机阈值就会报错 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的控制器进行参数限流
