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