Sentinel 实现原理

Posted 2023-03-03 lichunericli

服务雪崩

服务雪崩效应：因服务提供者的不可用导致服务调用者的不可用，并将不可用逐渐放大的过程。

当服务提供者不可用的，会产生大量重试，大量重试会加大请求流量，会存在大量请求线程同步等待造成资源耗尽，资源耗尽会导致服务调用者服务也将处于不可用状态，雪崩效应产生。

导致服务不可用的原因： 程序Bug，大流量请求，硬件故障，缓存击穿。

解决方案

（1）超时机制：超时则释放资源

（2）资源隔离：线程池+队列，信号量

（3）服务熔断：远程服务不稳定或网络抖动时暂时关闭

（4）服务降级：服务熔断后，服务将不再被调用，客户端准备本地的fallback回调，返回 缺省值。

Sentinel工作原理

Sentinel主要以流量为切入点，从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维 度来帮助开发者保障微服务的稳定性。

（1）实时监控 ：监控接口通过和拒绝的QPS ，实时监控仅存储5分钟以内的数据，可通过调用实时监控接口来实现持久化。

（2）流量控制（flow control）：其原理是监控应用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行控制，同一个资源可以创建多条限流规则。

（2.1）资源的调用关系：直接，链路和关联，关联是指资源的争取或者依赖，链路根据调用链路入口限流；

（2.2）运行指标：QPS，线程并发数和系统负载等；

（2.3）控制的效果：默认的快速失败/直接拒绝，WarmUp预热/冷启动，请求匀速排队通过（漏桶算法）等。

（3）BlockException异常统一处理：SpringWebMVC接口资源限流入口在HandlerInterceptor的实现类AbstractSentinelInterceptor的preHandle方法中，对异常的处理是BlockExceptionHandler的实现类。

（4）熔断降级：对调用链路中不稳定的资源进行熔断降级 ，熔断策略支持慢调用比例，异常比例和异常数。熔断触发的最小请求数，请求数小于该值时即使异常比率超出阈 值也不会熔断。

（4.1）慢调用比例 (SLOW_REQUEST_RATIO)：要设置允许的慢调用 RT（最大的响应时间），请求的响应时间大于该值则统计为慢调用。当单位统计时长内请求数目大于设置的最小请求数目，并且慢调用的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。

（4.2）异常比例 (ERROR_RATIO)：当单位统计时长内请求数目大于设置的最小请求数目，并且异常的比例大于阈值，则接下来的熔断时长内请求会自动被熔断，异常比率的阈值范围是0%-100%即（0.0-1.0）。

（4.3）异常数 (ERROR_COUNT)：当单位统计时长内的异常数目超过阈值之后会自动进行熔断。

注意：经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求成功完成没有错误或者小于设置的慢调用 RT，则结束熔断，否则会再次被熔断。异常降级仅针对业务异常，对 Sentinel 限流降级本身的异常（BlockException）不生效。

（5）热点规则：热点规则需要使用@SentinelResource("resourceName")注解，参数必须是7种基本数据类型。

（6）系统负载保护：保证系统不被拖垮，在系统稳定的前提下，保持系统的吞吐量。

Sentinel系统自适应限流从整体维度对应用入口流量（EntryType.IN）进行控制，结合应用的Load、CPU使用率、总体平均RT、入口QPS和并发线程数等几个维度的监控指标，通过自适应的流控策略，让系统的入口流量和系统的负载达到一个平衡。

（7）Sentinel工作主流程

详情参考：https://github.com/alibaba/Sentinel/wiki/Sentinel%E5%B7%A5%E4%BD%9C%E4%B8%BB%E6%B5%81%E7%A8%8B

（7.1）Sentinel中所有资源都对应的资源名称（resourceName），每次调用都会创建Entry对象。

（7.2）Entry可 以通过对主流框架的适配自动创建，也可通过注解方式或调用SphU API 显式创建。

（7.3）Entry 创建的时候，同时也会创建 一系列功能插槽（slot chain）。

NodeSelectorSlot 负责收集资源的路径，并将这些资源的调用路径，以树状结构存储起来，用于根据调用路径来 限流降级；

ClusterBuilderSlot 则用于存储资源的统计信息以及调用者信息，例如该资源的 RT, QPS, thread count 等等， 这些信息将用作为多维度限流，降级的依据；

StatisticSlot 则用于记录、统计不同纬度的 runtime 指标监控信息；

FlowSlot 则用于根据预设的限流规则以及前面 slot 统计的状态，来进行流量控制；

AuthoritySlot 则根据配置的黑白名单和调用来源信息，来做黑白名单控制；

DegradeSlot 则通过统计信息以及预设的规则，来做熔断降级；

SystemSlot 则通过系统的状态，例如 load1 等，来控制总的入口流量；

Sentinel可通过SPI机制来实现自定义降级ProcessorSlot扩展：

Sentinel集群流控

限制调用某个API的总QPS数，解决流量不均匀导致总体限流效果不佳的问题。

详情参考：https://github.com/alibaba/Sentinel/wiki/%E9%9B%86%E7%BE%A4%E6%B5%81%E6%8E%A7

（1）集群流控中共有两种身份

Token Client：集群流控客户端

用于向所属 Token Server 通信请求 token。集群限流服务端会返回给客户端结果，决定是否限流。

Token Server：集群流控服务端

处理来自 Token Client 的请求，根据配置的集群规则判断是否应该发放 token（是否允许通过）。

（2）Sentinel 集群流控规则

支持限流规则和热点规则两种规则，并支持两种形式的阈值计算方式：

集群总体模式

限制整个集群内的某个资源的总体QPS不超过此阈值。

单机均摊模式

单机均摊模式下配置的阈值等同于单机能够承受的限额，token server 会根据连接数来计算总的阈值并进行限制，实时计算总的阈值，对于机器经常进行变更的环境非常适合。

（3）启动方式

Sentinel 集群限流服务端有两种启动方式：

独立模式（Alone）

作为独立的 token server 进程启动，独立部署，隔离性好，但是需要额外的部署操作。独立模式适合作为 Global Rate Limiter 给集群提供流控服务。

嵌入模式（Embedded）

作为内置的 token server 与服务在同一进程中启动，集群中各个实例都是对等的，token server 和 client 可以随时进行转变，无需单独部署且灵活性比较好。但是隔离性不佳，需要限制 token server 的总 QPS，防止影响应用本身。嵌入模式适合某个应用集群内部的流控。