Sentinel：流量控制+熔断降级组件
目录
一、概念
1.1 概念
1.2 核心价值
1.3 核心特性与功能
1.4 功能边界
1.5 应用场景
1.6 与 Hystrix 对比
二、原理
2.1 核心概念
2.2 整体架构
2.2.1 核心库
2.2.2 控制台
2.3 工作流程
2.4 核心原理
2.4.1 流量控制原理
2.4.2 熔断降级原理
2.4.3 动态规则源
三、使用
3.1 环境搭建与部署
3.2 应用集成与规则配置
3.3 集成与配置
3.4 生产环境实践
3.4.1 规则持久化（至关重要！）
3.4.2 适配主流框架
3.4.3 监控与可视化
3.4.4 集群流控
3.5 配置项详解
一、概念
1.1 概念
Sentinel 是阿里巴巴开源的，一个以流量为切入点，提供流量控制、熔断降级、系统负载保护等一系列服务的轻量级高性能库。它的核心目标是保障微服务的稳定性和容错性，防止服务因瞬间的流量激增（如秒杀、双十一）、依赖服务不稳定或自身处理能力下降而导致系统雪崩。
可以把它理解为一个微服务的“交警”或“保险丝”。
-
交警（流量控制）：在繁忙的路口，交警会根据路况实时调整信号灯，控制不同方向的车流，防止交通瘫痪。Sentinel 就是微服务路口的交警，它控制着访问服务的请求流量QPS（每秒查询率），防止某个服务被突如其来的巨大流量冲垮。
-
保险丝（熔断降级）：当家里的电路短路或过载时，保险丝会自动熔断，切断电流，保护整个电路和电器。Sentinel 就是微服务电路的保险丝，当某个被调用的服务响应缓慢或失败率过高时，它会“熔断”对该服务的调用，快速返回一个预设的降级方案（fallback），避免资源被耗尽导致整个系统雪崩。
核心工作原理：定义资源 -> 定义规则 -> 实时监控和拦截。开发者通过代码或配置将需要保护的业务逻辑（如一个API接口、一个Service方法）定义为一个“资源”，然后为这个资源配置各种规则（如QPS阈值、响应时间、异常比例等）。Sentinel 会在运行时实时监控对这些资源的访问，一旦触发了规则，就立即采取相应的保护措施（如直接拒绝、排队等待、自动降级等）。
1.2 核心价值
Sentinel 的核心价值在于为分布式系统提供了 “韧性”（Resiliency） 能力。具体体现在：
-
可靠性 (Reliability)：
-
防止服务雪崩：通过熔断和隔离机制，将一个后端子服务的故障控制在一定范围内，避免故障向上蔓延，导致整个调用链路上的所有服务都崩溃。这是其最核心的价值。
-
-
可用性 (Availability)：
-
削峰填谷，应对突发流量：在秒杀、大促等场景下，通过流量控制（特别是“匀速排队”模式）将突发的巨大流量平滑成均匀的、服务能够处理的流量，既保证了系统不被冲垮，又最大限度地处理了请求。
-
优雅服务降级：当非核心服务不可用时，可以提供有损但可用的服务。例如，商品详情页的评论服务挂了，可以暂时不显示评论，而不是让整个页面都无法访问。
-
-
实时性 (Real-time)：
-
秒级监控和洞察：提供开箱即用的实时监控面板，可以清晰地看到每个资源的访问情况（QPS、响应时间、拒绝数量、异常数量等），帮助开发者快速发现系统瓶颈和异常点。
-
-
生态与易用性 (Ecosystem & Usability)：
-
丰富的生态集成：与 Spring Cloud、Dubbo、gRPC 等主流微服务框架无缝集成，几乎可以做到开箱即用，接近零成本接入。
-
多种规则配置方式：支持通过代码（硬编码）、本地文件、动态配置中心（如 Nacos, ZooKeeper, Apollo）等多种方式管理和推送规则，规则变更实时生效。
-
扩展性：提供了丰富的 SPI 接口，允许开发者自定义扩展（如自定义流量控制效果、数据源、适配器等）。
-
与另一款流行的容错库 Netflix Hystrix 相比，Sentinel 的设计理念更现代化：
-
Hystrix 侧重于隔离和熔断（通过线程池或信号量隔离），其监控需要依赖 Turbine。
-
Sentinel 则更侧重于丰富的流量控制手段和实时的监控，并且以“资源”为中心，概念更统一，功能也更全面。
1.3 核心特性与功能
1. 流量控制 (Flow Control)
这是 Sentinel 最基础也是最重要的功能。它通过不同的策略和指标来控制流量的通过速率，防止服务被瞬间的流量冲垮。
-
基于 QPS/并发数的流量控制：可以设置某个资源（如一个API接口）每秒最多能处理的请求数或同时处理的线程数。
-
流控模式：
-
直接：针对当前资源本身进行限流。
-
关联：当关联的资源达到阈值时，就限流自己。例如，“写”操作过于频繁时，可以限制“读”操作，避免读操作影响写操作。
-
链路：只针对从某个入口资源（Entry）来的流量进行限流。
-
-
流控效果：
-
快速失败：直接抛出
FlowException异常，这是默认方式。 -
Warm Up（冷启动）：让流量缓慢增加，逐渐达到阈值上限。适用于系统冷启动时，防止突然的洪峰流量将系统压垮。
-
排队等待：让多余的请求排队等待，匀速通过。这相当于以“漏桶”算法进行流量整形，可以处理脉冲流量，保证服务的平稳性。
-
2. 熔断降级 (Circuit Breaking & Downgradation)
当某个依赖服务（如下游的某个API）变得不稳定（表现为响应时间变长、异常比例升高）时，Sentinel 会对其进行熔断，避免本服务被拖垮，并提供降级策略。
-
熔断策略：
-
慢调用比例 (
SLOW_REQUEST_RATIO)：如果请求的响应时间超过设定的阈值，且慢调用的比例超过设定值，则触发熔断。 -
异常比例 (
ERROR_RATIO)：如果请求的异常比例超过阈值，则触发熔断。 -
异常数 (
ERROR_COUNT)：在统计时间内，如果异常数量超过阈值，则触发熔断。
-
-
降级：熔断触发后，在一段时间内（熔断时长），所有对该资源的调用都会自动被拒绝（快速失败），并调用用户自定义的降级方法（Fallback Method）返回一个托底数据，而不是一直等待或抛出异常给上游。过了熔断时间后，会进入“半开状态”，尝试放行一个请求，如果成功则关闭熔断，恢复链路。
3. 系统自适应保护 (System Adaptive Protection)
Sentinel 不仅关注单个服务的流量，还能从整个系统的维度（如 Load、CPU 使用率、总体平均 RT、入口 QPS 和线程数等）进行保护。
-
它有一个 “哨兵” 的角色，实时监控系统的各项指标。
-
当系统负载过高、CPU 使用率过载时，Sentinel 会自动触发全局的流量控制，只允许必要的流量进入系统，牺牲部分非核心功能，保住核心功能的可用性，实现“弃卒保帅”。
4. 实时监控与控制台 (Dashboard)
Sentinel 提供了一个非常精美的控制台（Dashboard），这是其一大亮点。
-
实时监控：可以实时查看接入应用的集群机器数量、每秒请求数、异常数量等信息。
-
规则管理与推送：可以在控制台上动态地配置各种流控、降级规则，并实时生效，无需重启应用。规则可以配置到具体某个API，粒度非常细。
-
机器发现：自动发现客户端，管理客户端推送的规则。
5. 热点参数限流 (Hotspot Parameter Flow Control)
这是更细粒度的流量控制。它可以精确到参数值，比如：
-
对某个商品ID
id=123的访问频率进行限制，而不影响其他商品ID的访问。 -
对某个用户ID
userId=abc的频繁操作进行限制。
这对于防止热点数据被刷、防止恶意用户攻击非常有效。
1.4 功能边界
-
API 网关 ： Sentinel 是一个客户端/应用内的库，它不具备网关的路由、认证、聚合、协议转换等核心功能。它通常与 API 网关（如 Spring Cloud Gateway, Zuul）协同工作，在网关上做全局流控，在微服务内部做细粒度流控。
-
服务发现与注册 ： 它不负责服务的注册与发现，这部分功能由 Nacos、Eureka、Consul 等组件承担。
-
配置中心 ： 虽然它可以从 Nacos、Apollo 等读取规则，但它本身不是一个通用的配置管理中心。
-
分布式事务 ： 不解决数据一致性问题。
-
日志与链路追踪 ： 它的监控侧重于实时指标（Metrics），而非详细的日志（Logs）和调用链（Tracing）。这部分需要与 ELK、SkyWalking、Zipkin 等工具配合使用。
1.5 应用场景
-
电商大促（秒杀、抢购）
-
场景：零点秒杀开始，瞬时流量是平时的成百上千倍。
-
应用：在商品详情页、下单接口等关键资源上设置 QPS 阈值，超过的请求直接拒绝并返回“活动太火爆，请稍后再试”的友好提示。使用 匀速排队 模式，让服务器按处理能力逐个处理请求，避免瞬间高并发打垮数据库。
-
-
防止下游服务故障导致雪崩
-
场景：服务A调用服务B，服务B因数据库压力大导致响应极慢。
-
应用：在服务A调用服务B的资源上设置熔断降级规则（如：平均RT > 2s 或异常比例 > 50% 则熔断5秒）。当规则触发，服务A会快速失败（直接调用降级逻辑，如返回缓存数据或静态提示），而不会让大量线程阻塞在等待服务B的响应上，从而保护了服务A本身乃至整个系统的稳定性。
-
-
根据系统负载进行保护
-
场景：服务器CPU突然飙升至90%以上，或系统负载（Load）异常高。
-
应用：配置系统保护规则，当整个服务器的CPU使用率超过80%时，自动触发限流，优先保证系统不死机，丢弃部分请求，弃车保帅。
-
-
热点数据防刷
-
场景：某款热门新品的详情页被频繁刷新，或者某个用户ID被恶意刷接口。
-
应用：使用热点参数限流，对商品ID或用户ID这个参数进行统计，限制单个热点参数值的访问频率。
-
-
灰度发布与金丝雀发布
-
场景：新版本服务上线，希望先让一小部分流量过来进行测试。
-
应用：可以通过 Sentinel 的限流功能，控制只有5%的流量会路由到新版本的服务实例上，待验证无误后再逐步放量。
-
1.6 与 Hystrix 对比
| 特性 | Sentinel | Hystrix |
|---|---|---|
| 核心机制 | 基于滑动窗口的真实时间实时指标统计，响应更快。 | 基于线程池/信号量隔离和时间窗口聚合。 |
| 隔离策略 | 并发线程数限流（信号量隔离），轻量级，无额外开销。 | 线程池隔离 和 信号量隔离。线程池隔离资源开销大，但隔离更彻底。 |
| 熔断降级策略 | 基于响应时间、异常比例、异常数，更丰富。 | 基于错误百分比。 |
| 实时监控 | 提供开箱即用的控制台，实时查看监控数据和管理规则。 | 需配合 Turbine 和 Dashboard 使用，配置较复杂。 |
| 规则配置 | 支持动态配置，可通过控制台、文件、Apollo/Nacos 等配置中心实时推送。 | 规则一般在代码中静态配置，修改需重启应用。 |
| 系统自适应保护 | 支持，能从整体系统维度进行防护。 | 不支持。 |
| 热点限流 | 支持。 | 不支持。 |
| 社区生态 | 活跃，是阿里巴巴和 Spring Cloud Alibaba 体系的核心组件。 | 维护模式（Hystrix 已进入维护状态，不再积极开发新功能）。 |
Sentinel 在设计上更现代化，功能更丰富，特别是其动态规则和强大的控制台，使其在易用性和功能性上超越了已进入维护状态的 Hystrix。它现在是 Java 微服务生态中事实上的流量治理标准。
二、原理
2.1 核心概念
-
资源： Sentinel 的关键概念。它可以是 Java 应用程序中的任何东西，例如：一个服务、一个方法、一段代码、甚至一个 URL。只要它可能需要被保护，就可以定义为一个资源。
-
规则： 围绕资源的各种治理规则。Sentinel 通过规则来定义如何保护资源。主要规则包括：
-
流量控制规则： 控制每秒请求数（QPS）或并发线程数。
-
熔断降级规则： 当资源响应慢或不稳定时，进行熔断，避免雪崩。
-
系统保护规则： 根据系统的整体指标（如 LOAD、CPU 使用率、总体平均 RT 等）进行保护。
-
来源访问控制规则： 根据调用来源（如 serviceConsumer）进行黑白名单控制。
-
热点参数规则： 对带有特定参数的资源调用进行精细化的流量控制。
-
-
指标： Sentinel 内部会实时收集资源的运行时数据，例如：QPS、RT（响应时间）、异常比例、线程数、系统负载等。这些指标是规则判断和决策的依据。
-
处理逻辑/降级逻辑 (
BlockHandler/Fallback)： 当资源被限流或熔断时（即被“block”了），执行的逻辑。可以是一个返回默认值的方法，或者抛出一个友好的提示。
2.2 整体架构
Sentinel 的功能可以划分为两大部分：核心库 和 控制台。
2.2.1 核心库
核心库是嵌入在应用程序中的部分，负责资源的定义、规则的校验和运行时数据的收集。它是 Sentinel 的“大脑”和“执行器”。
-
Slot（插槽）： 这是 Sentinel 架构中最核心的设计。整个处理流程被设计成一个 Slot Chain，即责任链模式。每个 Slot 负责完成不同的功能，它们按照顺序依次执行，共同完成一次资源访问的决策。默认的 Slot Chain 包含以下关键的 Slot：
-
NodeSelectorSlot： 负责收集资源的调用路径，并为每个调用来源（Context）创建调用树节点（DefaultNode）和入口节点（EntranceNode）。 -
ClusterBuilderSlot： 负责构建和管理集群节点（ClusterNode）。每个资源对应一个 ClusterNode，用于存储该资源的全局统计信息（不限调用来源）。 -
StatisticSlot： 最关键的 Slot。负责实时统计运行时数据，包括 QPS、RT、线程数、异常计数等。这些数据是后续规则校验的基础。 -
AuthoritySlot： 负责黑白名单规则（来源访问控制）的校验。 -
SystemSlot： 负责系统保护规则的校验。它会检查整个系统的状态（如总 QPS、LOAD 等）。 -
FlowSlot： 负责流量控制规则的校验。 -
DegradeSlot： 负责熔断降级规则的校验。 -
LogSlot： 当规则校验不通过（发生限流或熔断）时，记录阻塞日志。 -
... (其他 Slot)
-
2.2.2 控制台
控制台是一个独立的 Web 应用（Sentinel Dashboard），它不参与规则的决策，主要提供两大功能：
-
规则管理： 推送各种治理规则到各个应用程序的核心库。它支持多种数据源（如内存、文件、Nacos、ZooKeeper、Apollo 等），可以实现规则的集中管理和动态推送。
-
监控展示： 从各个应用程序的核心库拉取实时监控数据，并提供可视化的管理界面，方便用户查看系统状态、机器列表、资源调用情况等。
核心库与控制台的关系是松耦合的。即使控制台宕机，核心库也能独立工作（使用本地默认规则或最后一次推送的规则）。核心库与控制台通过 HTTP API 进行通信。
重要提示：控制台默认只在内存中管理规则。这意味着规则通过控制台下发后，只保存在客户端的内存中。应用重启后规则会丢失！生产环境必须配置规则持久化。
2.3 工作流程
一次资源调用的流程：
当你使用 SphU.entry(resourceName) 尝试进入一个资源时，Sentinel 内部的处理流程如下：
-
创建上下文： 为这次调用创建一个
Context，包含调用来源等信息。 -
执行 Slot Chain：
-
NodeSelectorSlot和ClusterBuilderSlot会初始化或找到该资源对应的统计节点（DefaultNode 和 ClusterNode）。 -
StatisticSlot开始统计。注意：它是先向后传递，等后续 Slot 都执行完了再统计出口数据。 -
请求继续向后传递，依次经过
AuthoritySlot、SystemSlot、FlowSlot、DegradeSlot进行规则校验。-
如果任何一个 Slot 的校验不通过（例如，
FlowSlot发现 QPS 超了），就会抛出一个BlockException异常。流程中断，StatisticSlot会记录这次阻塞，LogSlot会记录日志。 -
如果所有 Slot 的校验都通过，请求会继续执行你的业务代码。
-
-
-
执行业务逻辑： 执行被保护的资源代码。
-
记录出口信息：
-
无论业务代码是正常返回还是抛出异常，最终都会调用
exit方法。 -
exit方法会再次触发StatisticSlot，记录本次调用的响应时间（RT）、完成线程数等出口指标。
-
-
结束： 完成整个调用链。
2.4 核心原理
2.4.1 流量控制原理
Sentinel 的流量控制基于令牌桶和漏桶算法的变体，其核心是：
-
指标统计：
StatisticSlot以高频率（毫秒级）统计资源在过去 1 秒内的请求数（即 QPS）。 -
规则判断：
FlowSlot将实时统计的 QPS（或线程数）与用户预设的规则阈值进行比较。 -
效果控制： Sentinel 提供了丰富的流控效果，而不仅仅是简单的拒绝。
-
直接拒绝： 超出的请求直接抛出
BlockException。 -
Warm Up： 让流量缓慢增加，在一定时间内逐渐提高到阈值上限，防止冷系统被瞬间流量击垮。
-
匀速排队： 将请求以均匀的速度放过，类似于漏桶算法。它可以处理突发的流量，但让请求排队等待，而不是直接拒绝，起到“削峰填谷”的作用。
-
2.4.2 熔断降级原理
Sentinel 的熔断器基于“断路器”模式，其状态机如下：
-
CLOSED： 初始状态，允许请求通过。
-
OPEN： 熔断状态，所有请求都会被拒绝。
-
HALF-OPEN： 半开状态，允许少量试探请求通过。
状态转换的条件：
-
熔断策略：
-
慢调用比例： 如果统计时间窗口内，慢调用（RT 超过阈值）的比例超过设定值，且总请求数超过最小请求数，则触发熔断。
-
异常比例： 如果异常比例超过阈值，且总请求数超过最小请求数，则触发熔断。
-
异常数： 如果异常数量超过阈值，则触发熔断。
-
-
当熔断持续一段时间后（熔断超时时间），断路器会进入
HALF-OPEN状态，尝试放一个请求过去。-
如果该请求成功，则认为故障已恢复，断路器进入
CLOSED状态。 -
如果该请求失败，则继续保持
OPEN状态，并等待下一个熔断超时时间。
-
DegradeSlot 负责检查资源的熔断器状态。如果状态为 OPEN 或 HALF-OPEN 且试探请求未通过，则直接抛出 BlockException。
2.4.3 动态规则源
这是 Sentinel 生产环境使用的关键特性。核心库的 RuleManager 可以从外部数据源（如 Nacos）读取规则。
-
推模式： 控制台修改规则后，通过 Nacos 等配置中心的监听机制，将新规则推送给所有监听该配置的应用程序。
-
拉模式： 应用程序内部会定时从外部数据源拉取最新的规则。
这种方式实现了规则的集中管理和实时生效，无需重启应用。
三、使用
3.1 环境搭建与部署
控制台是一个标准的 Spring Boot应用。
-
下载：从 Sentinel GitHub Releases 页面下载最新版本的
sentinel-dashboard-{version}.jar。 -
启动：
# 默认端口是 8080
java -Dserver.port=8080 -Dcsp.sentinel.dashboard.server=localhost:8080 -jar sentinel-dashboard-{version}.jar# 可以指定其他端口和启动参数，例如设置登录账号密码（默认用户/密码是 sentinel/sentinel）
java -Dserver.port=8858 -Dsentinel.dashboard.auth.username=myadmin -Dsentinel.dashboard.auth.password=mypassword -jar sentinel-dashboard-{version}.jar-
访问：打开浏览器，访问
http://localhost:8080。使用默认账号密码sentinel/sentinel登录。
3.2 应用集成与规则配置
创建一个新的 Spring Boot 项目（或者选择已有的项目）。
- 添加 Maven 依赖
<!-- Sentinel Starter for Spring Cloud Alibaba -->
<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-sentinel</artifactId><version>2022.0.0.0</version> <!-- 请选择与你的 Spring Cloud/Spring Boot 版本兼容的版本 -->
</dependency><!-- 如果你需要整合 Sentinel 和 Web Servlet，通常 starter 已包含，也可显式添加 -->
<dependency><groupId>com.alibaba.csp</groupId><artifactId>sentinel-web-servlet</artifactId>
</dependency><!-- actuator 用于暴露端点，方便 Sentinel 监控 -->
<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-actuator</artifactId>
</dependency>-
配置应用连接控制台
在 application.yml 或 application.properties 中配置。
spring:application:name: your-application-name # 给应用起个名，会在控制台显示cloud:sentinel:transport:dashboard: localhost:8080 # 指定控制台地址和端口port: 8719 # 客户端本地的 HTTP Server 端口，用于与控制台通信，默认 8719，如果被占用会自动递增eager: true # 是否饥饿加载，设为 true 后项目启动即连接控制台，否则需首次访问后才连接
# 暴露 actuator 端点
management:endpoints:web:exposure:include: '*'- 定义资源并进行防护
有几种方式定义资源，推荐使用注解，最简单无侵入。
方式一：使用 @SentinelResource 注解（最常用）
@RestController
public class TestController {@GetMapping("/hello")@SentinelResource(value = "hello", blockHandler = "handleBlock") // value 定义资源名，blockHandler 定义限流/降级处理函数public String hello() {return "Hello, Sentinel!";}// 限流或降级的处理函数，签名需要和原函数一致，最后加一个 BlockException 参数public String handleBlock(BlockException ex) {return "Oops, blocked by Sentinel: " + ex.getClass().getSimpleName();}
}方式二：通过代码定义资源（更灵活）
@RestController
public class TestController {@GetMapping("/test")public String test() {try (Entry entry = SphU.entry("testResource")) {// 被保护的业务逻辑return "Business logic here";} catch (BlockException e) {// 被限流或降级return "Resource is blocked";}}
}3.3 集成与配置
在控制台管理规则：
-
启动 Spring Boot 应用。
-
访问一次资源（例如
curl http://localhost:8080/hello），这样 Sentinel 客户端才会向控制台注册自己。 -
刷新 Sentinel 控制台，在左侧“机器列表”或“簇点链路”中应该能看到应用和
/hello资源。 -
配置规则：
-
在“簇点链路”找到
/hello资源，点击操作栏的“流控”按钮。 -
设置 QPS 阈值为 1（即每秒只能处理 1 个请求）。
-
点击“新增”。
-
-
测试：快速刷新浏览器（每秒超过 1 次），会看到
handleBlock方法返回的“Oops, blocked...”信息。限流生效了！
3.4 生产环境实践
3.4.1 规则持久化（至关重要！）
内存中的规则重启即失效，绝对不能用于生产。需要将规则持久化到外部的数据源，如 Nacos, Apollo, ZooKeeper 等。
以 Nacos 为例：
添加依赖：
<dependency><groupId>com.alibaba.csp</groupId><artifactId>sentinel-datasource-nacos</artifactId>
</dependency>修改配置：在 application.yml 中配置 Nacos 作为数据源。
spring:cloud:sentinel:datasource:ds1: # 数据源名称，可自定义nacos:server-addr: ${nacos.server.addr} # Nacos 服务器地址dataId: ${spring.application.name}-sentinel # 规则 dataId，通常用应用名groupId: DEFAULT_GROUPrule-type: flow # 规则类型：flow(流控), degrade(降级), system(系统), authority(授权), param-flow(热点)ds2:nacos:server-addr: ${nacos.server.addr}dataId: ${spring.application.name}-degrade-sentinelgroupId: DEFAULT_GROUPrule-type: degrade# ... 可以配置多个数据源对应不同规则类型在 Nacos 中创建规则配置：在 Nacos 控制台上创建一个 Data ID 为 your-application-name-sentinel 的配置，内容为 JSON 数组格式的流控规则。
[{"resource": "hello","limitApp": "default","grade": 1, // 0-线程数，1-QPS"count": 1, // 阈值"strategy": 0, // 流控模式：0-直接，1-关联，2-链路"controlBehavior": 0, // 流控效果：0-快速失败，1-Warm Up，2-排队等待"clusterMode": false // 是否集群模式}
]效果：应用启动时，会自动从 Nacos 拉取规则并生效。在 Sentinel Dashboard 上修改规则，也会自动推送到 Nacos 中持久化（需正确配置，新版本 Dashboard 支持）。
3.4.2 适配主流框架
Sentinel 对主流框架提供了无缝集成：
-
Web Servlet：已经通过
sentinel-web-servlet自动整合，所有 URL 接口默认成为资源。 -
Dubbo：添加
sentinel-apache-dubbo-adapter依赖，所有的 Dubbo 服务提供者和消费者都会自动成为资源。 -
Spring Cloud Gateway/Netflix Zuul：添加
sentinel-spring-cloud-gateway-adapter依赖，可以对路由和自定义 API 分组进行限流。
3.4.3 监控与可视化
-
控制台监控：Sentinel Dashboard 提供了丰富的实时监控图表，包括通过QPS、拒绝数、响应时间等。
-
与 Prometheus/Grafana 集成：可以部署 Sentinel Exporter 将监控数据导出到 Prometheus，然后用更强大的 Grafana 看板进行可视化。可以通过 Grafana 等工具建立长期监控告警机制。
3.4.4 集群流控
如果应用是集群部署，单机限流模式（每台机器阈值=总阈值/机器数）不精确（因为流量分配可能不均）。Sentinel 提供了集群流控模式，由一个 Token Server 统一管理整个集群的流量。架构更复杂，但控制更精确。
3.5 配置项详解
| 配置类别 | 配置项 (Key / Field) | 说明 | 默认值 | 备注 |
|---|---|---|---|---|
| 基础配置 | project.name | 应用名称，用于标识当前服务 | 解析 main 函数类名 | 建议手动指定，便于识别和管理 |
csp.sentinel.app.type | 应用类型 | 0 (APP_TYPE_COMMON) | ||
csp.sentinel.metric.file.single.size | 单个监控日志文件的大小 | 52428800 (50MB) | ||
csp.sentinel.metric.file.total.count | 监控日志文件总数上限 | 6 | ||
csp.sentinel.statistic.max.rt | 最大有效响应时间 (ms)，超出按此值记录 | 4900 | ||
| 日志配置 | csp.sentinel.log.dir | Sentinel 日志文件目录 | ${user.home}/logs/csp/ | |
csp.sentinel.log.use.pid | 日志文件名是否加入进程号 (单机多实例时需设为 true) | false | ||
csp.sentinel.log.output.type | 日志输出类型 (file 或 console) | file | ||
| 控制台与传输 | csp.sentinel.dashboard.server | Sentinel 控制台地址 (格式: hostIp:port) | null | 必需配置 |
csp.sentinel.api.port | 本地启动 HTTP API Server 的端口号，用于与控制台交互 | 8719 | 端口冲突会自动探测 | |
csp.sentinel.heartbeat.interval.ms | 向控制台发送心跳包的时间周期 (ms) | null | 使用 HeartbeatSender 默认值 | |
csp.sentinel.heartbeat.client.ip | 心跳包中本机的 IP，多网卡环境有用 | - | 通过 HostNameUtil 解析 | |
| 流量控制规则 | resource | 资源名，规则的作用对象 | - | 必需配置 |
| (FlowRule) | count | 限流阈值 | - | 必需配置 |
grade | 阈值类型：FLOW_GRADE_QPS (QPS) 或 FLOW_GRADE_THREAD (线程数) | FLOW_GRADE_QPS | ||
limitApp | 流控调用来源 (default 代表不区分) | default | ||
strategy | 流控模式：直接、关联、链路 | 直接 | ||
controlBehavior | 流控效果：快速失败、Warm Up、匀速排队 | 快速失败 | ||
| 熔断降级规则 | resource | 资源名，规则的作用对象 | - | 必需配置 |
| (DegradeRule) | count | 熔断阈值 (对于RT策略是响应时间ms，对于比例策略是比例阈值，对于错误数策略是错误数量) | - | 必需配置 |
grade | 熔断策略：DEGRADE_GRADE_RT (慢调用比例), DEGRADE_GRADE_EXCEPTION_RATIO (异常比例), DEGRADE_GRADE_EXCEPTION_COUNT (异常数) | DEGRADE_GRADE_RT | ||
timeWindow | 熔断触发后持续的时间（单位为 ms），或降级的时间（单位为 s） | - | 必需配置 | |
minRequestAmount | 触发熔断的最小请求数目，静默数量 | 5 | ||
statIntervalMs | 统计的时间窗口长度（单位为 ms） | 1000 | ||
retryTimeoutMs | 熔断触发后持续的时间（单位为 ms），即熔断时长 | 1000 | ||
maxAllowedRtMs | 仅慢调用策略有效，判断慢调用的临界响应时间 (ms) | - | ||
| 热点参数规则 | resource | 资源名 | - | 必需配置 |
| (ParamFlowRule) | count | 限流阈值 | - | 必需配置 |
grade | 限流模式 (目前主要为 QPS) | QPS 模式 | ||
paramIdx | 热点参数索引 (对应方法参数位置，0开始) | - | 必需配置 | |
durationInSec | 统计窗口时间长度 (秒) | 1s | ||
controlBehavior | 流控效果 (快速失败、匀速排队) | 快速失败 | ||
paramFlowItemList | 参数例外项，可为特定参数值单独设置限流阈值 | - | ||
| 系统保护规则 | highestSystemLoad | 最大的 load1 (Linux系统有效) | -1 (不生效) | |
| (SystemRule) | avgRt | 所有入口流量的平均响应时间 (ms) | -1 (不生效) | |
maxThread | 入口流量的最大并发数 | -1 (不生效) | ||
qps | 所有入口资源的 QPS | -1 (不生效) | ||
highestCpuUsage | CPU 使用率 (百分比) | -1 (不生效) | ||
| 授权规则 | resource | 资源名 | - | 必需配置 |
| (AuthorityRule) | limitApp | 黑白名单列表 (多个用逗号分隔, 如 appA,appB) | default | |
strategy | 限制模式：AUTHORITY_WHITE (白名单), AUTHORITY_BLACK (黑名单) | AUTHORITY_WHITE |
配置方式：Sentinel 的配置非常灵活，可以通过以下几种方式进行配置。
-
JVM -D 参数：优先级最高，例如
-Dproject.name=myApp -Dcsp.sentinel.dashboard.server=localhost:8080。 -
Properties 文件：默认从
classpath:sentinel.properties读取，编码为 UTF-8。可通过-Dcsp.sentinel.config.file指定文件路径。 -
Spring Cloud Alibaba 配置 (application.yml/application.properties)：如果你在 Spring Cloud 环境中使用，可以直接在应用的配置文件中设置，例如
spring.cloud.sentinel.transport.dashboard=localhost:8080。 -
外部数据源 (推荐生产环境使用)：规则可以通过文件（如 JSON）、Nacos、ZooKeeper、Apollo、Redis 等数据源进行管理和动态加载，实现规则的热更新。这需要引入相应的
sentinel-datasource-extension或具体数据源的依赖（如sentinel-datasource-nacos）。
配置建议与最佳实践
-
应用名称 (
project.name)：务必显式配置，这对于在控制台识别应用和后续的监控排查至关重要。 -
控制台地址 (
csp.sentinel.dashboard.server)：必须正确配置，否则你的应用无法接入 Sentinel 控制台进行可视化管理。 -
规则管理：在生产环境中，强烈建议使用外部数据源（如 Nacos） 来管理规则。这样可以实现规则的集中管理、持久化和动态实时推送，避免规则在应用重启后丢失。
-
日志 PID：当单台机器部署多个相同服务的实例时，设置
-Dcsp.sentinel.log.use.pid=true可以保证每个实例的日志文件名中包含进程 PID，便于区分和诊断。 -
规则细化：配置规则时，资源名要准确，阈值和策略要根据实际的压测结果和业务需求进行仔细调优，避免设置过于激进或宽松。