SpringCloud Alibaba——Sentinel

本篇文章介绍的是SpringCloud Alibaba技术栈中针对熔断限流的解决方案——Sentinel，本篇文章的大纲如下所示： 一、概念介绍

• 当有大量请求突然涌入进来，远远超出系统可以处理的并发数。就会造成服务器宕机且服务不可用。为了保障服务仍然能够稳定运行，就需要系统具有限流、熔断、降级等能力。

1.1> 什么是服务雪崩

• 一个服务失败，导致整条链路的服务都失败的情形，我们称之为服务雪崩。
• 服务熔断和服务降级就可以视为解决服务雪崩的手段。
• 我们可以把它理解为多条有交集的高速公路路口。当ServiceD这个路口拥堵配对的时候，也会影响到ServiceG和ServiceF。随着时间推移。ServiceG和ServiceF也开始发生拥堵了，那么会影响到ServiceA和ServiceB。

1.2> 什么是限流

• 限流的主要目的是通过限制并发访问数或者限制一个时间窗口内允许处理的请求数量来保护系统，一旦达到限制流量，则对当前请求进行处理采取对应的拒绝策略。如：跳转错误页面、进行排队、服务降级等。
• 比如：系统可以处理1万的并发，但是这一时刻并发数是2万，那么限流机制就会保证1万的用户是正常使用的。
• 限流的方式有哪些： 1> 在Nginx层添加限流模块，限制平均访问速度。 2> 通过设置数据库连接池或线程池的大小来限制总的并发数量。 3> 通过Guava提供的Ratelimiter限制接口的访问速度。 4> TCP通信协议中的流量整形。

1.3> 什么是熔断（框架级别的熔断器，相当于保险丝）

• 服务熔断是指当某个服务提供者无法正常为服务调用者提供服务时，比如请求超时、服务异常等，为了防止整个系统出现雪崩效应，暂时将出现故障的接口隔离出来，断绝与外部接口的联系，当触发熔断之后，后续一段时间内该服务调用者的请求都会直接失败，直到目标服务恢复正常。
• 熔断其实是一个框架级别的处理，这套熔断机制的设计，基本上采用的就是断路器模式。如下图所示：

1.4> 什么是降级（业务级别的手工可配置开关，相当于06年笔记本玩魔兽争霸）

• 当下游的服务因为某种原因响应过慢，下游服务主动停掉一些不太重要的业务，释放出服务器资源，增加响应速度！
• 当下游的服务因为某种原因不可用，上游主动调用本地的一些降级逻辑，避免卡顿，迅速返回给用户！
• 服务降级大多是属于一种业务级别的处理。比如：开关降级。做法很简单，做个开关，然后将开关放配置中心。在配置中心更改开关，决定哪些服务进行降级。
• 自己梳理出核心业务流程和非核心业务流程。然后在非核心业务流程上加上开关，一旦发现系统扛不住，关掉开关，结束这些次要流程。

1.5> 服务熔断降级的几种常见方案

• 平均响应时间 比如1秒内持续进入5个请求，对应时刻的平均响应时间均超过阈值，那么接下来在一个固定的时间窗口内，对这个方法的访问都会自动熔断。
• 异常比例 当某个方法每秒调用所获得的异常总数的比例超过设定的阈值时，该资源会自动进入降级状态，也就是在接下来的一个固定时间窗口中，对这个方法的调用都会自动返回。
• 异常数量 和异常比例类似，当某个方法在指定时间窗口内获得的异常数量超过阈值时，会触发熔断。

二、常用的限流算法

2.1> 计数器算法

• 在指定周期内累加访问次数，当访问次数达到设定的阈值时，触发限流策略，当进入下一个时间周期时进行访问次数的清零。
• 如图所示：

• 临界问题，如图所示：

2.2> 滑动窗口算法

• 滑动窗口为固定窗口的改良版，解决了固定窗口在窗口切换时会受到两倍于阈值数量的请求，滑动窗口在固定窗口的基础上，将一个窗口分为若干个等份的小窗口，每个小窗口对应不同的时间点，拥有独立的计数器，当请求的时间点大于当前窗口的最大时间点时，则将窗口向前平移一个小窗口（将第一个小窗口的数据舍弃，第二个小窗口变成第一个小窗口，当前请求放在最后一个小窗口），整个窗口的所有请求数相加不能大于阈值。
• Sentinel就是采用滑动窗口算法来实现限流的。
• 如图所示：

【注】

• 1> 把3秒钟划分为3个小窗，每个小窗限制请求不能超过50秒。
• 2> 比如我们设置，3秒内不能超过150个请求，那么这个窗口就可以容纳3个小窗，并且随着时间推移，往前滑动。每次请求过来后，都要统计滑动窗口内所有小窗的请求总量。

2.3> 令牌桶限流算法（控制令牌生成速度，取的速度不控制）

• 令牌桶是网络流量整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一种算法。
• 对于每一个请求，都需要从令牌桶中获得一个令牌；如果没有获得令牌，则需要触发限流策略。
• 系统会以恒定速度（r tokens/sec）往固定容量的令牌桶中放入令牌。
• 令牌桶有固定的大小，如果令牌桶被填满，则会丢弃令牌。
• 会存在三种情况：
  • 请求速度 > 令牌生成速度 当令牌被取空后，会被限流
  • 请求速度 == 令牌生成速度 流量处于平稳状态
  • 请求速度 < 令牌生成速度 请求可被正常处理，桶满则丢弃令牌
• 如图所示：

2.4> 漏桶限流算法（控制水滴流出速度，不控制水滴产生速度）

• 主要的作用： 1> 控制数据注入网络的速度。 2> 平滑网络上的突发流量。
• 漏桶限流算法的核心就是：不管上面的水流速度有多块，漏桶水滴的流出速度始终保持不变。
• 消息中间件就采用的漏桶限流的思想。
• 如图所示：

三、Sentinel概述和基本使用

3.1> Sentinel概述

• https://github.com/alibaba/Sentinel/wiki/介绍
• 它是面向分布式服务架构的轻量级流量控制组件，主要以流量为切入点，从限流、流量整形、服务降级、系统负载保护等多个唯度来帮助我们保障微服务的稳定性。
• Sentinel的特性有如下： 适用场景丰富。 提供实时监控的功能包括查看单机秒级数据，设置500台以下规模的集群汇总运行情况。 只需引入Maven依赖并进行简单的配置，即可快速与Spring Cloud、Dubbo、gRPC等进行整合。
• 组成部分
  • Java核心库 不依赖任何框架/库，能够运行于所有Java运行时环境，同时对Dubbo、SpringCloud等框架也有较好的支持。
  • Dashboard控制台 基于SpringBoot开发，打包后可以直接运行，不需要额外的Tomcat等应用容器。
• 主要特征

• 开源生态

3.2> 部署Sentinel Dashboard

• 下载Sentinel源码或者直接下载release版本jar包 源码：https://github.com/alibaba/Sentinel jar包：https://github.com/alibaba/Sentinel/releases
• 命令启动Sentinel Dashboard java -Dserver.port=8000 -Dcsp.sentinel.dashboard.server=localhost:8000 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard-1.7.1.jar

【命令参数解释】

• -Dserver.port 指定Sentienl控制台的访问端口，默认是8080。
• -Dcsp.sentinel.dashboard.server 指定Sentinel Dashboard控制台的IP地址和端口，这里进行设置的目的是把自己的限流数据暴露到控制平台。
• -Dproject.name 设置项目名称。
• -jar 指定启动的jar包

• 启动日志如下

• 访问http://localhost:8000，从Sentinel 1.6.0开始，加入了登录功能。默认用户名&密码都是sentinel。控制台界面如下：

3.3> 实战1：编码方式接入Sentinel

3.3.0> 准备工作

• 接入流程

• 创建一个项目，名为sentinel-simple-demo
• 项目结构

3.3.1> 引入Sentinel依赖

• 【注意】从Sentinel 1.5.0开始仅支持JDK1.7或者以上版本。Sentinel 1.5.0之前的版本最低支持JDK1.6。

3.3.2> 定义日常业务代码

• BusinessService.java

3.3.3> 定义限流规则和熔断规则

• RulesUtils.java

3.3.4> 定义基于SphU方式的限流&熔断测试类

• 接下来，我们把需要控制流量的代码用Sentinel API SphU.entry("process") 和 entry.exit() 包围起来即可（SphO也是一样的）。当然，也支持注解形式——@SentinelResource，注解方式后续我们会介绍到。
• 资源名称（例如：“process”）可以定义方法名称、接口名称或者其他的唯一标识。
• 当使用SphU.entry时，如果资源被限流/熔断后，会抛出一个BlockException，然后在捕获异常后进行限流的逻辑处理。
  • 例子：SentinelSphUSimpleDemo.java
• 当使用SphO.entry时，如果资源被限流/熔断后，会返回false。然后在else判断后进行限流的逻辑处理。
  • 例子：SentinelSphOSimpleDemo.java
• 需要注意，当使用SphO.entry时，需要资源使用完之后调用SphO.exit()，否则会导致调用链记录抛出ErrorEntryFreeException异常。
• 通过SphU实现限流规则

• 运行之后，我们可以在日志 ~/logs/csp/${appName}-metrics.log.xxx 里看到下面的输出:

【注释】

日志格式为：MetricNode.java

• timestamp——限流统计的时间戳
• yyyy-MM-dd HH:mm:ss——限流统计的日期时间
• resource——资源名称
• passQps——代表通过的请求；
• blockQps——代表被阻止的请求；
• successQps——代表成功执行完成的请求个数；
• exceptionQps——代表用户自定义的异常；
• rt——代表平均响应时长；
• occupiedPassQps——代表优先通过的请求；
• concurrency——代表并发量；
• classification——代表资源类型；

• 通过SphU实现熔断规则

3.3.5> 定义基于SphO方式的限流&熔断测试类

• 通过SphO实现限流规则

• 运行之后，我们可以在日志 ~/logs/csp/${appName}-metrics.log.xxx 里看到下面的输出:

• 通过SphO实现熔断规则

3.4> 实战2：注解方式接入Sentinel

3.4.1> 前提介绍

• 在第三步，定义资源时，也可以使用@SentinelResource注解的方式，方便的进行资源管理。项目目录如下：

3.4.2> 引入sentinel-annotation-aspectj和SpringMVC依赖

• sentinel-simple-demo的pom

3.4.3> 编写Configuration配置类，创建SentinelResourceAspect的Bean实例

• SentinelAspectConfiguration.java

3.4.4> 创建服务类

• SentinelWithAnnotationService.java

• SentinelWithAnnotationServiceImpl.java

3.4.5> 创建外部异常类

• ExceptionUtil.java

3.4.6> 创建Controller测试类

• SentinelSimpleDemoController.java

3.4.7> @SentinelResource注解包含属性介绍

• 注意：注解方式埋点不支持private方法。
• @SentinelResource 用于定义资源，并提供可选的blockHandler异常处理和fallback配置项。
• 注解包含以下属性：
  • 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（since 1.6.0）：（可选项） 默认的 fallback 函数名称，通常用于通用的 fallback 逻辑（即可以用于很多服务或方法）。默认 fallback 函数可以针对所有类型的异常（除了 exceptionsToIgnore 里面排除掉的异常类型）进行处理。若同时配置了 fallback和defaultFallback，则只有fallback会生效。
  • defaultFallback 函数签名要求： 返回值类型必须与原函数返回值类型一致； 方法参数列表需要为空，或者可以额外多一个Throwable类型的参数用于接收对应的异常。 defaultFallback函数默认需要和原方法在同一个类中。若希望使用其他类的函数，则可以指定 fallbackClass 为对应的类的 Class 对象，注意对应的函数必需为static 函数，否则无法解析。
  • exceptionsToIgnore（since 1.6.0） 用于指定哪些异常被排除掉，不会计入异常统计中，也不会进入 fallback 逻辑中，而是会原样抛出。

3.5> 限流规则详解

3.5.1> FlowRule参数详解

• RulesUtils.initFlowRules()

【参数方法补充说明】

• rule.setGrade(...) —— 限流阈值类型
  • 并发线程数——RuleConstant.FLOW_GRADE_THREAD=0 并发线程数限流用来保护业务线程不被耗尽。如果超出阈值，新的请求就会被拒绝。比如：A服务调用B服务，而B服务发生不稳定或响应延迟，造成A服务吞吐下降，由于A服务中线程阻塞后未释放，造成占用很多线程，最终导致线程池耗尽。
  • QPS——RuleConstant.FLOW_GRADE_QPS=1 Queries Per Second即：每秒查询数。也就是每台服务器每秒钟可以响应的查询次数。
• rule.setStrategy(...) —— 调用关系限流策略
  • 调用方限流——RuleConstant.STRATEGY_DIRECT
  • 根据调用链路入口限流——RuleConstant.STRATEGY_CHAIN
  • 关联流量控制——RuleConstant.STRATEGY_RELATE
• rule.setControlBehavior(...) —— QPS流量流控行为
  • 直接拒绝 默认流量控制方式，超出阈值时，直接抛出FlowException异常。
  • Warm_Up 是一种冷启动（预热）方式。当流量突然增大时，可能会瞬间把系统压垮。那么我们希望这种请求是逐步递增的，并且在一个预期时间之后，达到允许处理请求的最大值。如图所示：

• 匀速排队 它会使请求以匀速的方式通过。类似于漏桶限流算法的那种方式。如图所示：

3.5.2> DegradeRule参数详解

• RulesUtils.initFlowDegradeRules()

【参数方法补充说明】

• rule.setGrade(...) —— 熔断策略
  • 平均响应时间——RuleConstant.DEGRADE_GRADE_RT=0 如果每秒资源数>=minRequestAmount（默认值5），对应的平均响应时间都超过了阈值（count，单位为毫秒），那么在接下来的时间窗口（timeWindow，单位为秒）内，对这个方法的调用都会自动熔断，抛出DegradeException。Sentinel默认统计的RT上限是4900ms，如果超出此阈值都会算作4900ms，如果需要修改，则通过启动参数-Dcsp.sentinel.statistic.max.rt=xxx来配置。
  • 异常比例——RuleConstant.DEGRADE_GRADE_EXCEPTION_RATIO=1 如果每秒资源数>=minRequestAmount（默认值5），并且每秒的【异常总数/总通过量 】超过阈值count，取值范围为[0.0, 1.0]，代表0%~100%，则资源将进入降级状态。同样，在接下来的timeWindow之内，对这个方法的调用都会自动触发熔断。
  • 异常数——RuleConstant.DEGRADE_GRADE_EXCEPTION_COUNT=2 当资源最近一分钟的异常数目超过阈值count之后，就会触发熔断。需要注意的是，如果timeWindow小于60s，则结束熔断状态后仍然可能进入熔断状态。

四、Sentinel的集成

4.1> 实战3：集成Spring Cloud Sentinel

4.1.0> 准备工作

• 创建一个项目，名为sentinel-nacos-demo
• 项目目录如下所示：

4.1.1> 只采用编码方式

• 引入Spring Cloud Sentinel和SpringMCV的依赖

• 创建一个REST接口，并通过@SentinelResource配置限流保护资源。SentinelNacosDemoController.java

• 手动配置流控规则，实现InitFunc接口，完成流控配置。FlowRuleStrategy.java

• 配置自动加载文件。 resources/META-INF/services/com.alibaba.csp.sentinel.init.InitFunc

• 启动服务，访问：http://localhost:8001/foo1
  • 1秒内的第1次访问：

• 1秒内的第N次访问：

4.1.2> Sentinel Dashboard方式

• 启动Sentinel Dashboard

• 在application.xml中添加如下配置

• 创建一个普通的REST接口。SentinelNacosDemoController.java

• 启动服务后，访问http://localhost:8001/dashboard，这样Sentinel Dashboard才会采集到该条url。此时由于没有配置限流策略，所以无论访问多少次，都会输出“-----dashboard-----”

• 访问http://localhost:8000，登录Sentinel Dashboard。点击“簇点链路”，设置流控。

• 配置流控规则

• 配置完流控规则后，多次请求会出现下面限流提示。

4.1.3> 自定义URL限流异常

• 首先：通过实现UrlBlockHandler接口，来重写blocked方法。该实现只能一个实现类。否则会报错：

• MuseBlockHandler.java。也可以负责一份MuseBlockHandler1.java，验证上面的异常。

• 配置流控规

• 请求http://localhost:8080/dashboard
  • 1秒内的第1次请求

• 1秒内的第N次请求

4.1.4> URL资源清洗

• 在默认情况下Sentinel会把所有的URL当作资源来进行控制。比如：/urlCleaner/1和/urlCleaner/2被当作两个资源。如果需要聚合资源，则需要进行url资源清洗。
• 首先，新REST接口 SentinelNacosDemoController.java

• 其次，实现MuseUrlCleaner.java接口，重写clean方法。将/urlCleaner/1和/urlCleaner/2都作为资源：/urlCleaner/*

• 执行http://localhost:8001/urlCleaner/1

• 打开Sentinel Dashboard。查看簇点链路，并设置流控。

• 执行http://localhost:8001/urlCleaner/1之后再执行执行http://localhost:8001/urlCleaner/2 ，那么会展示出限流警告

4.2> 实战4：集成Nacos

4.2.1> Nacos的安装

• 由于Sentinel Dashboard所配置的流控规则，都保存在内存中，一旦应用重启，这些规则都会被清除。为了解决这个问题，Sentinel提供了动态数据源支持，目前支持Consul、ZooKeeper、Redis、Nacos、Apollo、etcd等数据源扩展。下面以Nacos为例：
• Nacos官网 https://nacos.io/zh-cn/docs/quick-start.html
• 下载安装包 https://github.com/alibaba/nacos/releases
• 解压安装包unzip nacos-server-version.zip或者 tar -xvf nacos-server-version.tar.gzcd nacos/bin
• 启动nacos sh startup.sh -m standalone
• 如果您使用的是ubuntu系统，或者运行脚本报错提示[[符号找不到，可尝试如下运行： bash startup.sh -m standalone
• 打开控制台 http://localhost:8848/nacos 用户名&密码为：nacos & nacos

• 流程图

4.2.2> Sentinel集成Nacos

• 首先：添加Nacos数据源的依赖包

• 其次：在application.yml中添加数据源配置

• 第三：在SentinelNacosDemoController.java类中添加新的接口/withnacos请求，并重启服务

• 第四：在nacos中创建data-id为sentinel-nacos-demo-sentinel-flow的限流规则，此处的data-id与application.yml中配置的data-id一致。如下所示：

• 第五：在Sentinel Dashboard中，发现在【流控规则】中，已经加载了nacos中配置的规则。（只要Nacos中配置发布了，Sentinel就可以在流控规则中看到这条配置，如果看不到，可以尝试在Nacos中修改这个配置点击发布，再修改回来，再次发布

• 请求http://localhost:8001/withnacos
  • 1秒内第1次请求

• 1秒内第N次请求

五、工作原理

5.1> Sentinel的工作原理

• Sentinel的核心分为三部分：工作流程、数据结构和限流算法。
• 整体架构图如下所示：

• 调用链——Slot Chain 调用链是Sentinel的工作主流程，由各个Slot插槽组成，将不同的Slot按照顺序串在一起（责任链模式），从而将不同的功能（限流、降级、系统保护）组合在一起。Sentinel中各个Slot承担了不同的职责，每个模块更聚焦于实现某个功能。在Sentinel中，所有的资源都对应一个资源名称（resourceName），每次访问该资源都会创建一个Entry对象，并会同时创建一系列功能槽（Slot Chain） ，这些槽会组成一个责任链，每个槽负责不同的职责。
• 功能槽——Slot
  • NodeSelectorSlot 负责收集资源的调用路径，以树状结构存储调用栈，用于根据调用路径来限流降级。
  • ClusterBuilderSlot 负责创建以资源名维度统计的ClusterNode，以及创建每个ClusterNode下按调用来源origin划分的StatisticNode。
  • StatisticSlot 统计不同维度的请求数、通过数、限流数、线程数等runtime信息，这些数据存储在DefaultNode、OriginNode和ClusterNode中。
  • ParamFlowSLot 控制热点参数限流。
  • SystemSlot 控制总的入口流量，限制条件一次是总QPS、总线程数、RT阈值、操作系统当前load1、操作系统当前CPU利用率。
  • AuthoritySlot 权限控制，支持黑名单和白名单两种策略。
  • FlowSlot 根据限流规则和各个Node中的统计数据进行限流判断。
  • DegradeSlot 根据熔断规则和各个Node中的统计数据进行服务降级。
  • LogSlot 在出现限流、熔断、系统保护时负责记录日志。

5.2> Spring Clound Sentinel的工作原理

• 查看自动配置文件 META-INF/spring.factories文件。

• 这里EnableAutoConfiguration自动装配了5个配置类
  • SentinelWebAutoConfiguration 是对Web Servlet环境的支持。
  • SentinelWebFluxAutoConfiguration 是对Spring WebFlux的支持。
  • SentinelEndpointAutoConfiguration 暴露Endpoint信息。
  • SentinelFeignAutoConfiguration用于适配Feign组件。
  • SentinelAutoConfiguration支持对RestTemplate的服务调用使用Sentinel进行保护。
• SentinelWebAutoConfiguration

• CommonFilter

因此，对于Web Servlet环境，只是通过Filter的方式将所有请求自动设置为Sentinel的资源，从而达到限流的目的。

六、Sentinel核心源码分析

6.1> Sphu.entry源码分析

• 整体流程图

• CtSph.java

• 限流——FlowSlot & StatisticSlot

• FlowSlot.java

• FlowRuleManager.getFlowRuleMap();

• FlowRuleChecker.java

• 上面场景的应用 假设我们对接口XXXService配置限流1000QPS，这3种场景分别如下：
  • 第1种，目的是优先保障重要来源流量 我们需要区分调用来源，将限流规则细化。对A应用配置500QPS，对B应用配置200QPS，此时会产生两条规则：A应用请求的流量限制在500，B应用请求的流量限制在200。
  • 第2种，没有特别重要来源的流量 我们不想区分调用来源，所有入口调用XXXService共享一个规则，所有client加起来总流量只能通过1000QPS。
  • 第3种，配合第一种场景使用。 在长尾应用多的情况下，不想对每个应用进行设置，没有具体设置的应用都将命中。

• 最后，在passLocalCheck方法中，通过rule.getRater()获得流控行为，实现不同的处理策略，如下所示：
  • DefaultController：直接拒绝。
  • RateLimiterController：均匀排队
  • WarmUpController：冷启动（预热）
  • WarmUpRateLimiterController：匀速+冷启动