Sentinel 限流熔断

• route 资源与 API 分组
• 路径参数归一化
• 限流准确性

Sentinel 集成 Gateway 时，可把 route 资源（整个路由）或自定义 API 分组（ApiDefinition）作为限流资源。选择：route 资源粒度粗（整个路由限流），自定义 API 分组粒度细（按 URL 模式/条件分组，如 /api/order/**）。路径参数归一化：把路径中的动态参数（如 /api/order/123 中的 123）归一化为模板（如 /api/order/{id}），否则每个不同 ID 的 URL 会被当成不同资源，产生高基数，导致限流规则失效或误判。归一化保证同一类接口共享同一资源，限流准确。工程上：用自定义 API 分组定义资源模式，对路径参数归一化，避免高基数资源。

资源粒度决定限流精度。路径参数归一化避免高基数资源，保证限流规则按"接口类"生效。这是 Sentinel 网关限流的关键细节。

• QPS 流控（速率）
• 并发线程数流控（占用量）
• 慢调用场景选择

QPS 流控保护"到达速率"——限制单位时间进入的请求数（QPS），适合保护系统承受的请求量；并发线程数流控保护"占用量"——限制同时处理的并发线程数/请求占用量，适合保护系统资源（线程、连接）。慢调用场景应优先选择并发线程数流控：因为慢调用占用的资源时间长，QPS 流控无法感知调用耗时（请求进入后长期占用线程），并发线程数流控能直接限制同时占用的量，避免慢调用堆积拖垮系统。当调用慢时，并发数高，触发并发线程数流控，快速拒绝新请求，保护资源。工程上：慢调用/长耗时场景用并发线程数流控，快调用场景用 QPS 流控。

QPS 管"速率"，并发线程数管"占用量/资源"。慢调用占用资源久，并发线程数流控更能直接保护资源。选择依据是资源占用特征。

• 功能对比
• 性能对比
• 生态与选型

Sentinel 与 Resilience4j 2.x 功能对比：Sentinel 提供流控（QPS/线程/热点/集群）、熔断降级、系统自保护、控制台与动态规则，平台化强；Resilience4j 提供 CircuitBreaker、RateLimiter、Bulkhead、Retry、TimeLimiter 等可组合容错原语，轻量函数式。性能：Sentinel 指标统计在内存中，性能好；Resilience4j 轻量无额外依赖，性能也优。生态：Sentinel 契合 Alibaba 生态（Nacos 规则、控制台、Spring Cloud Alibaba），Resilience4j 契合 Spring Cloud 官方（spring-cloud-starter-circuitbreaker-resilience4j）。选型建议：需要集中管控、动态规则、精细流量治理（多实例、集群流控）选 Sentinel；需要轻量、可组合、纯库、贴合 Spring Cloud 官方、低运维选 Resilience4j。Spring Boot 4.0 中两者都可集成，按治理需求选择。

选型核心是"平台化治理 vs 轻量库"。Sentinel 强于动态规则与平台，Resilience4j 强于轻量与组合。结合团队生态与治理需求。

• 令牌桶限流
• 大模型推理限流
• 配置

Spring AI 2.0 调用大模型（LLM）推理时，可用 Sentinel 令牌桶限流控制调用频率与并发，防止突发请求打爆模型服务或超限。令牌桶限流：Sentinel 的匀速排队/令牌桶模式（FlowRule 的 controller 为 RateLimiterController）控制请求匀速通过，适合大模型推理这类"慢、贵、有频控"的场景。配置：为模型调用资源设置 QPS 阈值，用令牌桶控制速率，防止突发；同时可配合并发线程数流控限制并发推理（大模型推理占资源多）。大模型场景还需考虑：令牌桶限流（平滑速率）+ 排队（避免突发）+ 熔断（模型失败降级）。工程上：按模型服务的容量与成本设置限流，防突发与超限。

大模型推理是"慢、贵、有频控"场景，令牌桶限流平滑速率防突发，并发流控限制资源占用。理解令牌桶对大模型调用的适配。

• Sentinel 与 OTel 集成
• 限流上下文与 Trace
• 关联

Sentinel 与 OpenTelemetry 集成：Sentinel 的限流/熔断事件与 OTel 的 Trace 关联，让"被限流的请求"在链路中可观测。方案：在 Sentinel 的 BlockException 处理处（blockHandler）写入 OTel span 事件/标签（如 resource、rule、blocked），把限流信息关联到当前 Trace；限流上下文通过 OTel 的 Baggage/Context 传播，与 TraceID 关联。Spring Boot 4.0 中，Micrometer Observation + OTel 是默认链路，Sentinel 集成把限流指标（被拒次数、资源）+ 限流 span 关联到 trace。实现：自定义 blockHandler 记录 OTel span，或 Sentinel 的监听器把事件写入 Observation。价值：限流可观测，定位"哪个资源被限流、是否影响业务"。

关联核心是"限流事件写入 Trace"。把 BlockException 映射为 OTel span/标签，让限流在链路中可见。这是可观测性治理的一部分。

• 虚拟线程与 Slot Chain
• 线程挂载与统计
• 漏限流风险

Sentinel 的 Slot Chain 通过 Context（ThreadLocal）把当前请求的统计信息绑定到调用线程。虚拟线程下，每个请求在独立虚拟线程执行，若 Sentinel 的统计（如 QPS 计数、并发数）基于 ThreadLocal 或线程粒度，虚拟线程的创建/销毁可能影响统计准确性。但 Sentinel 的 QPS 统计基于滑动窗口（时间维度），不依赖线程；并发线程数统计基于"当前通过的 entry 数"，也不依赖平台线程。因此虚拟线程下 Slot Chain 不会因线程挂载导致漏限流（统计是时间/计数维度，非线程维度）。注意：虚拟线程下若用 ThreadLocal 存 Context，需正确传递（sentinel 的 AsyncEntry 或显式传播），否则上下文丢失。核心：Sentinel 的统计不依赖线程身份，虚拟线程不导致漏限流。

漏限流的担忧源于"统计是否依赖线程"。Sentinel 用滑动窗口/entry 计数统计，与线程无关，虚拟线程不导致漏限流。上下文传递需处理。

• Sentinel 与 Spring Boot 4 兼容
• 版本对齐
• 集成注意事项

Sentinel 在 Spring Boot 4.x 的兼容性取决于 Spring Cloud Alibaba 版本。Sentinel 通过 spring-cloud-starter-alibaba-sentinel 与 Spring Boot 集成，Boot 4.x 需对应新的 Spring Cloud Alibaba 版本。兼容性关注点：Sentinel 对 Boot 4 的 Jakarta EE 11、虚拟线程、自动配置变化的适配；@SentinelResource、@RestControllerAdvice 的异常处理；Sentinel 数据源（Nacos）与 Boot 4 的兼容。Boot 4.x 中 Sentinel 的注解、规则、监控 API 保持稳定，但底层随 Boot 4 调整。升级需查兼容矩阵，验证 Sentinel 的流控、熔断、数据源在 Boot 4 下正常工作。

兼容性由 Spring Cloud Alibaba 版本决定。Sentinel API 稳定，但 Boot 4 的 Jakarta 与自动配置变化需适配。升级验证核心能力。

• 异常比例策略
• 异常数策略
• 慢调用比例策略

Sentinel 熔断器三种降级策略：异常比例——统计窗口内异常数占比超过阈值（如 20%）触发熔断，适合异常率作为判定；异常数——统计窗口内异常数超过阈值（如 100）触发熔断，适合异常量判定；慢调用比例——统计窗口内响应时间超过阈值的调用占比超过阈值触发熔断，适合慢调用防护。触发熔断后进入 OPEN 状态，经过一定时间（熔断时长）进入 HALF_OPEN 半开，探测恢复。三种策略适用于不同故障表现：异常比例（异常率突增）、异常数（绝对异常量）、慢调用（依赖慢导致）。工程上按故障类型选择策略，设置合理的统计窗口与阈值。

三种策略是"异常率、异常量、慢调用"三种熔断触发依据。理解各自适用场景，按故障特征选择。熔断后半开探测恢复。

• Dashboard 监控与规则管理
• 集群流控
• 工作原理

Sentinel Dashboard 是控制台，提供：实时监控（资源 QPS、线程、异常）、规则管理（流控/熔断/热点规则下发）、集群流控配置。集群流控：解决"单机限流无法保护集群总量"的问题——通过 Token Server（集群令牌服务器）统一分配令牌，对集群整体 QPS 限流，单机限流到各自实例避免总量超限。工作原理：集群内选 Token Server，各客户端向 Token Server 申请令牌，集群流控规则（总量）在 Token Server 管理；Token Server 故障时客户端降级为本地限流。集群流控适合"总量控制"场景（如整体接口只能承受 N QPS）。Dashboard 负责规则管理，集群流控负责总量控制。

Dashboard 是管理面，集群流控是"总量治理"。集群流控解决单机限流的总量瓶颈，Token Server 是核心。理解其降级策略。

• 热点参数限流原理
• 参数索引与阈值
• 应用场景

Sentinel 热点参数限流（ParamFlowRule）针对资源调用中的特定参数进行限流：对同一资源，按参数值（如用户 ID、商品 ID）分别限流，避免某个热点参数值（如热门商品）打爆系统。配置：指定参数索引（paramIdx，第几个参数）、参数值可设阈值（对特定参数值单独限流）、剩余参数设默认阈值。工作原理：统计每个参数值的 QPS，超过阈值则限流该参数值。应用场景：热点商品、热点用户、反爬（按 IP 限流）。热点参数限流能精确控制"某个 key 的流量"，比全局限流更精细。

热点参数限流是"按参数值限流"。针对热点 key 精确防护，避免全局限流过松或过严。参数索引与阈值配置是关键。

• SystemRule 指标
• 采集机制
• 自适应保护

Sentinel 系统自适应限流（SystemRule）根据系统整体指标自适应限流，指标包括：CPU 使用率——SystemRule 采集系统 CPU 使用率，超过阈值则限流；入口 QPS——系统入口 QPS 超过阈值限流；并发线程数——系统总并发线程数超过阈值限流；还有 Load（负载）、RT。采集机制：Sentinel 通过系统监控（SystemStatusListener）采集 CPU、Load、线程数等 system 指标，通过入口统计（Entry）统计入口 QPS 与线程数。自适应保护：当系统指标超阈值（如 CPU 高），Sentinel 自动拒绝新请求，保护系统不过载。适合整体系统的自我保护，防止流量击穿系统。

SystemRule 是"系统级自适应保护"。基于 CPU、Load、入口 QPS、线程数等指标，超阈值自动限流。采集靠系统监控 + 入口统计。

• 限流策略类型
• 冷启动
• 应用场景

Sentinel 限流策略（FlowRule 的 grade）：QPS 限流——按每秒请求数限流，是最常用策略；线程数限流——按并发线程数限流，保护资源占用；冷启动（Warm Up）——控制流量从低到高缓慢增长，避免冷启动时突发流量打爆系统（预热阈值）。还有匀速排队（RateLimiterController）——请求匀速通过，避免突发。各策略适用：QPS 限流适合常规速率控制；线程数限流适合保护线程/资源；冷启动适合服务刚启动、缓存未热、系统未就绪时平滑放量。工程上按业务场景选择限流维度与模式。

限流策略是"按什么维度、什么模式限流"。QPS/线程数是维度，冷启动/匀速排队是模式。冷启动保护系统预热期。

• 秒级指标关联
• 标签基数控制
• 指标采集

Sentinel 秒级指标（QPS、线程、异常、RT）与业务关联：RT 反映业务延迟，线程数反映线程池占用，异常数反映下游错误。通过资源的秒级指标诊断：延迟高→查 RT、慢调用；线程池满→查并发线程数；下游错误→查异常数。关联方式：指标按资源（方法/接口）统计，与业务维度（链路、日志）关联。控制标签基数：指标的标签（label）应使用低基数（low_cardinality），如资源名、结果类型，避免把用户 ID、完整 URL 等作为标签（高基数导致指标爆炸、存储与查询压力）。采集时用 Sent Metrics 的 metricsFilter 或自定义标签，限制高基数维度，聚合为低基数指标。

秒级指标关联"延迟、线程、错误"三类业务信号。标签基数控制是"只保留低基数维度"，避免指标爆炸。高基数标签是监控常见坑。

• 集群限流与负载均衡
• CPU/权重实例选择
• 结合

Sentinel 集群限流控制"集群总量"，Spring Cloud LoadBalancer 控制"选择哪个实例"。结合：集群限流设定总量上限，LoadBalancer 在实例间按策略（权重、CPU）分配流量，使各实例负载均衡且总量受控。基于 CPU/权重实例选择：LoadBalancer 自定义 ServiceInstanceListSupplier 根据实例的 CPU 状态或权重（元数据）选择实例，把流量路由到负载较低/权重高的实例。集群限流与负载均衡结合：集群限流管总量，负载均衡管分配，避免某实例过载同时总量不超限。工程上：集群限流设总量，LoadBalancer 按权重/CPU 分配，实现"总量控制 + 均衡分配"。

集群限流是"总量闸门"，负载均衡是"分配策略"。二者结合实现总量受控且实例均衡。CPU/权重策略需自定义 supplier。

• 推送方向
• 版本管理
• 原子替换

Sentinel 规则从 Nacos 持久化时，推送方向：规则以 Nacos 为唯一数据源（单一事实源），Sentinel 通过 NacosDataSource 从 Nacos 拉取规则，控制台只读或通过 Nacos 修改，避免控制台直接改内存规则导致"控制台覆盖/与 Nacos 不一致"。版本：Nacos 配置带版本，规则更新时原子替换（整体替换规则集合），避免部分更新产生中间态。设计要点：推送方向单向（Nacos → Sentinel），控制台修改写入 Nacos 再推送；规则用版本号/内容比对，变更时原子替换整个规则集；避免控制台直接修改内存规则（重启丢失且与 Nacos 冲突）。工程上：Nacos 为唯一规则源，控制台经 Nacos 下发，原子替换规则。

避免覆盖的关键是"单向推送 + 版本 + 原子替换"。Nacos 为唯一事实源，控制台不直接改内存。规则变更原子替换防中间态。

• Dashboard 与 Prometheus 联动
• 限流指标展示
• 告警规则

Sentinel Dashboard 展示实时监控，但作为单体控制台不适合长期存储与告警；生产上把 Sentinel 指标接 Prometheus + Grafana。联动：Sentinel 通过 Micrometer 暴露指标（SentinelMetrics）到 Prometheus（management.endpoint.prometheus），Grafana 展示限流指标（被拒 QPS、资源 QPS）、告警规则配置：在 Prometheus 配置告警规则，如"资源被拒 QPS 超过阈值"（限流频繁触发）、"资源 QPS 超过阈值"（接近限流）、"熔断器打开次数"（熔断触发）等，触发告警。Dashboard 用于实时调试与规则管理，Prometheus + Grafana 用于长期监控与告警。工程上：Dashboard 实时调试，Prometheus 存储告警，Grafana 可视化。

Dashboard 实时、Prometheus 长期。告警规则针对"限流触发、接近限流、熔断"等信号。二者结合实现监控闭环。

• 故障注入类型
• 验证限流/半开/降级
• 场景验证

通过故障注入验证 Sentinel 各路径：延迟注入——对下游调用注入延迟，验证慢调用熔断（慢调用比例策略触发）、半开恢复（熔断后放行探测请求）；错误注入——注入异常/错误，验证异常比例熔断、降级路径（blockHandler/fallback 响应）；规则中心断连——断开 Nacos 规则源，验证本地规则兜底（规则缓存继续生效）、规则变更不失效、降级行为。验证要点：限流——注入高流量验证触发限流；半开恢复——熔断后注入恢复正常流量验证半开探测与恢复；降级——验证被拒后的降级响应。工程上：混沌测试注入故障，验证 Sentinel 各策略生效与降级路径正确。

故障注入验证"熔断、半开、降级、规则兜底"各路径。延迟/错误/断连分别针对慢调用、异常、规则源故障。验证降级路径完整性。

• 慢调用阈值
• 最小请求数
• 统计窗口

Sentinel 慢调用比例策略（SlowRequestRatio）熔断的条件：统计窗口内，响应时间超过"最大响应时间阈值"的调用占比超过"慢调用比例阈值"（如 50%），且调用的请求数达到"最小请求数"（如 5），才触发熔断。三个因素共同决定：最大响应时间——定义什么叫"慢调用"；最小请求数——避免样本不足时误判（请求数过少不熔断）；统计窗口——统计的时间范围。只有当窗口内请求数 ≥ 最小请求数 且 慢调用占比 ≥ 阈值，才熔断。最小请求数防止冷启动/低流量期误熔断。工程上：合理设置最大 RT、最小请求数、比例阈值，避免误判与漏判。

熔断是"样本量 + 比例 + 阈值"共同作用。最小请求数保证样本充分，慢调用比例定义触发线，RT 定义慢。三者结合避免误熔断。

• 参数索引提取
• 高基数成本
• 对象转换成本

热点参数限流通过参数索引（paramIdx）从调用参数中提取限流 key：paramIdx 指定第几个参数（0 开始），Sentinel 从方法的参数数组取该参数值作为限流 key。成本：参数高基数——若参数值基数极高（如用户 ID 百万级），每个参数值都维护统计节点，内存占用大、统计开销高；对象转换——参数值需转换为可哈希的 key（如 toString、hashCode），频繁转换有开销。工程上：热点参数限流适用于基数可控的热点 key（热门商品、IP），避免把无限高基数参数作为 key；对象转换成本在参数复杂时需注意。控制 key 基数与转换开销。

paramIdx 提取 key，高基数导致节点爆炸，对象转换有开销。热点参数限流适合"有限热点 key"，避免无限基数。

• 熔断状态迁移
• 半开探测
• 并发限制

熔断器状态迁移：CLOSED（关闭，正常放行）→ 触发熔断条件（异常比例/慢调用超阈值）→ OPEN（打开，拒绝请求）→ 经过熔断时长 → HALF_OPEN（半开，放行少量探测请求）→ 探测成功则 CLOSED（恢复），探测失败则回到 OPEN。半开探测并发数必须限制：半开时放行少量请求探测下游是否恢复，若并发数过大，可能瞬间打爆刚恢复的下游（或再次熔断），因此半开探测并发数（如 1 个探测请求）必须受限，用少量请求验证恢复，避免恢复瞬间再次过载。工程上：半开探测并发数小（通常 1），探测成功才逐步恢复。

状态迁移是"CLOSED→OPEN→HALF_OPEN→CLOSED"。半开并发受限是"用小样本探测恢复"，避免恢复瞬间过载。这是熔断器安全恢复的关键。

• 虚拟线程与并发
• 并发线程数流控校准
• 资源模型变化

虚拟线程把"线程"从稀缺平台线程变为轻量虚拟线程，线程数不再直接代表平台资源占用。因此并发线程数流控的意义变化：并发线程数规则原本限制"同时占用的线程/资源"，虚拟线程下并发数不再等价于平台线程占用，但并发数仍代表"同时处理的任务数"，可反映下游负载与资源占用（如数据库连接、内存）。校准：虚拟线程下，并发线程数流控应重新校准阈值——以"实际资源占用"（数据库连接、内存、下游吞吐）为准，而非平台线程数；可能提高并发阈值（虚拟线程便宜）但需结合下游容量。工程上：虚拟线程下并发线程数流控阈值需按实际资源（连接池、下游）重新校准，避免误设。

虚拟线程改变"线程即资源"的假设。并发数流控需从"平台线程"改为"实际资源占用"校准。结合下游容量设定阈值。

• Token Server 瓶颈
• 失败策略
• 放行 vs 拒绝

集群流控 Token Server 成为瓶颈或分区时，客户端无法获取令牌，失败策略选择：放行（fail-open）——客户端降级为本地限流或放行，保证可用性（可能总量超限）；拒绝（fail-closed）——客户端拒绝请求，保证总量受控（可能误伤可用性）。偏向哪个取决于业务：对总量严格管控（防超限、保安全）选拒绝；对可用性优先（保业务响应）选放行。Sentinel 集群流控默认在 Token Server 不可用时降级为本地限流（fail-open 的近似），用本地规则兜底。工程上：根据业务对"总量控制 vs 可用性"的优先级选择，配合本地限流兜底避免完全失控。

失败策略是"可用性 vs 总量控制"的权衡。fail-open 保可用（可能超限），fail-closed 保总量（可能误伤）。按业务选择并配本地兜底。

• blockHandler vs fallback
• 异常处理
• 方法签名规则

@SentinelResource 的 blockHandler 处理BlockException（被限流、熔断、降级触发的异常），fallback 处理业务异常（Exception，包括 BlockException 之外的异常）。blockHandler 只处理 Sentinel 触发的阻断（流控/熔断），fallback 处理业务逻辑异常。方法签名规则：blockHandler/fallback 方法需与原始方法同参数（或加 BlockException/Throwable 参数）、返回类型一致、static 方法；blockHandler 方法最后一个参数可以是 BlockException，fallback 方法最后一个参数可以是 Throwable。若 blockHandler 与 fallback 都配置，blockHandler 优先（处理 BlockException）。工程上：blockHandler 处理限流降级，fallback 处理业务异常，签名遵循规范。

blockHandler 管"被阻断"，fallback 管"业务异常"。签名需同参数 + 可加异常参数。理解二者分工与优先级。

• 拒绝 vs 远端失败
• 统一 fallback 的掩盖
• 错误区分

OpenFeign 集成 Sentinel 时，Sentinel 拒绝（本地限流/熔断的 BlockException）与远端调用失败（下游返回错误/异常的 Exception）是不同错误。应区分：Sentinel 拒绝用 blockHandler 处理（返回"触发限流/熔断"），远端失败用 fallback 处理（返回"下游异常"）。若用统一 fallback 处理两者，会掩盖差异——无法区分"被本地限流"与"下游故障"，而二者运维含义不同（限流是本地策略，远端失败是下游问题）。工程上：blockHandler 与 fallback 分离，分别透出"限流/熔断"与"下游失败"语义，便于诊断与降级。

区分"本地阻断"与"远端失败"是运维关键。统一 fallback 掩盖二者差异，导致无法定位问题。分离 blockHandler/fallback 保语义。

• 功能差异
• 资源模型
• 治理方式

Sentinel 与 Hystrix（Netflix 已停维）的差异：资源模型——Hystrix 用线程池/信号量隔离（每个命令独立线程池），Sentinel 用资源 + 滑动窗口统计，无线程池隔离（通过并发/线程数流控保护）；功能——Hystrix 主要做熔断降级（线程池隔离、熔断），Sentinel 提供流控、熔断、热点、系统自保护、集群流控等更全面；规则管理——Hystrix 配置静态，Sentinel 支持动态规则（Nacos/控制台）；Dashboard——Sentinel 有控制台，Hystrix 有 Hystrix Dashboard。性能——Sentinel 无线程池开销，性能更好。选型：Sentinel 是 Hystrix 的现代替代，功能更全、更活跃、动态规则。Hystrix 已停维，新项目用 Sentinel/Resilience4j。

差异核心是"资源模型与治理能力"。Hystrix 线程池隔离 + 静态熔断，Sentinel 资源统计 + 动态流控/熔断。Sentinel 更全面、活跃。

• Feign 集成
• 熔断降级
• 配置

Sentinel 与 OpenFeign 集成：开启 feign.sentinel.enabled=true，Feign 客户端被 Sentinel 保护，@SentinelResource 或 Feign 的容错定义生效。集成方式：Sentinel 的 Feign 适配器（SentinelFeign）为每个 Feign 接口创建 Sentinel 资源，流控/熔断规则作用于 Feign 调用；fallback/fallbackFactory 定义降级处理。配置：feign.sentinel.enabled=true、@FeignClient(fallback=...) 或 fallbackFactory。集成效果：Feign 调用可被 Sentinel 限流/熔断，失败时用 fallback 降级。工程上：开启 feign.sentinel，为 Feign 接口配置规则与降级，实现服务调用容错。

集成是"Feign 调用纳入 Sentinel 治理"。开启开关 + fallback 降级。Sentinel 对 Feign 调用做限流熔断。

• 网关集成
• SentinelGatewayFilter
• 限流熔断

Sentinel 与 Spring Cloud Gateway 集成：引入 spring-cloud-alibaba-sentinel-gateway，注册 SentinelGatewayFilter 与 SentinelGatewayBlockExceptionHandler，为 Gateway 的 route 资源与自定义 API 分组提供 Sentinel 限流/熔断。SentinelGatewayFilter 在过滤器链中为每个 route 创建 Sentinel 资源，执行限流规则；SentinelGatewayBlockExceptionHandler 处理被拒请求返回降级响应。自定义 API 分组用 GatewayApiDefinition 定义资源粒度。配置：spring.cloud.sentinel.filter.enabled=true，规则从 Nacos/配置加载。集成效果：网关入口流量被 Sentinel 限流/熔断，保护后端。工程上：集成 guard 过滤器 + block 处理器，实现网关限流。

集成是"网关过滤器 + 资源建模"。SentinelGatewayFilter 为 route/API 分组建资源，block 处理器降级。网关限流保护后端。

• Modulith 边界
• Sentinel 资源映射
• 协作

Spring Modulith 以模块化单体组织应用，模块间有明确边界（通过 event publication 等）。Sentinel 与 Modulith 边界的协作：Sentinel 的资源可按 Modulith 模块/边界划分，对模块边界上的调用（如模块间事件、服务方法）做限流/熔断，实现"按模块治理"。Modulith 模块是逻辑边界，Sentinel 资源可标注模块的关键方法（@SentinelResource），在模块边界控制流量。协作价值：模块化单体中，Sentinel 保护模块的入口/关键调用，防止某模块故障拖垮整体；模块边界清晰便于按模块配置规则。工程上：在 Modulith 模块边界方法上标注 Sentinel 资源，按模块治理流量。

协作是"Sentinel 资源与 Modulith 模块边界对齐"。按模块治理流量，保护模块化单体。边界清晰便于规则配置。

• Slot Chain 结构
• 各槽执行顺序
• 顺序重要性

Sentinel 的 Slot Chain（责任链）依次执行各槽：NodeSelectorSlot（建立资源节点）→ ClusterBuilderSlot（统计节点）→ LogSlot（日志）→ StatisticSlot（实时统计 QPS/线程/异常）→ AuthoritySlot（黑白名单）→ SystemSlot（系统保护）→ FlowSlot（流控）→ DegradeSlot（熔断）→ ParamFlowSlot（热点）。顺序：先统计（StatisticSlot），再做系统保护、流控、熔断等策略判断。扩展 Slot 时顺序重要：因为各槽依赖前面的统计结果（如 FlowSlot 需要 StatisticSlot 的 QPS 数据，DegradeSlot 需要统计窗口的异常/RT 数据），顺序错误会导致取不到数据或逻辑错误；且扩展槽插入位置影响其执行时机与优先级。工程上：扩展 Slot 需理解责任链顺序，插在正确位置。

槽链是"统计在前、策略在后"。统计槽为策略槽提供数据，顺序决定依赖关系与执行时机。扩展需遵循顺序。

• 黑白名单规则
• 来源识别
• 应用场景

Sentinel 的 Authority（黑白名单）规则（AuthorityRule）用于控制资源允许/拒绝的来源调用：白名单——只允许指定来源（limitApp）访问；黑名单——拒绝指定来源访问。来源通过 ContextUtil.enter(name, origin) 传入的 origin 标识，或根据请求特征（如 IP）识别。应用场景：按来源（服务方、IP）控制访问，如拒绝非白名单服务调用、限制特定来源。工程上：用 AuthorityRule 配置黑白名单，控制资源访问来源，防止未授权来源调用。注意来源标识的伪造风险（需在可信层控制）。

黑白名单是"按来源控制访问"。AuthorityRule + origin 标识。适用于按来源隔离，需注意来源伪造。

• BlockException 类型
• 降级处理
• 处理方式

Sentinel 的 BlockException 是阻止执行的异常基类，子类包括：FlowException（流控被拒）、DegradeException（熔断被拒）、SystemBlockException（系统保护被拒）、ParamFlowException（热点限流被拒）、AuthorityException（黑白名单被拒）。降级处理：当 Sentinel 阻止执行时抛出 BlockException，需通过 blockHandler（@SentinelResource）或全局 BlockExceptionHandler 处理，返回降级响应。处理方式：blockHandler 处理对应资源的 BlockException，全局处理器统一处理所有 BlockException，返回标准降级结构。工程上：区分 BlockException 与业务异常（BlockException 是"被限流/熔断"，业务异常是"业务失败"），分别处理。

BlockException 是"被 Sentinel 阻断"的统一异常。降级处理区分各子类（流控/熔断/系统）。blockHandler 与全局处理器处理。

• Warm Up 原理
• 预热阈值
• 应用场景

Sentinel 的 Warm Up（冷启动/预热）是一种流控模式：服务刚启动时，系统缓存未热、资源未就绪，若瞬间放大量流量容易打爆系统。Warm Up 让限流阈值从低值（coldFactor 默认 1/3）缓慢增长到设定阈值，经过预热期（warmUpPeriodSec）逐步放量。原理：令牌桶预热，初始阈值低，随预热时间线性/指数增长到目标阈值。应用场景：服务启动、缓存重建、水平扩容后的新实例，用 Warm Up 平滑放量，避免冷启动被突发流量击穿。工程上：为启动期服务配置 Warm Up 流控，配合系统自保护，平滑过渡。

Warm Up 是"冷启动平滑放量"。阈值从低到高增长，避免冷启动被击穿。适合启动/扩容场景。

• 资源（Resource）
• 规则（Rule）
• 上下文（Context）

Sentinel 核心概念：资源（Resource）——被保护的业务逻辑（方法、接口），用 SphU.entry("资源名") 或 @SentinelResource 定义，是限流/熔断的统计单元；规则（Rule）——对资源的治理策略，包括流控规则（FlowRule）、熔断规则（DegradeRule）、系统规则（SystemRule）、热点规则（ParamFlowRule）、授权规则（AuthorityRule）；上下文（Context）——本次调用的环境信息，通过 ContextUtil.enter() 创建，包含资源入口、调用来源（origin）、链路信息。三者关系：资源是被治理对象，规则定义治理策略，上下文关联调用来源与链路。理解概念是使用 Sentinel 的基础。

资源是"被保护对象"，规则是"治理策略"，上下文是"调用环境"。三者构成 Sentinel 治理模型。理解概念才能正确配置。

• 链路（Link）
• 上下文传播
• 调用链治理

Sentinel 的链路（Link）指一个调用链中资源的父子关系：ContextUtil.enter() 建立根节点，SphU.entry() 进入资源时建立父子链路（ParentNode → Node），形成调用树。链路用于支持"按调用链限流"（如限制某个入口的调用）。上下文传播：Context（含入口、来源、链路）通过 ContextUtil 在调用线程内传播，异步场景需显式传递（AsyncEntry、ContextUtil.runOnContext）。链路治理：通过 ClusterBuilderSlot 建立节点树，origin 标识来源，支持按来源/链路限流。虚拟线程/异步场景需正确传播上下文，避免链路丢失。工程上：理解链路与上下文传播，处理异步场景。

链路是"调用树"，上下文是"调用环境"。链路支持按调用链/来源限流，上下文需在异步场景显式传播。理解传播避免链路丢失。

• 热点参数限流
• 与 Alibaba 协同
• 规则下发

Sentinel 与 Spring Cloud Alibaba 协同的热点参数限流：@SentinelResource 标注资源，配合 @SentinelHotParam（或规则）定义热点参数限流规则，对指定参数值做精细限流。协同：规则通过 Nacos 数据源动态下发（Nacos 存热点规则，Sentinel 的 ParamFlowRule 动态加载），实现热点限流规则集中管理。热点参数限流（Hot Parameter）对高价值参数（商品 ID、用户 ID）按值限流，保护热点。Spring Cloud Alibaba 集成使热点规则可动态调整、灰度。工程上：用 @SentinelResource + 热点规则，Nacos 下发，实现热点治理。

协同是"热点规则 + 动态下发"。Sentinel 执行热点限流，Nacos 管理规则。@SentinelResource 标注资源。

• Warm Up 阈值计算
• coldFactor
• 预热增长

Sentinel Warm Up 流控模式的冷启动保护阈值计算：初始阈值为 阈值 / coldFactor（coldFactor 默认 3，即初始阈值为目标阈值的 1/3），随着预热时间增长，阈值逐渐上升到目标阈值。公式：warmUpThreshold = threshold / coldFactor（初始），预热期内阈值按预热周期平滑增长（Sentinel 用令牌桶/预热曲线，斜率随预热时长变化）。预热期由 warmUpPeriodSec 控制。保护逻辑：冷启动时阈值低（1/3），放量受限，随预热逐步提高到目标阈值，避免刚启动被突发流量打爆。Spring Boot 4.0 中公式不变，关键在于 coldFactor 与 warmUpPeriodSec 的配置。

Warm Up 初始阈值 = 目标阈值 / coldFactor（默认 1/3），预热期逐步增长。冷启动保护靠低阈值 + 平滑增长。理解公式配置预热参数。

• 令牌逐步增加
• 冷系统保护
• 配合手段

Warm Up 规则让可用令牌逐步增加：初始令牌桶容量小（阈值/coldFactor），预热期内令牌生成速率随预热时间逐步提高，直到达到目标阈值，实现"可用令牌从低保到逐步放开"。冷系统面对突发流量时还需配合：系统自适应保护（SystemRule，CPU/负载超限自动限流）、并发线程数/熔断（保护资源）、缓存预热（提前加载热点数据）、限流 + 熔断组合（突发时先限流再熔断）。工程上：Warm Up 平滑放量 + 系统自保护兜底 + 缓存预热，全面保护冷系统启动。

Warm Up 平滑令牌供给，系统自保护兜底过载。冷系统需"限流 + 自保护 + 缓存预热"组合，避免启动被击穿。

• 来源标识伪造
• 控制层
• 可信来源

Sentinel 的 origin（来源标识）用于按来源限流/黑白名单，若客户端可伪造 origin，则绕过来源限制。伪造来源标识的风险应在"可信层"控制：来源标识应在受信边界（如网关、服务入口）设置，而非由客户端任意声明；服务端验证来源标识的真实性（如网关认证后注入可信 origin，或基于 IP/身份）。控制层：在网关/认证层注入可信来源标识，服务端信任该标识；业务服务不信任客户端自报的 origin。工程上：来源标识由网关/认证层负责注入（可信），服务端基于可信来源做限流，防止伪造。

伪造来源需在"可信边界"控制。来源标识由网关/认证注入，服务端不信任客户端自报。防止绕过来源限流。

• 匀速排队原理
• 等待时间计算
• 超时拒绝

Sentinel 匀速排队（RateLimiterController）控制请求按固定间隔匀速通过：每个请求需等待前一个请求通过后间隔 interval（1/QPS）再通过。等待时间 = 从"当前应通过时间"到"本次请求应通过时间"的排队时间。若排队等待时间超过"最大排队时长"（maxQueueingTimeMs），则立即拒绝该请求（不排队）。原因：超过最大排队时长意味着请求已等待过久，即使放行也已失去时效（用户已超时/重试），继续排队会积压队列、占用资源、放大延迟，应立即拒绝（fail-fast）让客户端快速失败或重试。工程上：匀速排队平滑突发，超时立即拒绝避免队列积压。

匀速排队是"按间隔放行"。等待超过最大排队时长立即拒绝，避免无限排队积压与请求失效。这是"平滑 + 防积压"的平衡。

• 异常比例 vs 异常数
• 流量规模
• 业务异常统计

异常比例策略适合"流量规模大"的场景：用比例（异常/总数）判断，流量大时比例稳定，能反映异常率；异常数策略适合"流量规模小"的场景：用绝对异常数判断，流量小时异常数也能触发（比例可能因样本少不稳定）。业务异常是否计入：应区分——业务异常（如正常的业务校验失败、参数错误）不应计入熔断统计（是正常业务逻辑，非系统故障），只有"系统级异常"（如依赖故障、超时、数据库错误）才应计入熔断统计。若业务异常计入，会误熔断。工程上：通过 @SentinelResource 的 fallback 或异常过滤，区分业务异常与系统异常，只统计系统异常。

比例适合大流量、异常数适合小流量。业务异常不应计入熔断（正常逻辑），系统异常才计入。区分异常类型避免误熔断。

• 资源名基数
• 高基数问题
• 资源粒度规范

把完整 URL（含动态 ID）或用户 ID 直接作为资源名会造成高基数问题：每个不同 ID/URL 生成独立资源，产生海量资源节点，导致内存占用、统计开销、控制台/监控膨胀，且限流规则无法覆盖（规则针对具体资源名）。资源粒度应规范：用"资源类别"作为资源名（如 /api/order/{id} 归一化为 /api/order），把动态参数排除在资源名外；结合热点参数限流（对 ID 类参数用 ParamFlowRule 按参数值限流）而非资源名。规范：资源名保持低基数（按接口/方法命名），动态值用参数维度治理。工程上：资源名归一化，避免高基数，用热点参数处理动态值。

高基数资源名导致资源爆炸与规则失效。资源名用"类别级"（低基数），动态值用热点参数限流。这是资源达命名规范。

• 系统自适应规则指标
• 容器 CPU 限额
• 阈值判断

系统自适应规则（SystemRule）基于 CPU、Load、入口 QPS 等判断是否限流。容器 CPU 限额下，CPU 使用率是"容器内 CPU 使用率"（相对容器份额），而非宿主整体 CPU。因此：容器 CPU 限额小，容器内 CPU 使用率容易达到 100%（即使宿主空闲），导致 SystemRule 误判系统过载而限流；反之容器限流时 CPU 使用率受限于份额，无法反映真实负载。影响：容器 CPU 限额使 CPU/负载指标失真，阈值判断可能误触发限流。工程上：容器环境需校准 SystemRule 的 CPU/负载阈值（考虑容器份额），或用入口 QPS/并发等指标替代 CPU 判断，避免容器限额导致误限流。

容器 CPU 限额使 CPU 使用率失真（相对份额）。SystemRule 的 CPU 阈值需按容器校准，或用入口 QPS 替代。理解容器资源语义。