Sentinel

概述

Sentinel 是面向分布式、多语言异构化服务架构的流量治理组件，主要以流量为切入点，从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助开发者保障微服务的稳定性。

官网：https://github.com/alibaba/sentinel

https://sentinelguard.io/zh-cn/docs/introduction.html

Sentinel 主要特征：

快速开始

下载安装

下载地址：Release v1.8.6 · alibaba/Sentinel · GitHub

Sentinal 组件由两部分组成：

• 后台管理界面
• 前台 8080

启动命令：

java -jar sentinel-dashboard-1.8.6.jar

Sentinal 后台管理界面

用户名和密码都是：sentinal

上线服务

**注意：**Sentinel 需要 JDK 1.8 或更高版本。

<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-core</artifactId>
    <version>1.8.6</version>
</dependency>

添加 yaml 文件

server:
  port: 8401

spring:
  application:
    name: cloudalibaba-sentinel-service
  cloud:
    nacos:
      discovery:
        # Nacos服务注册中心地址
        server-addr: 127.0.0.1:8848
    sentinel:
      transport:
        #配置Sentinel dashboard地址
        dashboard: 127.0.0.1:8080
        #默认8719端口，假如被占用会自动从8719开始依次+1扫描,直至找到未被占用的端口
        port: 8719

management:
  endpoints:
    web:
      exposure:
        include: '*'

启动类

@EnableDiscoveryClient
@SpringBootApplication
public class MainApp8401 {
    public static void main(String[] args) {
        SpringApplication.run(MainApp8401.class, args);
    }
}

业务类

@RestController
public class FlowLimitController {
    @GetMapping("/testA")
    public String testA() {
        return "testA";
    }

    @GetMapping("/testB")
    public String testB() {
        return "testB";
    }
}

启动服务后，调用接口，在 sentienl 控制台中就有了接口流量监控。

至此 sentienl 已经监控到了 8401 的微服务了。

流控规则

任何系一个系统的运算、存储、网络资源都不是无限的，当系统资源不足不足以支撑外部超过预期的突发流量时，便应该有所取舍，建立面对超额流量自我保护的机制，这个机制就是微服务中常说的“限流”。

• 资源名：唯一名称，默认请求路径。
• 针对来源：Sentinel 可以针对调用者进行限流，填写微服务名，默认 default（不区分来源）
• 阈值类型
  • QPS（每秒请求数）：当调用该 api 的 QPS 达到阈值，进行限流。
  • 并发线程数：当调用该 api 的 线程数 达到阈值，进行限流。
• 是否集群：默认不需要集群。
• 流控模式
  • 直接：api 达到限流条件时，直接限流。
  • 关联：当关联的资源达到阈值时，就限流自己。（比如：自己是下单接口，当支付接口达到阈值时，限流下单接口）
  • 链路：只记录指定链路上的流量（指定资源从入口资源进来的流量，如果达到阈值，就进行限流）【api 级别的针对来源】
• 流控效果
  • 快速失败：直接失败，抛异常。
  • Warm up（预热）：预热冷启动方式。当系统长期处于低水位的情况下，流量突增，直接会将系统拉升到高水位，可能瞬间把系统压垮。通过“预热”，让流量缓慢增加，在一定的时间内逐渐增加到阈值上限，给冷系统一个预热的时间。根据 codeFactor（冷加载因子，默认 3）的值，从阈值/ codeFactor，经过预热时长，才达到设置的 QPS 阈值。
  • 排队等待：匀速排队，让请求以匀速通过，阈值类型必须设置为 QPS，否则无效。

直接

针对 testA 接口新增流控规则（系统默认：QPS、直接、快速失败）。

如果 testA 调用 QPS 大于 1，就会快速失败。

注意：QPS 与 并发线程数的区别。

QPS 是站在请求端来看的，每秒的请求数量。

并发线程数是服务端并发使用线程数。如果处理很快，QPS 大于 1，但是使用同一个线程。

关联

当关联的资源达到阈值时，就限流自己。比如：A 是下单接口，B 是支付接口。当支付接口（B）达到阈值时（压力大了），限流下单接口（A）。

如图配置：当 testB 接口的 QPS 达到了 1，限流 testA 接口。

使用 Postman 模拟并发调用 testB 接口，让后看 testA 接口的限流情况。

在 Postman 执行期间，testA 接口被限流了。当 Postman 执行完毕后，testA 接口恢复正常。限流策略生效。

链路

Warm up（预热）

预热冷启动方式。当系统长期处于低水位的情况下，流量突增，直接会将系统拉升到高水位，可能瞬间把系统压垮。通过“预热”，让流量缓慢增加，在一定的时间内逐渐增加到阈值上限，给冷系统一个预热的时间。根据 codeFactor（冷加载因子，默认 3）的值，从阈值/ codeFactor，经过预热时长，才达到设置的 QPS 阈值。

如下图：接口 testA 的 QPS 大于 100 会触发限流。接口 testA 是新接口上线，刚开始 QPS 达到 100/3 就开始限流，在 5 秒内逐步从 100 /3 提升至 100 的 QPS。

排队等待

匀速排队，让请求以匀速通过，阈值类型必须设置为 QPS，否则无效。

这种方式严格控制了请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。

这种方式主要用于处理间隔性突发的流量，例如消息队列。想象一下这样的场景，在某一秒有大量的请求到来，而接下来的几秒则处于空闲状态，我们希望系统能够在接下来的空闲期间逐渐处理这些请求，而不是在第一秒直接拒绝多余的请求。

下图设置含义：接口 testA 每秒处理 100 次请求，QPS 超过 100 就排队等待，等待的超时时间为 500 ms。

熔断规则

容错性设计（Design for Failure）是微服务的一个核心原则。由于某一个服务的崩溃，导致所有用到这个服务的其他服务都无法正常工作，一个点的错误经过层层传递，最终波及调用链上与此相关的所有服务，这便是雪崩效应。如何防止雪崩效应便是微服务架构容错性设计原则的具体实现。

要落实容错性设计这条原则，除了从思想观念上转变过来，正视程序必然是会出错的，并对它进行有计划的防御之外，还必须了解一些常用的容错策略和容错设计模式，作为具体设计与编码实践的指导。这里的容错策略指的是“面对故障，我们该做什么”。Sentinel 提供以下几种熔断策略。

• 慢调用比例 (SLOW_REQUEST_RATIO)：
  • 最大 RT（最大的响应时间）：请求的响应时间大于该值则统计为慢调用
  • 统计时长：当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目，并且慢调用的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断，若大于设置的慢调用 RT 则会再次被熔断。
• 异常比例 (ERROR_RATIO)：当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目，并且异常的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。异常比率的阈值范围是 [0.0, 1.0]，代表 0% - 100%。
• 异常数 (ERROR_COUNT)：当单位统计时长内的异常数目超过阈值之后会自动进行熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。

注意：

• 以上熔断策略，在熔断期间让请求快速失败。
• 上述熔断策略，都有一个最小请求数目的设置，目的是当系统 QPS 不高时，如果发生了异常，其实对系统整体的稳定性影响不大，不需要熔断处理。

慢调用比例

异常比例

异常数

热点参数限流

何为热点？热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据，并对其访问进行限制。比如：

• 商品 ID 为参数，统计一段时间内最常购买的商品 ID 并进行限制
• 用户 ID 为参数，针对一段时间内频繁访问的用户 ID 进行限制

热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制，仅对包含热点参数的资源调用生效。

Sentinel 利用 LRU 策略统计最近最常访问的热点参数，结合令牌桶算法来进行参数级别的流控。

实例

新增带参数据的方法

    @GetMapping("/testHotKey")
		// 热点参数限流,必须使用 SentinelResource，资源名必须是 value
    @SentinelResource(value = "testHotKey")
    public String testHotKey(@RequestParam(value = "p1", required = false) String p1,
                             @RequestParam(value = "p2", required = false) String p2) {
        return "testHotKey";
    }

新增热点规则：testHotKey 接口：

• 参数索引：对第 0 个参数（P1）进行热度限流。
• 单机阈值：QPS 阈值

如果不设置限量后的结果就会抛异常，异常打到前台用户界面，不友好。

自定义限流后的处理结果。

    @GetMapping("/testHotKey")
    @SentinelResource(value = "testHotKey", blockHandler = "deal_testHotKey")
    public String testHotKey(@RequestParam(value = "p1", required = false) String p1,
                             @RequestParam(value = "p2", required = false) String p2) {
        return "testHotKey";
    }

    public String deal_testHotKey(String p1, String p2, BlockException ex) {
        return "deal_testHotKey";
    }

参数例外项

参数例外项：可以针对指定的参数值单独设置限流阈值，不受前面 count 阈值的限制。仅支持基本类型和字符串类型

如下图：

• 正常情况下：p1 相同参数 QPS > 1 会进行限流。
• 特例：当 p1 == “vip” 时，QPS > 200 才会限流。

系统自适应保护

Sentinel 系统自适应保护从整体维度对应用入口流量进行控制，结合应用的 Load、总体平均 RT、入口 QPS 和线程数等几个维度的监控指标，让系统的入口流量和系统的负载达到一个平衡，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。

• Load（仅对 Linux/Unix-like 机器生效）：当系统 load1 超过阈值，且系统当前的并发线程数超过系统容量时才会触发系统保护。系统容量由系统的 maxQps * minRt 计算得出。设定参考值一般是 CPU cores * 2.5。
• CPU usage（1.5.0+ 版本）：当系统 CPU 使用率超过阈值即触发系统保护（取值范围 0.0-1.0）。
• RT：当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护，单位是毫秒。
• 线程数：当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。
• 入口 QPS：当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护。

@SentinelResource

@SentinelResource 用于定义资源，并提供可选的异常处理和 fallback 配置项。 @SentinelResource 注解包含以下属性：

• value：资源名称，必需项（不能为空）
• entryType：entry 类型，可选项（默认为 EntryType.OUT）
• blockHandler / blockHandlerClass: blockHandler 对应处理 BlockException 的函数名称，可选项。blockHandler 函数访问范围需要是 public，返回类型需要与原方法相匹配，参数类型需要和原方法相匹配并且最后加一个额外的参数，类型为 BlockException。blockHandler 函数默认需要和原方法在同一个类中。若希望使用其他类的函数，则可以指定 blockHandlerClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析。
• fallback：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 逻辑中，而是会原样抛出。

实例

创建 CustomerBlockHandler 类用于自定义限流处理逻辑。项目中所有的限流兜底逻辑都写在这个类里。

public class CustomerBlockHandler {
    public static CommonResult hanlderException(BlockException exception) {
        return new CommonResult<>(444, "自定义错误信息 global handlerException", "1");
    }

    public static CommonResult hanlderException2(BlockException exception) {
        return new CommonResult<>(444, "自定义错误信息 global handlerException", "2");
    }
}

import lombok.Data;

@Data
public class CommonResult<T> {
    private int code;
    private String message;
    private T data;

    public CommonResult(int code, String message, T data) {
        this.code = code;
        this.message = message;
        this.data = data;
    }
}

通过：blockHandlerClass 参数找到限流兜底的类

通过：blockHandler 参数找到限流兜底的类中的方法。

    @GetMapping("/testCustomer")
    @SentinelResource(value = "testCustomer",
            blockHandlerClass = CustomerBlockHandler.class,
            blockHandler = "hanlderException2")
    public CommonResult<String> deal_testHotKey(String p1, String p2, BlockException ex) {
        return new CommonResult<>(200, "testCustomer success", "0");
    }

持久化

一旦重启应用，sentienl 规则就丢失了，生产环境需要将配置进行持久化。

方案：将限流规则持久化到 Nacos 中。

新增 mvn 依赖

        <!--SpringCloud ailibaba sentinel-datasource-nacos 后续做持久化用到-->
        <dependency>
            <groupId>com.alibaba.csp</groupId>
            <artifactId>sentinel-datasource-nacos</artifactId>
        </dependency>

新增 yml 配置

server:
  port: 8401

spring:
  application:
    name: cloudalibaba-sentinel-service
  cloud:
    nacos:
      discovery:
        #Nacos服务注册中心地址
        server-addr: 127.0.0.1:8848
    sentinel:
      transport:
        #配置Sentinel dashboard地址
        dashboard: 127.0.0.1:8080
        #默认8719端口，假如被占用会自动从8719开始依次+1扫描,直至找到未被占用的端口
        port: 8719
      datasource:
        ds1:
          nacos:
            server-addr: 127.0.0.1:8848
            dataId: cloudalibaba-sentinel-service
            groupId: DEFAULT_GROUP
            data-type: json
            rule-type: flow
management:
  endpoints:
    web:
      exposure:
        include: '*'

手动在 Nacos 中添加接口限流信息

流量控制规则：

• resource：资源名称；
• limitApp：来源应用；
• grade：阈值类型，0表示线程数，1表示QPS；
• count：单机阈值；
• strategy：流控模式，0表示直接，1表示关联，2表示链路；
• controlBehavior：流控效果，0表示快速失败，1表示Warm Up，2表示排队等待；
• clusterMode：是否集群。

熔断降级规则：

• resource ：资源名，资源名是限流规则的作用对象，比如请求资源 getUser 。
• grade ：熔断策略，支持慢调用比例/异常比例/异常数策略。1：慢调用比例，2：异常比例，3：异常数。默认为1，慢调用比例。
• count ：慢调用比例模式下为慢调用临界 RT（超出该值计为慢调用）；异常比例/异常数模式下为对应的阈值。
• timeWindow ：熔断时长，单位为秒。
• minRequestAmount：熔断触发的最小请求数，请求数小于该值时即使异常比率超出阈值也不会熔断。默认为 5 。
• statIntervalMs ：统计时长（单位为 ms），如 60*1000 代表分钟级。默认为 1000 ms。
• slowRatioThreshold：慢调用比例阈值，仅慢调用比例模式有效

之后再重启服务：流控规则中已经用了 Nacos 中添加的流控规则。

注意：此时数据只能从 Nacos 单向 Sentinel 推送，不能从 Sentinel 向 Nacos 推送。

热点规则

[
  {
  	// 资源名
    "resource": "/test1",
    // 限流模式（QPS 模式，不可更改）
    "grade": 1,
    // 参数索引
    "paramIdx": 0,
    // 单机阈值
    "count": 13,
    // 统计窗口时长
    "durationInSec": 6,
    // 是否集群 默认false
    "clusterMode": 默认false,
    // 
    "burstCount": 0,
    // 集群模式配置
    "clusterConfig": {
      // 
      "fallbackToLocalWhenFail": true,
   	  // 
      "flowId": 2,
      // 
      "sampleCount": 10,
      // 
      "thresholdType": 0,
      // 
      "windowIntervalMs": 1000
    },
    // 流控效果（支持快速失败和匀速排队模式）
    "controlBehavior": 0,
    // 
    "limitApp": "default",
    // 
    "maxQueueingTimeMs": 0,
    // 高级选项
    "paramFlowItemList": [
      {
      	// 参数类型
        "classType": "int",
      	// 限流阈值
        "count": 222,
      	// 参数值
        "object": "2"
      }
    ]
  }
]

系统规则

[
  {
  	// RT
    "avgRt": 1,
    // CPU 使用率
    "highestCpuUsage": -1,
    // LOAD
    "highestSystemLoad": -1,
    // 线程数
    "maxThread": -1,
    // 入口 QPS
    "qps": -1
  }
]

授权规则

[
  {
    // 资源名
    "resource": "sentinel_spring_web_context",
  	// 流控应用
    "limitApp": "/test",
    // 授权类型(0代表白名单；1代表黑名单。)
    "strategy": 0
  }
]

双向推送

生产环境的 Sentinel Dashboard 需要具备下面几个特性:

• 规则管理及推送，集中管理和推送规则。sentinel-core 提供 API 和扩展接口来接收信息。开发者需要根据自己的环境，选取一个可靠的推送规则方式；同时，规则最好在控制台中集中管理。
• 监控，支持可靠、快速的实时监控和历史监控数据查询。sentinel-core 记录秒级的资源运行情况，并且提供 API 来拉取资源运行信息。当机器大于一台以上的时候，可以通过 Dashboard 来拉取，聚合，并且存储这些信息。这个时候，Dashboard 需要有一个存储媒介，来存储历史运行情况。
• 权限控制，区分用户角色，来进行操作。生产环境下的权限控制是非常重要的，理论上只有管理员等高级用户才有权限去修改应用的规则。

规则管理及推送

推送模式	说明	优点	缺点
原始模式	API 将规则推送至客户端并直接更新到内存中，扩展写数据源	简单，无任何依赖	不保证一致性；规则保存在内存中，重启即消失。严重不建议用于生产环境
Pull 模式	扩展写数据源， 客户端主动向某个规则管理中心定期轮询拉取规则，这个规则中心可以是 RDBMS、文件 等	简单，无任何依赖；规则持久化	不保证一致性；实时性不保证，拉取过于频繁也可能会有性能问题。
Push 模式	扩展读数据源，规则中心统一推送，客户端通过注册监听器的方式时刻监听变化，比如使用 Nacos、Zookeeper 等配置中心。这种方式有更好的实时性和一致性保证。生产环境下一般采用 push 模式的数据源。	规则持久化；一致性；快速	引入第三方依赖

原始模式

如果不做任何修改，Dashboard 的推送规则方式是通过 API 将规则推送至客户端并直接更新到内存中：

这种做法的好处是简单，无依赖；坏处是应用重启规则就会消失，仅用于简单测试，不能用于生产环境。

Pull 模式

pull 模式的数据源（如本地文件、RDBMS 等）一般是可写入的。使用时需要在客户端注册数据源：将对应的读数据源注册至对应的 RuleManager，将写数据源注册至 transport 的 WritableDataSourceRegistry 中。以本地文件数据源为例：

public class FileDataSourceInit implements InitFunc {

    @Override
    public void init() throws Exception {
        String flowRulePath = "xxx";

        ReadableDataSource<String, List<FlowRule>> ds = new FileRefreshableDataSource<>(
            flowRulePath, source -> JSON.parseObject(source, new TypeReference<List<FlowRule>>() {})
        );
        // 将可读数据源注册至 FlowRuleManager.
        FlowRuleManager.register2Property(ds.getProperty());

        WritableDataSource<List<FlowRule>> wds = new FileWritableDataSource<>(flowRulePath, this::encodeJson);
        // 将可写数据源注册至 transport 模块的 WritableDataSourceRegistry 中.
        // 这样收到控制台推送的规则时，Sentinel 会先更新到内存，然后将规则写入到文件中.
        WritableDataSourceRegistry.registerFlowDataSource(wds);
    }

    private <T> String encodeJson(T t) {
        return JSON.toJSONString(t);
    }
}

本地文件数据源会定时轮询文件的变更，读取规则。这样我们既可以在应用本地直接修改文件来更新规则，也可以通过 Sentinel 控制台推送规则。以本地文件数据源为例，推送过程如下图所示：

首先 Sentinel 控制台通过 API 将规则推送至客户端并更新到内存中，接着注册的写数据源会将新的规则保存到本地的文件中。使用 pull 模式的数据源时一般不需要对 Sentinel 控制台进行改造。

这种实现方法好处是简单，不引入新的依赖，坏处是无法保证监控数据的一致性。

Push 模式

生产环境下一般更常用的是 push 模式的数据源。对于 push 模式的数据源,如远程配置中心（ZooKeeper, Nacos, Apollo等等），推送的操作不应由 Sentinel 客户端进行，而应该经控制台统一进行管理，直接进行推送，数据源仅负责获取配置中心推送的配置并更新到本地。因此推送规则正确做法应该是 配置中心控制台/Sentinel 控制台 → 配置中心 → Sentinel 数据源 → Sentinel，而不是经 Sentinel 数据源推送至配置中心。这样的流程就非常清晰了：

从 Sentinel 1.4.0 开始，Sentinel 控制台提供 DynamicRulePublisher 和 DynamicRuleProvider 接口用于实现应用维度的规则推送和拉取，并提供了相关的示例。Sentinel 提供应用维度规则推送的示例页面（/v2/flow），用户改造控制台对接配置中心后可直接通过 v2 页面推送规则至配置中心。改造详情可参考 应用维度规则推送示例。

改造 Sentinel Dashbord

1. 下载 sentinel 源码，导入 idea 工程。主要改造 sentinel-dashbord 模块。

git clone https://github.com/alibaba/Sentinel.git

2. 在 pom.xml 文件中去掉 test scope 注释

 <!-- for Nacos rule publisher sample -->
        <dependency>
            <groupId>com.alibaba.csp</groupId>
            <artifactId>sentinel-datasource-nacos</artifactId>
            <!--<scope>test</scope>-->
        </dependency>

3. 修改前端路由配置（sidebar.html）

  <!--<li ui-sref-active="active" ng-if="!entry.isGateway">
            <a ui-sref="dashboard.flowV1({app: entry.app})">
              <i class="glyphicon glyphicon-filter"></i>&nbsp;&nbsp;流控规则</a>
          </li>-->
          <!-- 修改为flow，直接调用FlowControllerV2 -->
          <li ui-sref-active="active" ng-if="!entry.isGateway">
            <a ui-sref="dashboard.flow({app: entry.app})">
              <i class="glyphicon glyphicon-filter"></i>&nbsp;&nbsp;流控规则</a>
          </li>

这样就可以通过js跳转至FlowControllerV2了

      .state('dashboard.flow', {
          templateUrl: 
						

							上一篇：							
								香港服务器上哪种硬盘运行速度最快？							
						
						

							下一篇：							
								[阅读笔记 - 解密超大规模集成电路设计方法] 问题 6：实现超大规模集成电路（VLSI）设计的主要方法是什么？