微服务-Sentinel

目录

背景

Sentinel使用

Sentinel控制台

Sentinel控制规则

Sentinel整合OpenFeign


背景

在微服务项目架构中,存在多个服务相互调用场景,在某些情况下某个微服务不可用时,上游调用者若一直等待,会产生资源的消耗,极端情况下会影响整个应用,如下图:

在高并发的场景下,由于A服务不可用,导致B调用A一直等待,迟迟不能释放资源,进而导致B服务不可用,进而导致CD服务不可用,最终整个项目服务不可用,产生了服务崩塌。Sentinel可以解决上述问题,它在服务流量控制、熔断等方面有很好的解决方案。

Sentinel常用的使用场景如下:

1、秒杀场景:限流防止瞬时流量冲击。

2、服务熔断与降级:当服务不可用时,快速失败,避免级联故障。

3、系统保护:预防由于高负载引发的系统崩溃。

Sentinel使用

Sentinel控制台

Sentinel 控制台是一个独立应用,用于可视化的监控和管理,它可以直接运行可执行的jar,项目使用的jar版本是:sentinel-dashboard-1.8.8,直接运行:java -jar sentinel-dashboard-1.8.8.jar

运行后访问:http://localhost:8080/#/login sentinel/sentinel登录

Sentinel控制规则

Sentinel控制规则很多,包括:流控规则、熔断规则、热点规则、系统规则、授权规则,本文重点介绍流控规则、熔断规则。项目配置步骤如下:

1、项目添加对Sentinel的依赖

2、项目配置Sentinel

3、服务接口编写及简单测试

简单写了一个后台数据库查询接口,查询id=1的用户信息

4、Sentinel控制台配置流控规则

对上述服务接口,配置了每秒请求数不能超过1的流控规则,超过后,直接返回调用失败,浏览器快速请求后,会出现如下效果(流控规则已生效):

流控规则配置说明如下:

资源名:资源名是需要限流的唯一标识,可以是方法名、API请求路径等。通过资源名,Sentinel能够对流量进行管理与控制。

针对来源:针对特定的调用方进行限流。例如,服务A调用服务B时,可以针对服务A的调用进行限流。默认为 default,表示不区分调用来源。

QPS(每秒请求数):如果某个资源的每秒请求数超过设定的阈值,则会触发限流。

线程数:当访问该资源的并发线程数达到设定的阈值时,触发限流。

是否集群:如果不需要集群模式限流,默认选择"不需要集群"。否则,可以开启集群限流。

流控模式-直接限流:一旦达到阈值,直接限流当前的请求。

流控模式-关联限流:当关联的其他资源达到限流条件时,限流当前的资源。比如/resourceA达到阈值时,/resourceB也被限流。

流控模式-链路限流:对入口资源进行链路限流,限制从指定入口进入的资源访问。当链路上的访问量达到阈值时,限制链路上的流量,常用于链路保护。

流控效果-快速失败:当达到限流条件时,直接抛出异常,返回失败结果。

流控效果-Warm Up(预热):在一段时间内,逐步增加允许通过的流量,直至达到设定的 QPS 阈值。适合应用在高峰期流量突增的场景。

流控效果-排队等待:请求不会立即失败,而是进入排队状态,匀速通过。适用于平滑处理请求的场景,类似于"漏斗效应"。阈值类型必须为 QPS,否则无效。

如果需要手工处理限流或者降级的逻辑,不直接演示生硬的【Blocked by Sentinel (flow limiting)】信息,可以通过**@SentinelResource** 解决,参考代码如下:

blockHandler:处理限流或降级时的逻辑,方法名必须是 public,返回类型与原方法一致,且参数类型需要与原方法匹配,方法最后要加上 BlockException 参数。可以处理流控、熔断等情况触发的 BlockException。

5、Sentinel控制台配置熔断规则

Sentinel 的熔断规则主要分为三种策略,慢调用比例、异常比例和异常数,这些策略用于保护服务免于过载或连续的失败。

慢调用比例 :该策略会根据请求响应的时间来判断是否进行熔断,适合用于防止因某些请求响应过慢而拖垮整个系统。

最大RT(Response Time):表示系统中允许的最大响应时间,如果一个请求的响应时间超过这个设定值,就会被判定为慢调用

最小请求数目:在统计周期内,只有请求数超过设定的最小请求数,才会触发熔断逻辑。

熔断条件:当单位时间内内的慢调用比例超过设定的阈值时,触发熔断,进入熔断状态。

恢复机制:在熔断时长过后,进入半开状态,如果后续请求正常则关闭熔断器,如果再发生慢调用则继续熔断。

异常比例:该策略会根据异常的比例来判断是否进行熔断,适合用于当请求的失败率突然增加时,自动进行保护。

最小请求数目:同样需要单位时间内的请求数达到设定的最小值,才会计算异常比例。

熔断条件:当单位时间内内的异常比例大于设定的阈值时,触发熔断,进入熔断状态。

恢复机制:在熔断时长过后,进入半开状态,如果后续请求成功,则关闭熔断器,否则继续熔断。

异常数:该策略根据单位时间内的异常数量来判断是否熔断,适合用于系统中发生大量异常时的保护机制。

下方以异常数熔断规则举例:

后台模拟异常

异常数熔断规则配置:

在10秒时间内,最小请求大于5,接口出现10次异常后,接口服务熔断不可用

jemter多线程请求测试:

启动jemter任务,然后在浏览器请求:http://localhost:8088/blogUser/simulateException 显示接口服务已熔断。

当关闭jemter测试任务后,再次请求 http://localhost:8088/blogUser/simulateException 后,服务接口恢复。

Sentinel整合OpenFeign

Sentinel整合OpenFeign步骤如下:

1、增加配置信息

2、对feign接口增加服务降级的逻辑

3、测试调用

在blog-content服务正常可用时,调用http://localhost:8088/blogUser/simulate 时,系统返回后台数据信息;当关闭blog-content服务时,控制台显示【BlogContent 服务降级】

相关推荐
蝎子莱莱爱打怪6 天前
XZLL-IM干货系列 04|Netty 长连接实战:Pipeline 怎么排、心跳怎么跳、连接怎么管
后端·微服务·面试
SamDeepThinking7 天前
Java微服务练习方式
java·后端·微服务
米丘10 天前
微前端之 Web Components 完全指南
微服务·html
霸道流氓气质13 天前
领域驱动设计(DDD)在 Spring Boot 微服务中的实践指南
运维·spring boot·微服务
霸道流氓气质13 天前
Spring Boot 微服务性能优化完全指南
spring boot·微服务·性能优化
地瓜伯伯13 天前
从MESI缓存一致性协议讲透synchronized的底层
java·spring boot·spring·spring cloud·微服务·springcloud
Devin~Y13 天前
大厂 Java 面试实录:从音视频内容社区到 AI RAG 的全链路技术设计
java·spring boot·redis·spring cloud·微服务·kafka·音视频
递归尽头是星辰13 天前
AI 访问数据仓库:从直连到微服务化
数据仓库·人工智能·微服务·dataagent·ai数据治理
就改了14 天前
Windows 环境 SkyWalking 完整实操教程
windows·微服务·skywalking
至乐活着14 天前
Docker Compose多服务编排实战:从零搭建Node.js+MySQL+Redis全栈应用
docker·微服务·devops·容器编排·compose