「这是我参与2022首次更文挑战的第2天，活动详情查看：2022首次更文挑战」。
Sentinel工作主流程
Sentinel的核心骨架，将不同的Slot按照顺序串在一起（责任链模式），从而将不同的功能（限流、降级、系统保护）组合在一起。slot chain 其实可以分为两部分：统计数据构建部分（statistic）和判断部分（rule checking）。核心结构：目前的设计是 one slot chain per resource，因为某些 slot 是 per resource 的（比如 NodeSelectorSlot）。
在Sentinel里面，所有的资源都对应一个资源名称（resourceName），每次资源调用都会创建一个 Entry 对象。Entry可以通过对主流框架的适配自动创建，也可以通过注解的方式或调用 SphU API 显式创建。Entry 创建的时候，同时也会创建一系列功能插槽（slot chain），这些插槽有不同的职责，例如:
NodeSelectorSlot负责收集资源的路径，并将这些资源的调用路径，以树状结构存储起来，用于根据调用路径来限流降级； ClusterBuilderSlot 则用于存储资源的统计信息以及调用者信息，例如该资源的 RT, QPS, thread count 等等，这些信息将用作为多维度限流，降级的依据； StatisticSlot 则用于记录、统计不同纬度的 runtime 指标监控信息； FlowSlot 则用于根据预设的限流规则以及前面slot统计的状态，来进行流量控制； AuthoritySlot 则根据配置的黑白名单和调用来源信息，来做黑白名单控制； DegradeSlot 则通过统计信息以及预设的规则，来做熔断降级； SystemSlot 则通过系统的状态，例如 load1 等，来控制总的入口流量 Context Context 代表调用链路上下文，贯穿一次调用链路中的所有 Entry。Context 维持着入口节点（entranceNode）、本次调用链路的 curNode、调用来源（origin）等信息。Context 名称即为调用链路入口名称。 Context 维持的方式：通过 ThreadLocal 传递，只有在入口 enter 的时候生效。由于 Context 是通过 ThreadLocal 传递的，因此对于异步调用链路，线程切换的时候会丢掉 Context，因此需要手动通过 ContextUtil.runOnContext(context, f) 来变换 context。
Entry 每一次资源调用都会创建一个 Entry。Entry 包含了资源名、curNode（当前统计节点）、originNode（来源统计节点）等信息。 CtEntry 为普通的 Entry，在调用 SphU.entry(xxx) 的时候创建。特性：Linked entry within current context（内部维护着 parent 和 child） 需要注意的一点：CtEntry 构造函数中会做调用链的变换，即将当前 Entry 接到传入 Context 的调用链路上（setUpEntryFor）。 资源调用结束时需要 entry.exit()。exit 操作会过一遍 slot chain exit，恢复调用栈，exit context 然后清空 entry 中的 context 防止重复调用。
@SentinelResource 注解定义资源并配置 blockHandler 和 fallback 函数来进行限流之后的处理 blockHandler 函数会在原方法被限流/降级/系统保护的时候调用。 blockHandler 对应处理 BlockException 的函数名称 而 fallback 函数会针对所有类型的异常。请注意 blockHandler 和 fallback 函数的形式要求
流量控制
主要有两种统计类型，一种是统计并发线程数，另外一种则是统计 QPS。 Sentinel 并发控制不负责创建和管理线程池，而是简单统计当前请求上下文的线程数目（正在执行的调用数目），如果超出阈值，新的请求会被立即拒绝，效果类似于信号量隔离。并发数控制通常在调用端进行配置。
QPS流量控制 当 QPS 超过某个阈值的时候，则采取措施进行流量控制。流量控制的效果包括以下几种：直接拒绝、Warm Up、匀速排队
Warm Up方式，即预热/冷启动方式。当系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮
匀速排队 匀速排队（RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER）方式会严格控制请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。
熔断策略 Sentinel 提供以下几种熔断策略：
慢调用比例:选择以慢调用比例作为阈值，需要设置允许的慢调用 RT（即最大的响应时间），请求的响应时间大于该值则统计为慢调用。当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目，并且慢调用的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断，若大于设置的慢调用 RT 则会再次被熔断。
异常比例:当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目，并且异常的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。异常比率的阈值范围是 [0.0, 1.0]，代表 0% - 100%。
异常数 (ERROR_COUNT)：当单位统计时长内的异常数目超过阈值之后会自动进行熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。 滑动窗口算法 先将当前时间按照统计时长分段，得到当前时间对应的分段ID。因为窗口数组是固定的，所以随着时间线向前发展，会不断的顺序循环使用数组中的窗口。所以使用当前时间对应的分段ID与窗口数组的长度求余得到当前时间对应的窗口在窗口数组中的下标，拿到这个下标后，接着就是在循环中获取这个下标对应的窗口了。
在获取指定下标对应的窗口时，要分情况进行处理：
如果对应下标窗口为null，那么就是第一次进入，创建新窗口并使用cas设置。如果非空走下面的逻辑。 如果获取到的窗口开始时间等于当前时间计算出来的对应窗口开始时间，那么就拿到了当前时间需要的窗口，直接返回。 如果获取到的窗口开始时间小于当前时间计算出来的对应窗口开始时间，那么就说明这个窗口已经过期了，所以加锁重置，然后重复使用。 当前时间小于旧的窗口的开始时间，理论上来说是不应该出现这种情况的，如果存在这种情况，那么返回一个无效的空窗口。
Sentinel 与 Hystrix 的对比
Hystrix 的关注点在于以 隔离 和 熔断 为主的容错机制，超时或被熔断的调用将会快速失败，并可以提供 fallback 机制。 而 Sentinel 的侧重点在于：
多样化的流量控制 熔断降级 系统负载保护 实时监控和控制台 熔断降级设计理念 在限制的手段上，Sentinel 和 Hystrix 采取了完全不一样的方法。 Hystrix 通过 线程池隔离 的方式，来对依赖（在 Sentinel 的概念中对应 资源）进行了隔离。这样做的好处是资源和资源之间做到了最彻底的隔离。缺点是除了增加了线程切换的成本（过多的线程池导致线程数目过多），还需要预先给各个资源做线程池大小的分配。 Sentinel 对这个问题采取了两种手段:
通过并发线程数进行限制 和资源池隔离的方法不同，Sentinel 通过限制资源并发线程的数量，来减少不稳定资源对其它资源的影响。这样不但没有线程切换的损耗，也不需要您预先分配线程池的大小。当某个资源出现不稳定的情况下，例如响应时间变长，对资源的直接影响就是会造成线程数的逐步堆积。当线程数在特定资源上堆积到一定的数量之后，对该资源的新请求就会被拒绝。堆积的线程完成任务后才开始继续接收请求。
通过响应时间对资源进行降级
除了对并发线程数进行控制以外，Sentinel 还可以通过响应时间来快速降级不稳定的资源。当依赖的资源出现响应时间过长后，所有对该资源的访问都会被直接拒绝，直到过了指定的时间窗口之后才重新恢复。
