Sentinel

Spring Cloud Alibaba sentinel:https://sca.aliyun.com/zh-cn/docs/2022.0.0.0/user-guide/sentinel/overview


限流降级

在微服务系统中,一个对外的业务功能可能会涉及很长的服务调用链路。当其中某个服务出现异常,如果没有服务调用保护 机制可能会造成该服务调用链路上大量相关服务直接或间接调用的服务器仍然持续不断发起请求,最终导致相关的所有服务资源耗尽产生异常发生雪崩效应。限流和降级分别作为在流量控制服务保护 方面的两个重要手段,可以有效地应对此类问题。
限流

针对服务提供者的策略,用于控制对特定服务接口或服务实例的访问量。其目的在于保护服务提供者免受过大请求流量的影响,确保服务稳定性。
降级

针对服务消费者的应对策略,在服务出现异常或限流时,通过对服务调用进行降级处理,确保消费者端能够在异常情况下正常工作。降级的目的在于转变为弱依赖状态,使系统能够在服务不可用时提供基本的功能或数据。
限流关注于保护服务提供者,控制请求流量;
而降级则关注于服务消费者,确保在服务不可用或异常情况下提供基本的功能

流控规则(抛出 FlowException)

资源名:一般是我们的请求路径;

针对来源:来自于哪个应用,default默认全部来源;

阈值类型:QPS或线程数;单机阈值:单个节点的QPS或线程数阈值;

是否集群:被请求的服务是否集群部署;

流控模式:

  • 直接,直接对该资源进行控制;
  • 关联,关联某一个资源 ,被关联的资源 达到阈值,则限制当前资源的访问;
  • 链路,记录指定链路上的流量;(/入口资源/.../终点资源)入口终点匹配就控制;

流控效果:

  • 快速失败 ,直接限制;
  • Warm Up,根据coldFactor(默认3)的值,从 阈值/coldFactor,经过预热的时长,才达到设置的QPS阈值,比如设置QPS阈值为100,那么100/3 =33,用33作为最初的阈值,然后在预热时长到达100后再开始限流;
  • 排队等待,在QPS阈值到达后,新的请求就等待,直到超时,可以适用于突发流量的请求;

由于sentinel starter依赖默认情况下就会为所有的HTTP服务提供限流埋点,所有的HTTP接口都能获得Sentinel保护。

Sentinel默认会将Controller方法做context整合,导致链路模式的流控失效,解决办法:配置spring.cloud.sentinel.web-context-unify=false

降级规则(抛出 DegradeException)

  • 慢调用比例RT: 在统计时长内,达到最小请求数,接口响应时间大于最大RT,慢调用比例达到比例阈值时,接下来熔断时长内自动开启熔断。
  • 异常比例:在统计时长内,达到最小请求数且异常比例达到比例阈值时,接下来的熔断时长内自动开启熔断。
  • 异常数:在统计时长内,达到最小请求数且达到异常数量时,接下来的熔断时长内自动开启熔断。

热点规则(抛出 ParamFlowException)

热点参数限流会统计传入参数中的热点参数,并根据配置的限流阈值与模式,对包含热点参数的资源调用进行限流,热点参数限流可以看做是一种特殊的流量控制,仅对包含热点参数的资源调用生效;

系统规则(抛出 SystemBlockException)

  • Load,Load自适应(仅对Linux/Unix-like机器生效):系统的load1作为启发指标,进行自适应系统保护,当系统load1超过设定的启发值,且系统当前的并发线程数超过估算的系统容量时才会触发系统保护,系统容量由系统的maxQps * minRt估算得出,设定参考值一般是 CPU cores * 2.5;
  • 平均 RT:当单台机器上所有入口流量的平均RT达到阈值即触发系统保护;
  • 并发线程数:当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护;
  • 入口 QPS:当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护;
  • CPU usage:当系统 CPU 使用率超过阈值即触发系统保护;

授权规则(抛出 AuthorityException)

  • 白名单:只允许名单内的应用访问
  • 黑名单:不允许名单内的应用访问

Dashboard 通信原理

微服务暴露给Sentinel Dashboard的API接口列表:http://localhost:8719/api

配置饥饿加载:spring.cloud.sentinel.eager=true

规则持久化

  • 原始模式:默认模式,该模式下规则不持久化;
  • Pull模式:

    如上图所示:sentinel dashboard推送规则给微服务,微服务将规则更新到内存,同时将规则更新到本地文件,实现持久化;
  • Push模式:将规则存储在nacos配置中心,微服务从nacos配置中心获取规则,这种方式有更好的实时性和一致性保证;但是当我们在sentinel dashboard控制台更新规则,nacos里面的规则并不能得到更新,需要我们自己修改SentinelDashboard源码;
相关推荐
Wang's Blog2 天前
Redis: Sentinel工作原理和故障迁移流程
redis·sentinel
小笨猪-2 天前
Redis-哨兵
数据库·redis·分布式·缓存·sentinel
天下蒂一厨2 天前
sentinel微服务部署
java·微服务·架构·sentinel
中间件XL3 天前
sentinel原理源码分析系列(一)-总述
sentinel·限流·熔断·分布式流控·集群流控
后台技术汇4 天前
深刻理解Redis集群(下):Redis 哨兵(Sentinel)模式
数据库·redis·缓存·bootstrap·sentinel
学地理的小胖砸4 天前
【简介Sentinel-1】
信息可视化·sentinel·遥感·地理信息·遥感影像数据源
弥琉撒到我5 天前
微服务sentinel解析部署使用全流程
spring cloud·微服务·架构·sentinel
GIS工具-gistools20216 天前
使用SNAP工具处理Sentinel-1数据应注意磁盘和内存问题
sentinel·snap
中间件XL7 天前
sentinel原理源码分析系列(二)-动态规则和transport
sentinel·限流熔断·源码原理分析
中间件XL7 天前
sentinel原理源码分析系列(三)-启动和初始化
sentinel·限流熔断·原理源码分析