第二章 Sentine 核心工作原理

Posted 2023-03-17

参考技术A

可以看出，实际上 sentinel 的核心原理就是： 为每个资源创建一条链，链上包含一系列的 slot，这些 slot 分两部分，前一部分 slot 用于做各种统计，后一部分 slot 基于前一部分 slot 的统计结果，做出相应的流控逻辑

sentinel 的数据统计是基于 Node 结构来做，首先看下四种 Node 的类结构。

在 FlowSlot 执行限流逻辑时，会根据来源（limitApp）和流控模式（strategy）选择相关的统计 Node 节点，之后再使用该 Node 节点 + 流控效果（controlBehavior）+ 限流阈值类型（QPS/并发线程数）执行限流操作。限流设计如下，后续的流控设计基本类似。

以下内容摘抄自 sentinel官网

限流规则中的 limitApp 字段用于根据调用方进行流量控制。该字段的值有以下三种选项，分别对应不同的场景：

举个使用案例，假设调用关系如下：被调用方的入口 IN 流控设置了200QPS（不区分调用来源），调用来源1和调用来源2均没有设置流控规则，那么假设调用来源1是一个集聚流量，马上打满了200qps，那么整个调用来源2就无法请求成功了。为了避免这种情况，可以使用 some_origin_name 为调用来源1配置一条规则，然后再设置一条 other 规则为其他调用源进行设置，而二者相加的阈值就是被调方的入口接口阈值。

当 QPS 超过某个阈值的时候，则采取措施进行流量控制。流量控制的手段包括下面 3 种，对应 FlowRule 中的 controlBehavior 字段：

与 Hystrix 的对比，摘抄自 官网 。
Hystrix 通过 线程池隔离 的方式，来对依赖（在 Sentinel 的概念中对应资源）进行了隔离。这样做的好处是资源和资源之间做到了最彻底的隔离。缺点是除了增加了线程切换的成本（过多的线程池导致线程数目过多），当业务调用资源时，需要将自身线程切换到给资源分配的线程池中的线程，还需要预先给各个资源做线程池大小的分配。（实际上，Hystrix 也支持信号量隔离，Hystrix 官方推荐线程池隔离方式）

Sentinel 对这个问题采取了两种手段:

通过看程序传入的 Context.origin 是否在配置的流控应用（limitApp）中，再根据授权类型（白名单/黑名单）来判断是否可以需要流控。这里可以根据想要控制的目标来灵活的设计 origin。

系统保护规则是 应用整体 维度的，而不是资源维度的，并且 仅对入口流量生效 。入口流量指的是进入应用的流量（EntryType.IN），比如 Web 服务或 Dubbo 服务端接收的请求，都属于入口流量。sentinel 提供了一个全局的IN流量的统计节点ClusterNode( total_inbound_traffic )，在 StatisticSlot 统计信息时，会将IN流量数据统计入其中。

为什么不用 Load1 的阈值直接限流？

解决方案：BBR

我们把系统处理请求的过程想象为一个水管，到来的请求是往这个水管灌水，当系统处理顺畅的时候，请求不需要排队，直接从水管中穿过，这个请求的RT是最短的；反之，当请求堆积的时候，那么处理请求的时间则会变为：排队时间 + 最短处理时间。

推论一: 如果我们能够保证水管里的水量，能够让水顺畅的流动，则不会增加排队的请求；也就是说，这个时候的系统负载不会进一步恶化。
我们用 T 来表示(水管内部的水量) ，用 RT来表示请求的处理时间 ，用 P来表示进来的请求数 ，那么一个请求从进入水管道到从水管出来，这个水管会存在P * RT个请求。换一句话来说， 当 T ≈ QPS * Avg(RT) 的时候，我们可以认为系统的处理能力和允许进入的请求个数达到了平衡 ，系统的负载不会进一步恶化。

接下来的问题是，水管的水位是可以达到了一个平衡点，但是这个平衡点只能保证水管的水位不再继续增高，但是还面临一个问题，就是在达到平衡点之前，这个水管里已经堆积了多少水。如果之前水管的水已经在一个量级了，那么这个时候系统允许通过的水量可能只能缓慢通过，RT会大，之前堆积在水管里的水会滞留；反之，如果之前的水管水位偏低，那么又会浪费了系统的处理能力。

推论二:　当保持入口的流量是水管出来的流量的最大的值的时候，可以最大利用水管的处理能力。
然而，和 TCP BBR 的不一样的地方在于，还需要用一个系统负载的值（load1）来激发这套机制启动。

Spring Cloud Gateway核心概念和工作原理-Part 1

参考技术A Spring Cloud Gateway是Spring官方基于Spring 5.0，Spring Boot 2.0和Project Reactor等技术开发的网关，Spring Cloud Gateway旨在为微服务架构提供一种简单而有效的统一的API路由管理方式。Spring Cloud Gateway作为Spring Cloud生态系中的网关，目标是替代Netflix ZUUL，其不仅提供统一的路由方式，并且基于Filter链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。

使用过Zuul的人，都知道网关的核心肯定是Filter以及Filter Chain（Filter 责任链）。Spring Cloud Gateway也具有路由和Filter的概念。下面介绍一下Spring Cloud Gateway中的几个重要概念。

Spring Cloud Gateway 核心处理流程如下所示。

Gateway的客户端向Spring Cloud Gateway发起请求，请求首先会被 Gateway Handler Mapping 接收，决定请求匹配的路由，然后发送给Gateway Web Handler。Handler 通过特定的请求filter链发送请求。

过滤链通过虚线分隔的原因是过滤器filter可以在代理请求发送之前或者之后执行逻辑。执行所有 pre 过滤逻辑，然后发出请求给代理服务（proxied service），之后将执行 post 过滤器逻辑。

将如下依赖项添加到Spring Cloud项目的pom.xml文件中。

Spring Cloud Gateway提供了一个gateway actuator，该EndPoint 提供了关于Filter和Routes的信息查询。可以在application.yml 中配置开启。

访问gateway 端点：

可以看到返回的路由信息：

新的gateway网关路由配置有两种方式：

1.通过@Bean自定义RouteLocator，在启动主类Application中配置。

2.在配置文件yml中配置。

这两种方式都可以实现网关路由是等价的，但是通常项目开发中会使用配置文件yml方式。

相关链接：

https://cloud.spring.io/spring-cloud-gateway/spring-cloud-gateway.html