Sentinel详解
2021-08-03 11:02:43 3 举报AI智能生成
学习Sentinel内容的一些记录，分支会比较多。
作者其他创作
大纲/内容
概念须知
响应时间RT
吞吐量TPS
并发用户数
每秒查询率QPS
是什么？
Sentinel是阿里开源的项目，提供了流量控制、熔断降级、系统负载保护等多个维度来保障服务之间的稳定性。
特征
丰富的应用场景
Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即
突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
完备的实时监控
Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机
器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。
广泛的开源生态
Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring
Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入Sentinel。
完善的SPI扩展点
Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快
速地定制逻辑。例如定制规则管理、适配动态数据源等。
丰富的生态圈
使用
控制台（Dashboard）
控制台主要负责管理推送规则、监控、集群限流分配管理、机器发现等。
核心库（Java客户端）
不依赖任何框架/库，能够运行于 Java 7 及以上的版本的运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。
核心功能
熔断保护
步骤
1.定义资源
何为资源？
资源是 Sentinel 的关键概念。它可以是 Java 应用程序中的任何内容，例如，由应用程序提供的服务，或由应用程序调用的其它应用提供的服务，RPC接口方法，甚至可以是一段代码。
如何定义资源？
方法一：把需要控制流量的代码用 Sentinel的关键代码 SphU.entry("资源名") 和 entry.exit() 包围起来即可。
方法二：使用Sentinel提供的注解@SentinelResource来定义资源。
@SentinelResource注解有哪些属性？
value
资源名称，必需项（不能为空）
entryType
entry 类型，可选项（默认为 EntryType.OUT）
blockHandler / blockHandlerClass
blockHandler 对应处理 BlockException的函数名称，可选项。
blockHandler 函数访问范围需要是 public，返回类型需要与原方法相匹配，参数类型需要和原方法相匹配并且最后加一个额外的参数，类型为 BlockException。blockHandler 函数默认需要和原方法在同一个类中。若希望使用其他类的函数，则可以指定 blockHandlerClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析。
fallback /fallbackClass
fallback 函数名称，可选项，用于在抛出异常的时候提供 fallback 处理逻辑。
fallback 函数可以针对所有类型的异常（除了exceptionsToIgnore里面排除掉的异常类型）进行处理。
fallback 函数签名和位置要求有哪些？
返回值类型必须与原函数返回值类型一致
方法参数列表需要和原函数一致，或者可以额外多一个 Throwable 类型的参数用于接收对应的异常
fallback 函数默认需要和原方法在同一个类中。若希望使用其他类的函数，则可以指定 fallbackClass为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析
defaultFallback
默认的 fallback 函数名称，可选项，通常用于通用的 fallback 逻辑（即可以用于很多服务或方法）。
默认 fallback 函数可以针对所有类型的异常（除了exceptionsToIgnore里面排除掉的异常类型）进行处理。若同时配置了 fallback 和 defaultFallback，则只有 fallback 会生效。
defaultFallback 函数签名要求有哪些？
返回值类型必须与原函数返回值类型一致
方法参数列表需要为空，或者可以额外多一个 Throwable 类型的参数用于接收对应的异常
defaultFallback 函数默认需要和原方法在同一个类中。若希望使用其他类的函数，则可以指定 fallbackClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析
exceptionsToIgnore（since 1.6.0）：用于指定哪些异常被排除掉，不会计入异常统计中，也不会进入 fallback 逻辑中，而是会原样抛出
2.定义规则
有哪些规则？
流控规则
熔断降级规则
系统规则
权限规则
热点参数规则
3.检验规则是否生效
熔断降级
解决的问题?
对调用链路中不稳定的资源进行熔断降级，是保障高可用的重要措施
规则属性？
resource
资源名，即规则的作用对象
grade
熔断策略，支持慢调用比例/异常比例/异常数策略，默认值是慢调用比例
count
慢调用比例模式下为慢调用临界 RT（超出该值计为慢调用）；异常比例/异常数模式下为对应的阈值
timeWindow
熔断时长，单位为 s
minRequestAmount
熔断触发的最小请求数，请求数小于该值时即使异常比率超出阈值也不会熔断（1.7.0 引入)，默认值是5
statIntervalMs
统计时长（单位为 ms），如 60*1000 代表分钟级（1.8.0 引入），默认值是1000ms
slowRatioThreshold
慢调用比例阈值，仅慢调用比例模式有效（1.8.0 引入）
有哪几种降级策略？
平均响应时间 (DEGRADE_GRADE_RT)
当资源的平均响应时间超过阈值（DegradeRule 中的 count，以 ms 为单位）之后，资源进入准降级状态。如果接下来 1s 内持续进入 5 个请求（即 QPS >= 5），它们的 RT 都持续超过这个阈值，那么在接下的时间窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个方法的调用都会自动地熔断（抛出 DegradeException）。
注意 Sentinel 默认统计的 RT 上限是 4900 ms，超出此阈值的都会算作 4900 ms，若需要变更此上限可以通过启动配置项 -Dcsp.sentinel.statistic.max.rt=xxx 来配置。
异常比例 (DEGRADE_GRADE_EXCEPTION_RATIO)
当资源的每秒异常总数占通过量的比值超过阈值（DegradeRule 中的 count）之后，资源进入降级状态，即在接下的时间窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个方法的调用都会自动地返回。
异常比率的阈值范围是 [0.0, 1.0]，代表 0% - 100%。
异常数 (DEGRADE_GRADE_EXCEPTION_COUNT)
当资源近 1 分钟的异常数目超过阈值之后会进行熔断。
注意由于统计时间窗口是分钟级别的，若 timeWindow 小于 60s，则结束熔断状态后仍可能再进入熔断状态。
与Hystrix的熔断对比
Hystrix常用的线程池隔离会造成线程上下切换的overhead比较大；Hystrix使用的信号量隔离对某个资源调用的并发数进行控制，效果不错，但是无法对慢调用进行自动降级
Sentinel通过并发线程数的流量控制提供信号量隔离的功能；此外，Sentinel支持的熔断降级维度更多，可对多种指标进行流控、熔断，且提供了实时监控和控制面板，功能更为强大
限流
什么是限流？
流量控制(Flow Control)，原理是监控应用流量的QPS或并发线程数等指标，当达到指定阈值时对流量进行控制，避免系统被瞬时的流量高峰冲垮，保障应用高可用性。
限流规则组成的6大因素
resource
资源名，即限流规则的作用对象
count
限流阈值
grade
限流阈值类型（QPS 或并发线程数）
QPS
每秒请求数，当前调用该api的QPS到达阈值的时候进行限流
线程数
当调用该api的线程数到达阈值的时候，进行限流
limitApp
流控针对的调用来源，若为 default 则不区分调用来源
strategy
调用关系限流策略
直接失败模式
当api大达到限流条件时，直接限流
关联模式
当关联的资源到达阈值，就限流自己
对于链路，Sentinel 通过 NodeSelectorSlot 建立不同资源间的调用的关系，并且通过 ClusterBuilderSlot 记录每个资源的实时统计信息。
链路
只记录指定路上的流量，指定资源从入口资源进来的流量，如果达到阈值，就进行限流，api级别的限流
Warm up（预热）模式
处理请求的数量是缓步的增多，经过预期的时间以后，到达系统处理请求个数的最大值
默认 coldFactor 为 3，即请求 QPS 从 threshold / 3 开始，经预热时长逐渐升至设定的 QPS 阈值
排队等待模式
怎么实现？
匀速排队（RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER）方式会严格控制请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。阈值必须设置为QPS。
用于何处？
主要用于处理间隔性突发的流量，例如消息队列
具体过程？
Sentinel会以固定的间隔时间让请求通过, 访问资源。当请求到来的时候，如果当前请求距离上个通过的请求通过的时间间隔不小于预设值，则让当前请求通过；否则，计算当前请求的预期通过时间，如果该请求的预期通过时间小于规则预设的 timeout 时间，则该请求会等待直到预设时间到来通过；反之，则马上抛出阻塞异常。
简化说明
使用一个时间段(比如20s的时间)处理某一瞬时产生的大量请求, 起到一个削峰填谷的作用, 从而充分利用系统的处理能力
热点规则 (ParamFlowRule)
热点参数规则
resource
资源名，必填
count
限流阈值，必填
grade
限流模式，默认QPS模式
durationInSec
统计窗口时间长度（单位为秒），1.6.0 版本开始支持，默认1s
controlBehavior
流控效果（支持快速失败和匀速排队模式），1.6.0 版本开始支持，默认是快速失败模式
maxQueueingTimeMs
最大排队等待时长（仅在匀速排队模式生效），1.6.0 版本开始支持，默认是0ms
paramIdx
热点参数的索引，必填，对应 SphU.entry(xxx, args) 中的参数索引位置
paramFlowItemList
参数例外项，可以针对指定的参数值单独设置限流阈值，不受前面 count 阈值的限制。仅支持基本类型和字符串类型
clusterMode
是否是集群参数流控规则，默认是false
clusterConfig
集群流控相关配置
controlBehavior
流量控制效果（直接拒绝、Warm Up、匀速排队）
系统保护
目的
保证系统不被拖垮
在系统稳定的前提下，保持系统的吞吐量
旧思路
系统保护的思路是根据硬指标，即系统的负载 (load1) 来做系统过载保护。当系统负载高于某个阈值，就禁止或者减少流量的进入；当 load 开始好转，则恢复流量的进入。
延伸出两个问题
load 是一个“结果”，如果根据 load 的情况来调节流量的通过率，那么就始终有延迟性。也就意味着通过率的任何调整，都会过一段时间才能看到效果。当前通过率是使 load 恶化的一个动作，那么也至少要过 1 秒之后才能观测到；同理，如果当前通过率调整是让 load 好转的一个动作，也需要 1 秒之后才能继续调整，这样就浪费了系统的处理能力。所以我们看到的曲线，总是会有抖动。
恢复慢。想象一下这样的一个场景（真实），出现了这样一个问题，下游应用不可靠，导致应用 RT 很高，从而 load 到了一个很高的点。过了一段时间之后下游应用恢复了，应用 RT 也相应减少。这个时候，其实应该大幅度增大流量的通过率；但是由于这个时候 load 仍然很高，通过率的恢复仍然不高。
目标
在系统不被拖垮的情况下，提高系统的吞吐率，而不是 load 一定要到低于某个阈值
Sentinel的做法
在系统自适应保护的做法是，用 load1 作为启动自适应保护的因子，而允许通过的流量由处理请求的能力，即请求的响应时间以及当前系统正在处理的请求速率来决定。
系统保护规则的应用
支持的模式
Load 自适应（仅对 Linux/Unix-like 机器生效）
系统的 load1 作为启发指标，进行自适应系统保护。当系统 load1 超过设定的启发值，且系统当前的并发线程数超过估算的系统容量时才会触发系统保护（BBR 阶段）。系统容量由系统的 maxQps * minRt 估算得出。设定参考值一般是 CPU cores * 2.5。
CPU usage（1.5.0+ 版本）
当系统 CPU 使用率超过阈值即触发系统保护（取值范围 0.0-1.0），比较灵敏。
平均 RT
当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护，单位是毫秒。
并发线程数
当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。
入口 QPS
当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护。
本质
系统保护规则是从应用级别的入口流量进行控制，从单台机器的 load、CPU 使用率、平均 RT、入口 QPS 和并发线程数等几个维度监控应用指标，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。
系统保护规则是应用整体维度的，而不是资源维度的，并且仅对入口流量生效。入口流量指的是进入应用的流量（EntryType.IN），比如 Web 服务或 Dubbo 服务端接收的请求，都属于入口流量。
参数说明
highestSystemLoad
最大的 load1，参考值 -1 (不生效)
avgRt
所有入口流量的平均响应时间 -1 (不生效)
maxThread
入口流量的最大并发数 -1 (不生效)
qps
所有入口资源的 QPS -1 (不生效)
黑白名单规则
作用
黑白名单根据资源的请求来源（origin）限制资源是否通过，若配置白名单则只有请求来源位于白名单内时才可通过；若配置黑名单则请求来源位于黑名单时不通过，其余的请求通过
调用方信息通过 ContextUtil.enter(resourceName, origin) 方法中的 origin 参数传入
访问控制规则(AuthorityRule)
也就是黑白名单规则
配置项
resource
资源名，即限流规则的作用对象
limitApp
对应的黑名单/白名单，不同 origin 用 , 分隔，如 appA,appB
strategy
限制模式，AUTHORITY_WHITE 为白名单模式，AUTHORITY_BLACK 为黑名单模式，默认为白名单模式 比如我们希望控制对资源 test 的访问设置白名单，只有来源为 appA 和 appB 的请求才可通过
核心组件
Resource
定义完资源后，可通过埋点来保护服务
埋点的方式
try-catch 方式（通过 SphU.entry(...)），当 catch 到BlockException时执行异常处理(或fallback)
if-else 方式（通过 SphO.entry(...)），当返回 false 时执行异常处理(或fallback)
也可用SentinelResource注解
在sentinel中具体表示资源的类是：ResourceWrapper ，他是一个抽象的包装类，包装了资源的 Name 和EntryType。
两个实现类
StringResourceWrapper
通过对一串字符串进行包装，是一个通用的资源包装类
MethodResourceWrapper
对方法调用的包装
Context
定义
Context是对资源操作时的上下文环境，每个资源操作(针对Resource进行的entry/exit)必须属于一个Context，如果程序中未指定Context，会创建name为"sentinel_default_context"的默认Context。
一个Context生命周期内可能有多个资源操作，Context生命周期内的最后一个资源exit时会清理该Context，这也预示这整个Context生命周期的结束。
Entry
定义
每次执行 SphU.entry() 或 SphO.entry() 都会返回一个Entry，Entry表示一次资源操作，内部会保存当前invocation信息。
在一个Context生命周期中多次资源操作，也就是对应多个Entry，这些Entry形成parent/child结构保存在Entry实例中。
0 条评论
下一页
