Sentinel Usage

2024-06-29
7 min read

Sentinel 是阿里巴巴开源的面向分布式服务架构的 流量防护 组件。它以流量为切入点，从 流量控制、熔断降级、系统负载保护 等多个维度保障服务稳定性。

Introduction

  1. 为什么需要 Sentinel

    微服务拆分后，单个接口的异常可能沿调用链扩散，引发雪崩。Sentinel 在调用链路上做三件事：

    1. 事前预防 ：通过流控、热点限流限制流量规模，避免系统被突发请求压垮。
    2. 事中隔离 ：通过熔断在下游不稳定时快速失败，切断故障传播。
    3. 事后兜底 ：通过系统保护在 CPU、负载、RT 等整体指标恶化时，从入口层面保护应用。

  2. 核心概念

    理解 Sentinel 只需抓住两个概念：

    概念 含义 举例
    资源 被 Sentinel 保护的一段代码或接口 Controller 方法、Service 方法、任意代码块
    规则 围绕资源设定的防护策略 流控规则、熔断规则、热点规则、系统规则

    资源与规则的关系：先定义 资源 ，再为资源配置 规则 。规则可在控制台动态下发，也可在代码中加载。

  3. 整体架构

    Sentinel 由两部分组成：

    • 核心库（客户端） ：嵌入业务应用，负责统计流量、执行规则、上报监控。不依赖框架，Java 7+ 即可运行。
    • 控制台（Dashboard） ：独立部署的 Web 应用，负责规则配置、实时监控、机器列表展示。

安装（服务端）

  1. 下载与启动

    从 Sentinel GitHub 下载 release 包 。

    控制台默认将规则保存在内存中，重启后配置丢失。生产环境应将规则持久化到 Nacos 等外部存储，由客户端拉取。

  2. Sentinel Dashboard 启动脚本

    #!/bin/bash
nohup /root/skytech-app/jdk-11.0.11/bin/java \
-Dserver.port=8858 \
-Dcsp.sentinel.dashboard.server=localhost:8858 \
-Dproject.name=sentinel-dashboard \
-Dsentinel.dashboard.auth.username=sentinel \
-Dsentinel.dashboard.auth.password=sentinel \
-jar sentinel-dashboard-1.8.10.jar &

tail -f nohup.out

    启动后访问 http://localhost:8858 进入控制台。

应用接入（客户端）

  1. 添加依赖

    与 Spring Cloud 的整合通过 spring-cloud-starter-alibaba-sentinel 实现，该 Starter 包含核心库、Spring 整合模块及与控制台通信的能力。

    <dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

  2. 配置 Sentinel

    在 application.yml 中配置控制台连接信息：

    spring:
  application:
    name: skytech-app
  cloud:
    sentinel:
      transport:
        dashboard: 10.100.10.178:8858
        port: 8719
      eager: true

    配置项说明：

    • spring.cloud.sentinel.transport.dashboard ：Sentinel 控制台地址。
    • spring.cloud.sentinel.transport.port ：客户端本地端口，Sentinel 在此端口启动 HTTP Server 与控制台通信；若被占用会自动 +1 重试。
    • spring.cloud.sentinel.eager ：是否在启动时立即注册到控制台。默认为 false （首次调用时才注册）；设为 true 可在启动后立刻在控制台看到该服务。
    • 默认情况下，所有 Controller 接口会自动注册为监控资源，无需额外注解即可在控制台看到 QPS 等指标。

  3. 配置持久化

    限流规则可存储在 Nacos 中。在 客户端 应用里配置 Nacos 数据源，应用启动后会自动拉取并监听变更：

    可在 application.yml 中配置（Spring Cloud Alibaba 方式）：

    spring:
  cloud:
    sentinel:
      datasource:
        flow:
          nacos:
            server-addr: localhost:8848
            data-id: ${spring.application.name}-flow-rules
            group-id: DEFAULT_GROUP
            rule-type: flow

    Nacos 中存储的 JSON 格式与控制台导出的流控规则一致，修改后会自动推送到客户端。

  4. 定义资源的方式

    Sentinel 支持三种方式定义资源，按推荐程度排列：

    1. 注解 ： @SentinelResource ，适合 Controller / Service 方法，语义清晰。
    2. API ： SphU.entry() / SphU.exit() ，适合非 Spring 场景或细粒度代码块。
    3. 自动埋点 ：Spring MVC 适配器自动将 @RequestMapping 映射为资源，零代码接入。

指标说明

Sentinel 控制台提供秒级实时监控。理解指标是调参的前提：

指标名称 说明
通过 QPS 每秒通过流控 / 熔断检查、实际执行的请求数
拒绝 QPS 每秒被规则拦截的请求数
响应时间（RT） 资源调用的平均响应时间（毫秒）
线程数 当前资源正在执行的并发线程数
分钟通过 最近一分钟内通过的请求总数
分钟拒绝 最近一分钟内被拒绝的请求总数

流控

  1. 概述

    流量控制（Flow Control）是 Sentinel 最核心的能力：监控资源的 QPS 或并发线程数，超过阈值时按策略拦截或排队，避免瞬时高峰冲垮服务。

  2. 四种防护能力对比

    在进入各章节细节前，先明确 Sentinel 四类规则的职责边界：

    规则类型 作用范围 触发条件 典型场景
    流控 单个资源 QPS / 线程数超阈值 接口限流、秒杀削峰
    熔断 单个资源 慢调用 / 异常比例 / 异常数超阈值 下游超时、故障隔离
    热点 单个资源的某个参数值 热点参数 QPS 超阈值 热门商品、恶意刷单用户
    系统保护 整个应用入口 CPU / Load / RT / QPS / 线程数超阈值 全局兜底，防止整体过载

  3. 流控规则要素

    流控规则由以下字段组成：

    • resource ：资源名，规则作用对象。
    • grade ：阈值类型。 FLOW_GRADE_QPS （按 QPS）或 FLOW_GRADE_THREAD （按并发线程数）。
    • count ：阈值数值。
    • *strategy*：调用关系策略：
      • STRATEGY_DIRECT ：直接对当前资源限流。
      • STRATEGY_RELATE ：关联资源达到阈值时，限流当前资源。
      • STRATEGY_CHAIN ：关联资源达到阈值时，按调用链路入口限流当前资源。
    • controlBehavior ：流控效果：
      • CONTROL_BEHAVIOR_DEFAULT ：快速失败，抛出 FlowException 。
      • CONTROL_BEHAVIOR_WARM_UP ：预热，冷启动时流量缓慢升至阈值。
      • CONTROL_BEHAVIOR_RATE_LIMITER ：匀速排队，对应令牌桶算法。

  4. 令牌桶与漏桶

    Sentinel 的排队等待和热点参数限流基于 令牌桶算法 ：

    • 系统以固定速率向桶中放入令牌，桶容量有上限，满了则丢弃多余令牌。
    • 请求到达时需取走一枚令牌才能通过；无令牌则拒绝或排队。
    • 生成速率决定长期平均吞吐，桶容量决定可承受的突发量。

    与 漏桶算法 对比：漏桶严格控制流出速率，无法消化突发；令牌桶允许在桶满时一次性处理突发，更贴近真实业务。

  5. 三种流控模式

    1. 直接模式

      对当前资源直接限流。例如 QPS 阈值设为 100 ，超过即拒绝。

    2. 关联模式

      当 关联资源 达到阈值时，限流 当前资源 。典型场景：写库压力大时，限流读操作以保证写操作优先。

      资源 A（读操作） ──关联──▶ 资源 B（写操作）
当资源 B 的 QPS 超过阈值时，限制资源 A 的访问

    3. 链路模式

      按调用链路入口限流。例如资源 C 同时被入口 A 和入口 B 调用，若只想限制 A → C 这条链路的流量，使用链路模式并指定入口资源。

      无论哪种模式，Sentinel 只能针对 当前应用内 的资源流控，无法跨应用限流。跨服务限流需在网关层（如 Spring Cloud Gateway + Sentinel）实现。

  6. 三种流控效果

    1. 快速失败

      默认方式。QPS 或线程数超阈值时直接拒绝，抛出 FlowException 。适合需要精确控制、不允许排队的场景。

    2. Warm Up（预热）

      冷启动时允许通过的流量从较低值逐步升至阈值。初始阈值约为 count / coldFactor （ coldFactor 默认为 3 ）。

      适合秒杀等场景：活动开始瞬间流量暴增，预热可避免冷系统直接被峰值打垮。

    3. 排队等待

      严格控制请求通过间隔，让流量匀速通过。适合消息削峰、定时任务突发等可容忍短暂等待的场景。

熔断

  1. 概述

    熔断降级（Circuit Breaking）用于应对微服务雪崩：当下游服务不稳定（响应慢、异常多）时，暂停调用并快速返回 fallback，避免故障沿调用链扩散。待下游恢复后，通过半开探测逐步恢复调用。

  2. 熔断策略

    Sentinel 支持三种熔断策略，均基于滑动窗口统计：

    1. 慢调用比例 ：

      • 响应时间超过 maxAllowedRt 的请求视为慢调用。
      • 当慢调用比例超过 ratioThreshold 且请求数 ≥ minRequestAmount 时触发熔断。
      • statIntervalMs*：统计窗口时长，默认 *1000 ms。

    2. 异常比例*（ *ERROR_RATIO ）：

      • 异常请求占总请求的比例超过 ratioThreshold 且请求数 ≥ minRequestAmount 时触发。
      • statIntervalMs*：统计窗口时长，默认 *1000 ms。

    3. 异常数*（ *ERROR_COUNT ）：

      • 统计窗口内异常总数超过 count 时触发。
      • statIntervalMs*：统计窗口时长，默认 *1000 ms。

热点

  1. 概述

    热点参数限流（ParamFlow）针对 方法入参 做细粒度控制：统计参数中的热点值（如某个商品 ID、用户 ID），对高频参数单独限流。Sentinel 用 LRU 策略识别最近最常访问的参数值，并结合令牌桶算法控制通过速率。

  2. 适用场景

    • 商品 ID 限流 ：某爆款商品被恶意刷新，只限该 ID 的请求，不影响其他商品。
    • 用户 ID 限流 ：限制单个用户的访问频率，防止刷单。
    • 地区 / 渠道限流 ：对特定地区或渠道的请求单独设阈值。

系统保护

  1. 概述

    系统自适应保护（System Rules）从 应用整体 维度控制入口流量，不针对单个资源。当 Load、CPU、平均 RT、入口 QPS 或并发线程数等指标超过阈值时，从入口层面拒绝新请求，在最大吞吐与系统稳定之间取得平衡。

  2. 系统保护维度

    • Load ：系统 load1 超过阈值时触发，仅在 Linux / Unix 上有效。参考值： CPU 核数 × 2.5 。
    • CPU 使用率 ：CPU 使用率超过阈值（ 0.0 ~ 1.0 ）时触发。
    • 平均 RT ：所有入口流量的平均响应时间超过阈值（毫秒）时触发。
    • 并发线程数 ：所有入口流量的并发线程数超过阈值时触发。
    • 入口 QPS ：所有入口流量的 QPS 超过阈值时触发。

    与流控、熔断不同，系统规则是 全局 的：任一维度达到阈值即触发，对所有入口资源生效。

    配置建议：

    • 多个维度可同时配置，任一触发即生效。
    • 系统保护适合作为 兜底策略 ，在单资源流控 / 熔断无法覆盖时防止整体过载。
    • 阈值需结合压测与线上监控持续调优，不宜照搬默认值。
#Java
Previous H2 Usage
Next Ftp Resume Transfer

See Also

Ftp Resume Transfer
DeferredResult 使用指南
Maven 项目骨架
Clickhouse Tutorial
ElasticSearch Part1
Mybatis Config 雪花算法id，用 redis 管理 workerId