SpringCloud Alibaba Sentinel史上最详细说到微服务治理很多团队都是从“服务能跑起来”开始的。但等流量上来、依赖变多你会发现真正麻烦的不是写业务代码而是怎么让系统在突发流量下不被打垮、在依赖服务抖动时不发生雪崩。这时候流量控制、熔断降级就不再是可选功能而是保命手段。SpringCloud Alibaba Sentinel 就是干这个的。它由阿里开源定位是“面向分布式服务架构的流量控制、熔断降级组件”既能像传统限流器一样对 QPS、并发线程数做精准控制也能在依赖服务调用变慢、报错率升高时自动熔断还能在系统整体负载过高时触发保护。相比社区里老牌的 HystrixSentinel 在功能丰富度、控制台可视化、规则热更新这几个维度上要顺手得多尤其是它自带的 dashboard可以直观看到每个接口的实时 QPS、RT、拒绝数量排查线上问题非常方便。这篇内容面向的读者包括正在给微服务加防护能力的开发人员、刚接触 SpringCloud Alibaba 想系统了解 Sentinel 的人以及准备把 Sentinel 落到生产环境、但不清楚规则持久化和网关整合该怎么做的团队。我会从核心概念、工作原理解起再给出完整接入步骤、注解用法、规则配置、Nacos 持久化、OpenFeign 和 Gateway 整合方案最后把多年踩过的坑整理成排查清单一次性讲透。1. Sentinel 到底解决了什么问题1.1 从一次线上事故说起没有保护的服务有多脆弱我在某电商公司做过一个促销活动项目。平时流量平稳系统很安静但大促一开始首页聚合接口瞬间被刷爆。这个接口会并行调用商品、库存、营销、用户四个下游服务一旦某个下游变慢Tomcat 线程池就会被占满其他接口也连带着全挂最终整个应用不可用。那种“一个接口拖垮全站”的场景不亲身经历一次很难有切肤之痛。事后排查问题链条很清晰下游营销服务因为数据库连接池被打满响应时间从 20ms 飙到 5s首页聚合接口调它用的是同步 HTTP线程全部阻塞线程耗尽后健康检查失败实例被负载均衡摘掉紧接着新流量打到剩余实例上剩余实例也很快崩溃。整个过程不到三分钟。这就是典型的缺乏流量控制和熔断降级的表现。如果当时用 Sentinel 做两层防护事情完全不会发展成这样第一层给首页聚合接口设置 QPS 阈值超出部分直接拒绝或排队保护应用自身第二层给下游调用配置熔断规则当营销服务慢调用比例超过阈值时自动熔断快速返回兜底数据而不是干等 5 秒。1.2 Sentinel 能做什么限流、熔断、系统保护Sentinel 的核心能力可以分成三块。第一块是流量控制。你可以针对任意资源接口、方法、甚至某段代码设置 QPS 阈值或并发线程数阈值。QPS 限流适合大多数接口场景比如规定某个接口每秒最多处理 1000 个请求超出直接返回“系统繁忙”并发线程数限流则更适合保护线程池比如规定某资源同时最多占用 5 个线程避免慢调用耗尽线程资源。第二块是熔断降级。Sentinel 支持三种熔断策略慢调用比例、异常比例、异常数。以慢调用比例为例你可以设定“如果 1 秒内进入的请求数超过 5 个且其中超过 70% 的请求 RT 大于 500ms就熔断该资源 10 秒”。熔断期间请求直接走降级逻辑不再发起真实调用给下游喘息恢复的时间。第三块是系统保护规则。它是全局维度的兜底可以基于系统负载Load、CPU 使用率、入口 QPS 等指标做自适应保护。当系统整体负载过高时Sentinel 会限制进入系统的流量而不是让每个接口各自为战。这三块能力结合起来基本覆盖了微服务治理中最常见的三个问题流量突增、依赖故障、系统过载。1.3 对比 Hystrix为什么选 Sentinel 而不是老牌组件有不少团队现在还跑着 Hystrix但如果你正在新项目选型我会直接建议 Sentinel。不是说 Hystrix 不好它的熔断思路很经典但 Sentinel 在以下几个方面优势太明显了。控制台体验差距最大。Hystrix 的 Dashboard 需要自己搭建 Turbine 聚合数据而且界面简陋只能看个大概Sentinel 自带一个开箱即用的 dashboard可以实时看到每个资源的 QPS、RT、并发线程数、拒绝数量还能直接在页面上动态修改规则修改后秒级生效。规则配置方式也不同。Hystrix 的规则基本靠硬编码写在注解里改规则要改代码、发版Sentinel 的规则可以通过控制台、API、Nacos 等多种方式动态推送支持规则持久化不需要重启应用就能生效。Sentinel 的限流算法也更丰富。Hystrix 主要靠信号量隔离和线程池隔离Sentinel 则内置了滑动窗口、令牌桶、漏桶等多种限流策略还支持热点参数限流这种细粒度能力。比如你想对某个商品的 ID 单独做限流同一接口其他参数不受影响Hystrix 完全做不了Sentinel 可以一行配置搞定。2. 核心概念与工作原理解读2.1 资源、规则与 Slot 链Sentinel 有两个最基础的概念资源Resource和规则Rule。资源是你想要保护的对象可以是一个方法、一个接口、一段代码。在代码里你可以用SphU.entry(资源名)手动定义一个资源也可以用SentinelResource注解自动定义。资源名是全局唯一的控制台上看到的所有数据都是按资源名维度统计的。规则就是施加在资源上的限制包括流量控制规则、熔断降级规则、系统保护规则、授权规则、热点参数规则。一个资源可以挂多条规则多条规则之间是“或”的关系只要命中任意一条就会被拦截。理解 Sentinel 的执行机制要抓住“Slot 链”这个概念。每个资源请求进入 Sentinel 后会沿着一条 ProcessorSlotChain 依次经过各个插槽每个槽负责一项能力。比如 NodeSelectorSlot 负责构建调用链 contextFlowSlot 负责流量控制校验DegradeSlot 负责熔断校验StatisticSlot 负责统计指标。这种插槽式设计让 Sentinel 的扩展性非常强你可以自定义 Slot 插入链路中实现特殊逻辑比如做参数加密校验、灰度放行等。2.2 限流算法拆解滑动窗口、令牌桶与漏桶Sentinel 的流量控制底层实现非常讲究这里需要理解几个核心算法。最基础的是计数器算法固定时间窗口内计数超过阈值就拒绝。但这个算法有临界问题假设阈值是 100 QPS第一个窗口最后 500ms 通过了 100 个请求第二个窗口最开始 500ms 又通过了 100 个请求在这 1 秒内实际通过了 200 个请求远远超过阈值。Sentinel 默认使用的是滑动窗口算法它的设计巧妙得多。它把时间窗口细分成多个小格子比如秒级窗口分成 2 个 500ms 的格子每来一个请求就计算当前时间落在哪个格子里然后把窗口往前滑动只统计最近一个完整窗口内的数据。这样就避免了计数器算法的临界突发问题统计精度更高。窗口格子数越多精度越高但内存开销也越大默认 2 个格子在大多数场景下已经够用。除了滑动窗口Sentinel 还支持两种流控效果。一种是排队等待漏桶算法请求以固定速率通过超出的请求在队列里排队适合需要平滑处理流量的场景比如刷数据任务另一种是 Warm Up令牌桶算法系统冷启动时限制流量让流量缓慢增长到阈值避免刚启动瞬间被打满特别适合 Java 应用 JIT 预热场景。选择哪种流控效果取决于业务容忍度。如果是交易类接口建议直接快速失败返回明确的提示如果是秒杀类场景可以用排队等待让流量均匀释放如果应用刚发布完强烈建议配 Warm Up防止冷启动直接被流量打死。2.3 熔断降级的底层状态机Sentinel 的熔断降级也有一套完整的状态机包含关闭CLOSED、开启OPEN、半开HALF_OPEN三种状态。初始状态是关闭此时请求正常通过。一旦某个统计周期内触发了熔断条件比如慢调用比例超过阈值状态变为开启后续请求直接走降级逻辑。经过设定的熔断时长后状态变为半开Sentinel 会放行少量探测请求如果这些请求都成功了说明下游已经恢复状态回到关闭如果还是有请求失败状态重新变为开启。这套状态机逻辑在代码层面由 DegradeSlot 配合异常计数器实现。慢调用比例熔断统计的是“RT 大于阈值”的请求占比异常比例熔断统计的是“抛出异常”的请求占比异常数熔断统计的是最近统计周期内的异常总数。实际使用中慢调用比例最常用因为它对“下游变慢但还没报错”这种情况非常敏感很多时候服务不是挂了只是慢异常统计是发现不了的。熔断降级最关键的一个参数是“最小请求数”。假设你的接口每秒只有 1 个请求这个请求恰好很慢如果最小请求数是 5那么即使慢调用比例达到 100%也不会触发熔断因为样本量不够误判风险高。生产环境我一般设置为 10 以上太低容易误伤。3. 完整接入实操从零到生产可用的每一步3.1 环境准备与依赖接入在开始之前先交代一下我使用的环境版本方便你对照SpringCloud Alibaba 2021.0.5.0SpringBoot 2.7.xSentinel 核心版本 1.8.6Nacos Server 2.2.0。如果你用的版本跨度比较大配置方式可能略有出入但核心逻辑是通用的。创建一个新的 SpringBoot 工程以 Maven 为例在pom.xml中引入以下依赖dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-sentinel/artifactId /dependency这个 starter 会自动完成 Sentinel 的初始化把SphU、SentinelResource等核心能力注入 Spring 容器。它不会自动开启对 Web 容器的埋点要拦截所有 HTTP 请求还需要引入 Web 适配器依赖dependency groupIdcom.alibaba.csp/groupId artifactIdsentinel-spring-webmvc-adapter/artifactId version1.8.6/version /dependency然后修改application.yml指定控制台地址和应用名spring: application: name: order-service cloud: sentinel: transport: dashboard: localhost:8080 port: 8719 eager: true这里的port: 8719是 Sentinel 客户端与控制台通信的端口默认 8719。如果你的应用已经占用了这个端口可以改但要保证控制台能访问到。注意eager: true表示应用启动时就主动连接控制台而不是等第一个请求进来才初始化。如果漏掉这个配置你启动完应用立刻打开控制台会看不到应用列表得手动访问一个接口后才会出现。3.2 启动控制台Sentinel DashboardSentinel Dashboard 是一个独立的 SpringBoot 应用官方已经打好了 jar 包。从 GitHub Releases 页面下载sentinel-dashboard-1.8.6.jar然后直接启动java -Dserver.port8080 -Dcsp.sentinel.dashboard.serverlocalhost:8080 -Dproject.namesentinel-dashboard -jar sentinel-dashboard-1.8.6.jar启动后访问http://localhost:8080默认账号密码都是sentinel。控制台启动成功之后你的客户端应用如果也配置好了就能在“机器列表”里看到应用实例。这里建议先把控制台跑起来再做后续的规则配置因为 Sentinal 的规则如果不通过控制台下发直接编码方式虽然可以但可维护性会比较差后面我会详细说。3.3 定义资源手动埋点与注解方式Sentinel 有两种主要的资源定义方式手动埋点和注解。手动埋点适合那些需要对特定代码块做精细控制的场景。比如你要保护一段从 Redis 批量查询数据的代码import com.alibaba.csp.sentinel.Entry; import com.alibaba.csp.sentinel.SphU; import com.alibaba.csp.sentinel.slots.block.BlockException; public ListProduct queryHotProducts(ListLong productIds) { try (Entry entry SphU.entry(hotProductQuery)) { // 这里的代码受 Sentinel 保护 return doQuery(productIds); } catch (BlockException ex) { // 被限流或熔断时走到这里做降级处理 return fallbackHotProducts(productIds); } }手动埋点的好处是灵活可以精确到代码块级别坏处是侵入性强业务代码里到处是 Sentinel 的调用看起来不够清爽。更优雅的用法是SentinelResource注解把资源和业务逻辑解耦。SentinelResource( value order/createOrder, blockHandler createOrderBlockHandler, fallback createOrderFallback ) public Order createOrder(OrderCreateDTO dto) { // 正常业务逻辑 return orderService.create(dto); } public Order createOrderBlockHandler(OrderCreateDTO dto, BlockException ex) { // 被限流/熔断时执行 return Order.blockedOrder(); } public Order createOrderFallback(OrderCreateDTO dto, Throwable t) { // 业务逻辑抛异常时执行 return Order.errorOrder(); }这里强调两个很容易踩的坑。第一blockHandler方法的返回值、参数列表必须和原方法一致并且最后一个参数必须是BlockException否则运行时会抛异常。第二fallback处理的是业务异常blockHandler处理的是 Sentinel 拦截异常两者职责不同。如果同时配置被 Sentinel 拦截时走blockHandler业务方法内部抛异常时走fallback互不干扰。还有个细节是注解的value属性也就是资源名。这个名称必须全局唯一建议用“模块/功能/动作”的命名规范比如order/createOrder、pay/wechatPay方便在控制台识别。3.4 在控制台配置流控规则参数与策略详解控制台左侧菜单栏有“流控规则”和“熔断规则”点进去可以针对某个资源名直接配置规则。这里我以order/createOrder为例演示一个完整的流控规则配置过程。点“新增流控规则”弹窗里需要填这些字段资源名order/createOrder针对来源default默认不区分调用来源也可以指定微服务名做针对性控制阈值类型QPS 或并发线程数单机阈值比如 100是否集群不选单机模式流控模式直接 / 关联 / 链路流控效果快速失败 / Warm Up / 排队等待大多数场景选“直接 快速失败”就够用了。QPS 阈值需要根据接口的实际容量来定我的经验是先做压测找到接口在目标 RT比如 200ms下的最大 QPS然后乘以 0.7 作为安全阈值。比如压测出来最大 QPS 是 1500线上阈值设 1000 比较稳留出余量应对突发。关联模式适合两个资源有依赖关系的情况。比如order/create和order/query两个接口共享数据库连接池你可以给order/query设置“关联资源 order/create”当 create 接口的 QPS 超过阈值时query 接口开始限流优先保护写操作的可用性。链路模式是更高级的用法在 Spring MVC 中默认不生效需要手动开启spring.cloud.sentinel.web-context-unify: false。它能做“入口级别的精细化控制”比如一个底层的公共方法被 A、B 两个入口调用你只想限制 A 入口对它的调用频率链路模式可以做到。Warm Up 冷启动的配置也值得说一下。阈值是 1000冷启动时长 10 秒那么系统会从 1000 / 3默认冷启动因子是 3开始在 10 秒内慢慢增长到 1000。这期间流量是平滑爬坡的不会瞬间打满。我每次上线新版应用都会配上Java 应用刚启动时 JIT 还没完成热点代码编译性能只有稳定期的五六成这时候接满流量特别容易超时。重要提示这些规则配置在控制台后默认是保存在内存里的。应用重启后规则全部丢失这在生产环境是不可接受的。规则持久化的问题我会在后面专门用一节来讲这里先记住这个坑。4. 规则持久化与微服务组件整合4.1 为什么必须做规则持久化以及如何用 Nacos 实现Sentinel 客户端默认将规则存储在本地内存这意味着两件事应用重启规则消失控制台改规则只能影响当前运行中的实例下次重启又回到原样。对生产环境来说这等于没有配置。业界最主流、也是官方推荐的解决方案是利用 Nacos 作为规则配置中心把规则存为 Nacos 配置Sentinel 客户端通过DataSource接口动态读取。这样规则既能在 Nacos 控制台上统一管理、修改也能在应用重启后自动拉取真正做到“规则与代码分离”。首先引入依赖dependency groupIdcom.alibaba.csp/groupId artifactIdsentinel-datasource-nacos/artifactId version1.8.6/version /dependency然后在application.yml中配置数据源spring: cloud: sentinel: datasource: flow: nacos: server-addr: localhost:8848 >[ { resource: order/createOrder, limitApp: default, grade: 1, count: 1000, strategy: 0, controlBehavior: 0, clusterMode: false }, { resource: product/queryDetail, limitApp: default, grade: 1, count: 500, strategy: 0, controlBehavior: 2, warmUpPeriodSec: 10, clusterMode: false } ]参数对应关系grade为 1 表示 QPS 限流、0 表示并发线程数strategy为 0 表示直接模式、1 关联、2 链路controlBehavior为 0 快速失败、1 Warm Up、2 排队等待。熔断规则的字段稍有不同grade为 0 慢调用比例、1 异常比例、2 异常数还需要count、timeWindow、minRequestAmount、statIntervalMs等参数。配置完成后客户端应用会在启动时自动从 Nacos 拉取规则也会监听 Nacos 配置变更如果控制台或 Nacos 里修改了规则客户端在几秒内就能感知并更新不需要重启。这里的方案实测下来有一个小坑如果应用启动时 Nacos 还没准备好或者>feign: sentinel: enabled: true然后在启动类上保留EnableFeignClients。接着创建一个 Feign 接口FeignClient(name inventory-service, fallbackFactory InventoryFeignFallbackFactory.class) public interface InventoryFeignClient { GetMapping(/inventory/deduct) InventoryDeductResult deduct(RequestParam(skuId) Long skuId, RequestParam(count) Integer count); }降级逻辑通过 fallbackFactory 实现可以拿到具体的异常原因Component public class InventoryFeignFallbackFactory implements FallbackFactoryInventoryFeignClient { Override public InventoryFeignClient create(Throwable cause) { return new InventoryFeignClient() { Override public InventoryDeductResult deduct(Long skuId, Integer count) { return InventoryDeductResult.failed(库存服务不可用: cause.getMessage()); } }; } }这个整合的效果是当inventory-service调用触发熔断或者被限流时Feign 调用不会报 500而是走 fallback 返回一个兜底结果上游业务代码根据结果决定后续逻辑。我比较推荐在涉及库存、支付这类关键链路的场景下fallback 里至少记录完整日志入参、异常、耗时方便事后追溯。需要注意Feign 的 Sentinel 整合对 SpringBoot 2.x SpringCloud Alibaba 的版本匹配比较敏感。如果出现 Feign 调用没有进入 Sentinel 控制台的情况优先检查版本兼容性再检查feign.sentinel.enabled配置是否被覆盖。4.3 与 Spring Cloud Gateway 整合网关层限流网关是流量的第一道入口在网关层做限流能挡住大部分恶意刷量、突发流量避免把压力传达到下游服务。Sentinel 对 Spring Cloud Gateway 有专门的适配模块。引入依赖dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-sentinel/artifactId /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-alibaba-sentinel-gateway/artifactId /dependency然后在网关配置文件中声明需要限流的路由spring: cloud: gateway: routes: - id: order-service-route uri: lb://order-service predicates: - Path/order/**Sentinel 网关适配器会自动识别这个路由并在控制台的“网关流控规则”里出现对应的资源名通常是路由 ID 或者 Path 路径。你可以基于路由维度配置限流比如限制/order/**每秒最多 500 QPS也可以基于某个自定义的 API 分组做更精细的维度。网关层限流的阈值设置要格外谨慎它不是针对单个下游接口的而是所有经过网关的请求总量。建议至少观察一周的网关访问趋势取高峰 QPS 的 1.2 到 1.5 倍作为阈值如果设得过低会把正常流量也挡在外面。4.4 热点参数限流与应用场景热点参数限流是 Sentinel 独有的一项高级能力它把限流粒度从“资源”细化到“参数值”。举个例子同一秒内1000 个请求都打在同一个商品的详情接口上远超正常水平但其他商品的请求量很小。常规 QPS 限流看不出问题因为总 QPS 并没有超热点参数限流可以精确地识别出“某个参数值”的 QPS 超了然后只对携带这个参数值的请求做限制。使用方式是在控制台的“热点规则”中配置也可以代码方式定义ParamFlowRule rule new ParamFlowRule(product/queryDetail) .setParamIdx(0) .setCount(100) .setDurationInSec(1); ParamFlowItem item new ParamFlowItem() .setObject(String.valueOf(10001L)) .setCount(5); rule.setParamFlowItemList(Collections.singletonList(item)); ParamFlowRuleManager.loadRules(Collections.singletonList(rule));setParamIdx(0)表示对第一个参数进行限流setCount(100)表示每秒最多允许 100 次ParamFlowItem则指定特定参数值商品 ID 10001自己单独的阈值是 5。热点参数限流在电商、内容平台的“单点热点”场景特别管用比如大 V 带某件商品、某条视频突然爆火、某个直播间人数暴涨。它能把突发流量精准掐住而不是让整个接口的所有请求都无辜躺枪。5. 生产环境部署与常见问题排查5.1 部署架构建议与内存调优Sentinel 的整体部署包含三部分客户端应用、Dashboard 控制台、规则持久化存储Nacos。客户端分布在各个微服务实例中无论应用部署在虚拟机、容器还是 K8s都不影响。但要注意K8s 环境下需要给每个 Pod 分配独立的port默认 8719而且这个端口不能冲突。如果有多个副本在同一台宿主机上必须显式配置不同的transport.port否则控制台会串数据。Dashboard 控制台建议独立部署不要和应用混在一起。它本身是一个无状态应用可以单节点跑也可以做多节点负载均衡。控制台自带的内存存储会在重启后丢失历史监控数据如果需要长期留存监控曲线需要对接外部存储但这是进阶话题大多数团队默认只保留运行期数据也可以接受。内存方面客户端应用如果接入的资源非常多需要适当调大 JVM 内存。Sentinel 默认会为每个资源分配一些统计结构资源数量上万时内存占用会到几百 MB。我见过一个极端案例用户在代码里用SphU.entry()动态生成了大量资源名比如把商品 ID 拼在资源名后面几天下来资源数超过 10 万直接把堆内存耗尽了。正确做法是资源名保持静态最多加上类型前缀参数级别的区分交给热点参数规则去处理。5.2 控制台看不到应用或数据这是被问得最多的问题没有之一。启动应用之后控制台的“机器列表”里空空如也或者能看到应用但看不到监控数据。排查思路按下面这个顺序来第一确认eager: true是否配置。没配置的话客户端要等第一个 Web 请求进来才会注册到控制台你什么都不访问就永远不出现。第二确认transport.port8719是否被防火墙拦截。客户端向控制台注册的通信走的是这个端口控制台连接不上客户端自然无法采集数据。第三看到应用但 QPS 曲线是平的说明资源埋点没生效。Spring MVC 接口需要引入sentinel-spring-webmvc-adapter并配置 URL 解析器或者使用了SentinelResource但根本没有请求经过该方法。第四检查 Dashboard 本身的日志。控制台启动时会输出客户端注册信息如果日志里完全没有任何注册记录问题大概率出在网络或配置上。5.3 规则不生效或规则丢失规则配置了但请求并没有被拦截这类问题的原因集中在三个方面。第一种规则下发到了控制台但客户端没有同步到。这个要从数据源排查如果用的是 Nacos 持久化方案看 Nacos Server 有没有收到配置变更客户端有没有建立监听可以打开客户端 debug 日志观察规则更新记录。第二种资源的名称不一致。你在控制台上配的是order/createOrder但代码里方法实际用的资源名是OrderController.createOrder规则永远不会命中。Spring WebMVC 适配器默认的资源名格式是HTTP方法:URL比如POST:/order/createOrder而SentinelResource注解的资源名是你自己定义的 value两者完全不同。很多人在这里栽跟头。第三种规则的阈值设置不合理。比如 QPS 阈值设了 1000而实际流量只有 200自然不会触发。可以先手动把阈值调低比如 10马上压一批请求验证验证通过后再调回正常值。规则丢失的问题前面说过几乎都是因为规则存在内存里没做持久化。如果用了 Nacos 数据源还要注意规则文件的 JSON 格式是否正确。一个常见的坑是数组格式的 JSON 中某个规则的字段名拼写错误比如timeWindow写成了timewindowNacos 不报错但客户端解析时会静默失败规则就丢了。5.4 熔断触发后接口一直不恢复熔断触发后正常情况下会等待timeWindow秒后进入半开状态尝试放行少量请求探测恢复情况。但有的场景下熔断一旦开启就再也不恢复所有请求都被拦截。先检查timeWindow是否配置得太长比如配了 300 秒那自然要等 5 分钟。但更常见的原因在慢调用比例熔断的策略上如果count慢调用阈值 RT设置得太低比如 50ms而业务接口的正常 RT 就是 100ms那么统计周期内几乎所有请求都会判定为慢调用熔断恢复后探测请求也全部超时状态永远打不开。建议统计一下接口的正常 RT把阈值设在正常值的两倍以上给抖动留出空间。还有一个隐蔽的坑熔断降级的统计是看“请求数”和“慢调用比例”两个条件同时满足的。如果你设置了最小请求数为 5而熔断恢复后的半开状态只放行了 1 个探测请求这个请求即使成功也要等到下一轮统计周期结束后才可能关闭熔断。此时如果这个周期内请求还是不够多一直不满足最小请求数条件熔断就展示为“不恢复”。5.5 Sentinel 对性能的影响到底有多大这是不少团队在技术选型时的顾虑。Sentinel 客户端是以 Java Agent 或者代码埋点的方式运行在业务进程里的每一次资源请求都会经过 Slot 链的检查确实会有字节级的开销。但实际测试下来单机 QPS 几万以内的场景Sentinel 自身的耗时在微秒到几十微秒级别对比一次 HTTP 调用动辄几毫秒到几十毫秒占比非常小。真正影响性能的反而是不合理的规则设计。比如给每个请求都做一次热点参数限流且参数值数量非常大那底层维护的统计结构会占用不少内存和 CPU再比如给所有接口都加上慢调用统计RT 记录的开销虽然不大但监控数据的采集和上报也会产生额外消耗。我的建议是不要对所有资源都做保护只保护核心链路下订单、支付、商品详情、购物车等。其他查询类接口可以只配置系统保护规则兜底。精细化保护比全量保护效果更好也不容易拖垮性能。6. 从接入到治理的一些个人经验6.1 设计规则前先定义好系统的“水位线”接入 Sentinel 的第一步不是写配置而是搞清楚系统容量。你至少要知道这几个数字单机最高 QPS、核心接口的 RT 基线、数据库连接池上限、下游服务的处理能力。我习惯在项目里维护一份“容量水位表”每个核心接口一行记录接口名、预估单机 QPS、单机阈值、RT 基线、降级策略。这份表既是配置规则的依据也是每次压测后的复盘基准。没有水位线的限流就像不知道车能跑多快就踩油门规则设得再花哨也是盲目的。强烈建议在接入 Sentinel 的同时做一轮核心接口压测哪怕只是单机压测拿到的数据也比拍脑袋强得多。6.2 规则治理是个持续迭代的过程不是一次配置一劳永逸业务流量是会变的促销活动、版本上线、外部合作都可能让某个接口的流量模式发生大幅变化。如果规则是静态的要么误杀正常流量要么漏掉突发流量。我在团队里推行了一个简单有效的机制每周回顾一次 Sentinel 控制台的监控数据对比 QPS 波动和拒绝量评估当前阈值是否合理。有一次大促前我们把下单接口的 QPS 阈值从 2000 调高到 3000结果当天真出现了 2800 的突发流量如果没有提前调整大促第一波流量就会把大量用户挡在门外。反过来活动结束后的第一周我们又会把阈值调回正常值防止异常流量在非活动期间穿透防护。6.3 降级逻辑的设计要比限流本身更用心限流和熔断只是手段降级才是用户真正接触到的东西。如果降级逻辑设计得不好比如 fallback 里又调用了另一个不可用的服务那等于火上浇油再比如降级数据是一张空壳页面用户看到的体验会很差。我在实际项目里总结了一个降级设计原则降级内容必须本地可得、响应快速、语义明确。本地可得指降级数据要从本地缓存或静态资源读取不要再发起远程调用响应快速指降级处理逻辑本身要控制在毫秒级语义明确指返回的数据要能让调用方识别出“这是降级数据”可以在数据里加一个degraded: true的标记方便前端做差异化展示。6.4 给新接入团队的最后几条建议如果你所在的团队刚开始接触 Sentinel我建议按下面的节奏分三步走。第一步先接入控制台和基础限流能力只保护最重要的一两个接口跑通全流程熟悉控制台操作和规则模型。第二步补齐熔断降级、Feign 整合和规则持久化把核心链路的防护建立起来。第三步再逐步扩展到热点参数限流、网关限流、系统保护等高级能力。过程中需要注意版本之间的兼容性是个容易翻车的点。SpringCloud Alibaba、SpringBoot、Sentinel 三者之间版本不匹配会出现注入失败、Feign 降级不生效等诡异问题。推荐直接参考官方版本说明锁定一整套经过验证的版本组合不要只升级其中一个组件。最后分享一个小技巧在开发环境把 Sentinel 的日志级别调成 DEBUG观察SlotChain的初始化过程和规则加载日志能帮你快速定位大多数配置问题。上线前记得调回 INFO否则日志量会非常大。这个习惯帮我节省过无数次排查时间也希望对你管用。