微服务架构里限流降级这件事说起来简单做起来坑多。我见过不少团队在单体应用拆成微服务之后流量一上来某个下游服务扛不住连锁反应把整个链路拖垮最后演变成全站不可用。这类问题不是靠加机器能解决的核心在于入口处有没有一道可靠的流量防护机制。基于SpringBoot、Gateway、Nacos、Sentinel这套组合做限流降级是我在实际项目中反复验证过的一套方案它把网关层的统一流量管控和服务层的细粒度保护结合起来既能挡住突发洪峰又能在依赖服务异常时快速熔断避免故障扩散。这套东西适合谁看如果你正在做微服务架构的流量治理或者手头项目已经拆成了多个服务但还没上防护措施又或者你用过Sentinel但只在单个服务里加注解、没在网关层做过统一限流那这篇内容应该能帮你少走一些弯路。下面我按方案设计、核心细节、实操落地、问题排查几个维度把整套东西拆开讲清楚。1. 方案整体设计与技术选型拆解1.1 为什么是这四个组件凑在一起先说说这套组合的分工逻辑。SpringBoot是底座负责把各个服务快速跑起来这个没什么争议。Gateway作为微服务的统一入口所有外部请求先经过它再路由到后端服务这就给了我们一个天然的流量管控点——在请求进入后端之前做第一道拦截。Nacos承担两个角色服务注册发现和配置中心Gateway需要知道后端服务在哪里Sentinel的规则配置也需要一个地方集中存储和动态推送Nacos正好都能干。Sentinel则是流量防护的核心提供限流、熔断降级、系统自适应保护等能力。这四个组件的关系可以这样理解Gateway是小区大门Nacos是门牌号登记处加公告栏Sentinel是门口的保安SpringBoot是每栋楼本身。外部访客先到大门保安根据当前小区承载能力决定放不放行门牌号从登记处查保安的执勤规则从公告栏动态更新。这个类比虽然粗糙但能帮你快速建立整体认知。为什么不用其他方案比如直接在Gateway里写过滤器做限流用Redis做计数器。这种方案我早期试过问题是限流算法要自己实现滑动窗口、令牌桶这些逻辑写起来容易出bug而且熔断降级、系统保护这些能力全得自己造轮子。Sentinel把这些都封装好了还提供了控制台做规则管理和实时监控省下来的开发成本远大于引入一个组件的学习成本。至于为什么用Nacos而不是Eureka加Config的组合主要是Nacos一个组件同时解决注册发现和配置管理运维复杂度低而且它的配置推送是长轮询机制规则变更能秒级生效这对限流规则调整很关键。1.2 限流和降级的边界怎么划这里有个容易混淆的点限流和降级到底该放在哪一层做。我的经验是分两层。网关层做全局限流针对的是所有进入系统的流量比如按路由维度限制每秒请求数防止某个接口被刷爆。服务层做细粒度降级针对的是服务之间的调用依赖比如订单服务调用库存服务库存服务响应变慢或报错率升高时订单服务这边要快速熔断不再继续等待。这个分层设计的逻辑在于网关层看到的是外部流量它不知道后端服务的实时健康状态所以适合做基于QPS、并发数的粗粒度限流服务层能看到具体的依赖调用情况适合做基于响应时间、异常比例的熔断降级。两层配合外层挡洪峰内层防雪崩。如果只在网关层做限流后端服务之间的调用链出了问题它管不了如果只在服务层做外部突发流量会直接打到每个服务上压力分散但总量没控制住。所以两层都要有各司其职。1.3 规则存储与动态推送的链路设计限流规则不能写死在代码里这是基本原则。线上流量模式随时在变规则要能动态调整。这套方案里规则的流转链路是Sentinel控制台或Nacos配置中心修改规则推送到Nacos配置Gateway和服务通过Nacos客户端监听配置变更拿到新规则后刷新到Sentinel的规则管理器里。具体来说Gateway端需要实现一个从Nacos读取规则并注册到Sentinel的机制服务端则可以通过Sentinel的Nacos数据源适配器直接对接。这里有个细节要注意Gateway的Sentinel集成和普通SpringBoot应用的集成方式不一样Gateway是基于WebFlux的响应式编程模型不能用普通的Sentinel starter得用专门的网关适配包。这个坑我后面在实操部分会详细说。2. 核心细节解析与关键配置要点2.1 Gateway集成Sentinel的特殊之处Gateway用的是Spring WebFlux底层是Netty和Reactor跟传统Servlet容器完全是两套东西。所以你不能直接把spring-cloud-starter-alibaba-sentinel引进来就指望它生效那个starter里的过滤器是基于Servlet的在Gateway里根本不走。正确的做法是引入spring-cloud-alibaba-sentinel-gateway这个包它提供了针对Gateway的全局过滤器和网关限流适配。配置上有几个关键点。第一要在Gateway的配置里开启Sentinel的网关适配通过spring.cloud.sentinel.filter.enabled相关配置控制。第二网关限流规则的维度跟普通规则不同它支持按route维度、按API分组维度来限流。route维度就是针对Gateway里配置的某条路由比如/order/**这条路由单独限流API分组维度则是把一组URL pattern归为一个API组统一限流。实际项目里我一般两个维度都用route维度做粗控API分组做细控。还有一个容易忽略的点Gateway的Sentinel规则里有个resourceMode参数区分ROUTE_ID和CUSTOM_API两种模式。如果你用route维度resource填的是路由ID如果用API分组resource填的是API分组名称。这两个别搞混填错了规则不生效还不报错排查起来很费劲。2.2 Nacos作为规则数据源的接入方式Sentinel原生支持多种数据源Nacos是其中之一。接入方式是在服务里配置一个NacosDataSource指定Nacos的地址、分组、dataIdSentinel会从这个dataId下读取JSON格式的规则。规则变更时Nacos推送配置Sentinel的数据源监听器收到变更后自动刷新规则。这里的关键是规则JSON的格式要对。限流规则的JSON结构包含resource、grade、count、strategy等字段。grade区分QPS模式和线程数模式strategy区分直接、关联、链路三种流控策略。我见过有人把grade填成0以为是QPS其实0是线程数模式1才是QPS模式这个数值对应关系得记牢。另外controlBehavior字段控制流控效果0是快速失败1是Warm Up预热2是排队等待默认快速失败。配置示例大概长这样[ { resource: order-service, grade: 1, count: 100, strategy: 0, controlBehavior: 0 } ]这段规则的意思是对order-service这个资源做QPS限流阈值100直接拒绝策略快速失败。实际项目中阈值要根据压测结果来定不能拍脑袋。2.3 熔断降级规则的参数怎么定熔断降级规则的参数比限流规则更需要经验。Sentinel的熔断器支持三种策略慢调用比例、异常比例、异常数。慢调用比例是指统计窗口内慢调用响应时间超过阈值的调用占比超过设定比例就熔断异常比例是异常数占比超阈值熔断异常数是异常数量绝对值超阈值熔断。参数选择上慢调用比例适合保护响应时间敏感的下游比如商品详情页调用价格服务价格服务响应超过500ms就算慢调用慢调用比例超过50%就熔断。异常比例适合保护那些偶发异常但整体可用的服务比如支付回调异常比例超过30%熔断。异常数适合低频但关键的调用比如对账接口一分钟内异常超过5次就熔断。熔断时长也要斟酌。设太短下游还没恢复就放流量进去等于没熔断设太长下游恢复了流量还进不来影响可用性。我一般从10秒起步观察下游恢复速度再调整。还有个minRequestAmount参数表示统计窗口内最小请求数低于这个数不触发熔断防止样本太少误判。这个值设太小容易误熔断设太大又反应迟钝一般设成阈值的十分之一左右比较合理。3. 完整实操流程与核心环节实现3.1 环境准备与依赖引入先把基础环境搭起来。需要准备Nacos服务端单机模式就够开发用、Sentinel控制台可选但强烈建议装规则管理和监控都靠它、以及一个Gateway服务和一个后端业务服务。Nacos的启动很简单下载后执行启动脚本单机模式加-m standalone参数即可。Sentinel控制台是个SpringBoot的jar包直接java -jar跑起来默认端口8080注意别跟Gateway端口冲突。Gateway服务的依赖里除了常规的spring-cloud-starter-gateway和spring-cloud-starter-alibaba-nacos-discovery关键是要加这两个dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-sentinel/artifactId /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-alibaba-sentinel-gateway/artifactId /dependency第一个是Sentinel核心包第二个是Gateway适配包。版本上要注意跟Spring Cloud Alibaba的版本对齐版本不匹配会出现类找不到或者过滤器不生效的问题。我一般用Spring Cloud Alibaba的BOM统一管理版本避免手动指定版本号踩坑。3.2 Gateway路由与Sentinel规则配置Gateway的路由配置在application.yml里大致结构是spring: cloud: gateway: routes: - id: order-route uri: lb://order-service predicates: - Path/order/** - id: user-route uri: lb://user-service predicates: - Path/user/**这里lb://表示走负载均衡服务名从Nacos注册中心查。路由配好后Sentinel的网关限流规则就可以针对order-route和user-route这两个route ID来配。网关限流规则的注册有两种方式一种是通过Sentinel控制台的网关流控菜单手动配另一种是通过代码或Nacos配置动态加载。生产环境推荐后者因为控制台配的规则默认存在内存里重启就没了。通过Nacos加载的方式需要写一个配置类在启动时从Nacos读取规则并调用GatewayRuleManager.loadRules()注册。这个配置类大概长这样Configuration public class GatewaySentinelConfig { PostConstruct public void init() { // 从Nacos读取网关流控规则 ListGatewayFlowRule rules new ArrayList(); GatewayFlowRule rule new GatewayFlowRule(order-route) .setCount(50) .setIntervalSec(1); rules.add(rule); GatewayRuleManager.loadRules(rules); } }这段代码是硬编码示例实际项目里应该从Nacos配置读取用NacosDataSource包装后注册。setCount(50)表示每秒50个请求setIntervalSec(1)表示统计窗口1秒。这两个参数配合起来就是QPS限流。3.3 服务端熔断降级的代码实现服务端的熔断降级最直接的方式是用SentinelResource注解。比如订单服务调用库存服务的接口SentinelResource(value deductStock, blockHandler deductStockBlockHandler, fallback deductStockFallback) public String deductStock(String skuId, int count) { return stockClient.deduct(skuId, count); } public String deductStockBlockHandler(String skuId, int count, BlockException ex) { return 请求被限流请稍后重试; } public String deductStockFallback(String skuId, int count, Throwable t) { return 库存服务暂时不可用已进入降级逻辑; }这里blockHandler处理的是被限流或熔断时的情况fallback处理的是业务异常。两个方法的签名要注意blockHandler方法参数比原方法多一个BlockExceptionfallback方法参数多一个Throwable且返回值类型要跟原方法一致。签名不对的话注解不生效而且不报错这个坑很隐蔽。熔断规则同样通过Nacos配置加载规则JSON里grade字段在熔断规则里表示熔断策略0是慢调用比例1是异常比例2是异常数。别跟限流规则的grade搞混限流规则里0是线程数、1是QPS两套规则的字段含义不一样这是Sentinel设计上容易让人迷惑的地方。3.4 压测验证与阈值调优规则配完不压测等于没配。我一般用JMeter或者wrk对网关发压观察几个指标网关的QPS是否被限制在阈值附近、被限流的请求返回码是否符合预期Sentinel默认返回429、后端服务的响应时间是否稳定、熔断触发后是否按预期降级。压测时有个细节Sentinel的统计是基于滑动窗口的窗口长度默认1秒分成若干格子。压测刚开始的前一两秒数据可能不准要等窗口填满再看。另外如果压测工具本身成为瓶颈测出来的QPS上不去那就不是限流生效了而是压测机扛不住这个要区分清楚。我一般会先用小流量确认链路通再逐步加压到超过阈值观察限流是否精确拦截。阈值调优的思路是先按理论容量估算一个初始值比如单机Tomcat最大线程数200按每个请求50ms算理论QPS上限4000但实际要考虑GC、IO等待等因素初始阈值设成理论值的60%到70%比较稳妥然后压测微调。调的时候一次只改一个参数改完重新压不然出了问题不知道是哪个参数导致的。4. 常见问题与排查技巧实录4.1 规则不生效的排查路径规则不生效是最高频的问题排查要按链路走。第一步看规则有没有加载成功Sentinel控制台的簇点链路里能不能看到对应的资源名看不到说明资源没被Sentinel识别可能是注解没生效或者依赖没引对。第二步看规则有没有推送成功Nacos配置的dataId和group是否跟代码里读的一致配置内容JSON格式是否合法。第三步看规则是否匹配resource名是否跟代码里的资源名完全一致大小写、前后空格都可能导致不匹配。我遇到过一个典型情况Gateway的网关限流规则配了但完全不生效查了半天发现是spring-cloud-alibaba-sentinel-gateway的版本跟Gateway的版本不兼容适配包里的过滤器没被注册。这种版本兼容问题没有报错只能靠对比版本矩阵和看启动日志里的过滤器注册情况来定位。所以版本对齐这件事再怎么强调都不为过。4.2 限流误杀与漏放的平衡限流阈值设得不准要么误杀正常流量要么该拦的没拦住。误杀的常见原因是阈值设太低或者统计窗口太短。比如设了每秒100的阈值但业务本身有周期性波动整点秒杀时正常流量就超过100这时候限流就把正常用户挡在外面了。解决办法是用Warm Up模式让阈值从低到高逐渐爬升给系统一个预热过程或者用排队等待模式让超出的请求排队而不是直接拒绝。漏放的原因往往是限流维度选错了。比如只按route维度限流但某个route下有多个API其中一个API特别耗资源route整体QPS没超但那个API已经把资源吃光了。这种情况要下沉到API分组维度对耗资源的API单独限流。还有一种漏放是集群限流没做单机限流每台机器独立计数集群总QPS是单机阈值乘以机器数流量不均时某些机器先到阈值被限其他机器还闲着。要精确控制集群总量得上Sentinel的集群限流模式部署一个token server统一计数。4.3 熔断后恢复异常的处置熔断触发后到了熔断时长Sentinel会进入半开状态放一个请求过去试探成功则关闭熔断器失败则继续熔断。这里可能出现的问题是半开状态下放过去的请求恰好又失败了熔断器重新打开如此反复下游明明已经恢复但熔断器一直关不掉。这种情况通常是探测请求本身有问题比如探测的是个重接口恢复初期扛不住。解决办法是调整熔断策略用异常比例而不是异常数让探测更宽容或者缩短熔断时长增加探测频率让恢复更快被感知。还有个情况是熔断器关了但降级逻辑还在走这通常是fallback方法里的逻辑有问题比如降级方法里又调了同一个下游服务形成循环。降级方法里绝对不能调原服务只能返回兜底数据或者走缓存这个原则要守住。4.4 常见问题速查表问题现象可能原因排查方向解决方式规则配了不生效资源名不匹配控制台看簇点链路资源名核对代码资源名与规则resource网关限流完全无效适配包版本不兼容看启动日志过滤器注册对齐Spring Cloud Alibaba版本限流误杀正常流量阈值过低或窗口过短对比压测QPS与阈值调高阈值或改Warm Up模式集群总量超限单机限流未做集群检查是否配置集群模式部署token server做集群限流熔断后无法恢复探测请求持续失败看半开状态探测日志改异常比例策略或缩短熔断时长降级逻辑死循环fallback里调原服务检查fallback方法调用链降级方法只返回兜底数据4.5 实操心得与避坑建议说几个文档里不会写但实际会踩的点。第一Sentinel控制台的规则默认存在内存重启丢失生产环境一定要接Nacos持久化而且要在服务启动时主动拉取一次规则不能只依赖推送否则服务重启到Nacos推送之间的窗口期规则是空的。第二Gateway的Sentinel限流返回的默认响应体是空的429前端拿到这个响应不知道怎么处理最好自定义一个BlockRequestHandler返回统一的JSON错误结构带上错误码和提示信息。第三压测环境跟生产环境的机器配置、网络延迟差异很大压测调好的阈值上生产要打折我一般按压测值的70%上线观察一周再逐步放开。还有一点关于Nacos配置的限流规则的dataId建议按服务名加环境后缀命名比如order-service-sentinel-flow-prodgroup用SENTINEL_GROUP这样多环境多服务的规则管理不会乱。规则变更后Nacos推送有延迟虽然通常是毫秒级但网络抖动时可能到秒级对规则实时性要求极高的场景要考虑这个延迟窗口。最后分享一个监控上的做法Sentinel控制台的实时监控只保留最近几分钟的数据历史数据要自己接。我一般把Sentinel的监控数据通过MetricsRepository定时拉取写到Prometheus或者直接落库配合告警规则做阈值预警。这样限流熔断触发时能第一时间知道而不是等用户反馈才发现。这套组合拳打下来流量治理这块基本就稳了剩下的就是根据业务变化持续调优没有一劳永逸的配置只有持续观察和调整。 
长河君 · 2026/10/27 15:58:40 · 阅读 1.2k SpringBoot+Gateway+Nacos+Sentinel微服务限流降级实战
微服务架构里限流降级这件事说起来简单做起来坑多。我见过不少团队在单体应用拆成微服务之后流量一上来某个下游服务扛不住连锁反应把整个链路拖垮最后演变成全站不可用。这类问题不是靠加机器能解决的核心在于入口处有没有一道可靠的流量防护机制。基于SpringBoot、Gateway、Nacos、Sentinel这套组合做限流降级是我在实际项目中反复验证过的一套方案它把网关层的统一流量管控和服务层的细粒度保护结合起来既能挡住突发洪峰又能在依赖服务异常时快速熔断避免故障扩散。这套东西适合谁看如果你正在做微服务架构的流量治理或者手头项目已经拆成了多个服务但还没上防护措施又或者你用过Sentinel但只在单个服务里加注解、没在网关层做过统一限流那这篇内容应该能帮你少走一些弯路。下面我按方案设计、核心细节、实操落地、问题排查几个维度把整套东西拆开讲清楚。1. 方案整体设计与技术选型拆解1.1 为什么是这四个组件凑在一起先说说这套组合的分工逻辑。SpringBoot是底座负责把各个服务快速跑起来这个没什么争议。Gateway作为微服务的统一入口所有外部请求先经过它再路由到后端服务这就给了我们一个天然的流量管控点——在请求进入后端之前做第一道拦截。Nacos承担两个角色服务注册发现和配置中心Gateway需要知道后端服务在哪里Sentinel的规则配置也需要一个地方集中存储和动态推送Nacos正好都能干。Sentinel则是流量防护的核心提供限流、熔断降级、系统自适应保护等能力。这四个组件的关系可以这样理解Gateway是小区大门Nacos是门牌号登记处加公告栏Sentinel是门口的保安SpringBoot是每栋楼本身。外部访客先到大门保安根据当前小区承载能力决定放不放行门牌号从登记处查保安的执勤规则从公告栏动态更新。这个类比虽然粗糙但能帮你快速建立整体认知。为什么不用其他方案比如直接在Gateway里写过滤器做限流用Redis做计数器。这种方案我早期试过问题是限流算法要自己实现滑动窗口、令牌桶这些逻辑写起来容易出bug而且熔断降级、系统保护这些能力全得自己造轮子。Sentinel把这些都封装好了还提供了控制台做规则管理和实时监控省下来的开发成本远大于引入一个组件的学习成本。至于为什么用Nacos而不是Eureka加Config的组合主要是Nacos一个组件同时解决注册发现和配置管理运维复杂度低而且它的配置推送是长轮询机制规则变更能秒级生效这对限流规则调整很关键。1.2 限流和降级的边界怎么划这里有个容易混淆的点限流和降级到底该放在哪一层做。我的经验是分两层。网关层做全局限流针对的是所有进入系统的流量比如按路由维度限制每秒请求数防止某个接口被刷爆。服务层做细粒度降级针对的是服务之间的调用依赖比如订单服务调用库存服务库存服务响应变慢或报错率升高时订单服务这边要快速熔断不再继续等待。这个分层设计的逻辑在于网关层看到的是外部流量它不知道后端服务的实时健康状态所以适合做基于QPS、并发数的粗粒度限流服务层能看到具体的依赖调用情况适合做基于响应时间、异常比例的熔断降级。两层配合外层挡洪峰内层防雪崩。如果只在网关层做限流后端服务之间的调用链出了问题它管不了如果只在服务层做外部突发流量会直接打到每个服务上压力分散但总量没控制住。所以两层都要有各司其职。1.3 规则存储与动态推送的链路设计限流规则不能写死在代码里这是基本原则。线上流量模式随时在变规则要能动态调整。这套方案里规则的流转链路是Sentinel控制台或Nacos配置中心修改规则推送到Nacos配置Gateway和服务通过Nacos客户端监听配置变更拿到新规则后刷新到Sentinel的规则管理器里。具体来说Gateway端需要实现一个从Nacos读取规则并注册到Sentinel的机制服务端则可以通过Sentinel的Nacos数据源适配器直接对接。这里有个细节要注意Gateway的Sentinel集成和普通SpringBoot应用的集成方式不一样Gateway是基于WebFlux的响应式编程模型不能用普通的Sentinel starter得用专门的网关适配包。这个坑我后面在实操部分会详细说。2. 核心细节解析与关键配置要点2.1 Gateway集成Sentinel的特殊之处Gateway用的是Spring WebFlux底层是Netty和Reactor跟传统Servlet容器完全是两套东西。所以你不能直接把spring-cloud-starter-alibaba-sentinel引进来就指望它生效那个starter里的过滤器是基于Servlet的在Gateway里根本不走。正确的做法是引入spring-cloud-alibaba-sentinel-gateway这个包它提供了针对Gateway的全局过滤器和网关限流适配。配置上有几个关键点。第一要在Gateway的配置里开启Sentinel的网关适配通过spring.cloud.sentinel.filter.enabled相关配置控制。第二网关限流规则的维度跟普通规则不同它支持按route维度、按API分组维度来限流。route维度就是针对Gateway里配置的某条路由比如/order/**这条路由单独限流API分组维度则是把一组URL pattern归为一个API组统一限流。实际项目里我一般两个维度都用route维度做粗控API分组做细控。还有一个容易忽略的点Gateway的Sentinel规则里有个resourceMode参数区分ROUTE_ID和CUSTOM_API两种模式。如果你用route维度resource填的是路由ID如果用API分组resource填的是API分组名称。这两个别搞混填错了规则不生效还不报错排查起来很费劲。2.2 Nacos作为规则数据源的接入方式Sentinel原生支持多种数据源Nacos是其中之一。接入方式是在服务里配置一个NacosDataSource指定Nacos的地址、分组、dataIdSentinel会从这个dataId下读取JSON格式的规则。规则变更时Nacos推送配置Sentinel的数据源监听器收到变更后自动刷新规则。这里的关键是规则JSON的格式要对。限流规则的JSON结构包含resource、grade、count、strategy等字段。grade区分QPS模式和线程数模式strategy区分直接、关联、链路三种流控策略。我见过有人把grade填成0以为是QPS其实0是线程数模式1才是QPS模式这个数值对应关系得记牢。另外controlBehavior字段控制流控效果0是快速失败1是Warm Up预热2是排队等待默认快速失败。配置示例大概长这样[ { resource: order-service, grade: 1, count: 100, strategy: 0, controlBehavior: 0 } ]这段规则的意思是对order-service这个资源做QPS限流阈值100直接拒绝策略快速失败。实际项目中阈值要根据压测结果来定不能拍脑袋。2.3 熔断降级规则的参数怎么定熔断降级规则的参数比限流规则更需要经验。Sentinel的熔断器支持三种策略慢调用比例、异常比例、异常数。慢调用比例是指统计窗口内慢调用响应时间超过阈值的调用占比超过设定比例就熔断异常比例是异常数占比超阈值熔断异常数是异常数量绝对值超阈值熔断。参数选择上慢调用比例适合保护响应时间敏感的下游比如商品详情页调用价格服务价格服务响应超过500ms就算慢调用慢调用比例超过50%就熔断。异常比例适合保护那些偶发异常但整体可用的服务比如支付回调异常比例超过30%熔断。异常数适合低频但关键的调用比如对账接口一分钟内异常超过5次就熔断。熔断时长也要斟酌。设太短下游还没恢复就放流量进去等于没熔断设太长下游恢复了流量还进不来影响可用性。我一般从10秒起步观察下游恢复速度再调整。还有个minRequestAmount参数表示统计窗口内最小请求数低于这个数不触发熔断防止样本太少误判。这个值设太小容易误熔断设太大又反应迟钝一般设成阈值的十分之一左右比较合理。3. 完整实操流程与核心环节实现3.1 环境准备与依赖引入先把基础环境搭起来。需要准备Nacos服务端单机模式就够开发用、Sentinel控制台可选但强烈建议装规则管理和监控都靠它、以及一个Gateway服务和一个后端业务服务。Nacos的启动很简单下载后执行启动脚本单机模式加-m standalone参数即可。Sentinel控制台是个SpringBoot的jar包直接java -jar跑起来默认端口8080注意别跟Gateway端口冲突。Gateway服务的依赖里除了常规的spring-cloud-starter-gateway和spring-cloud-starter-alibaba-nacos-discovery关键是要加这两个dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-sentinel/artifactId /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-alibaba-sentinel-gateway/artifactId /dependency第一个是Sentinel核心包第二个是Gateway适配包。版本上要注意跟Spring Cloud Alibaba的版本对齐版本不匹配会出现类找不到或者过滤器不生效的问题。我一般用Spring Cloud Alibaba的BOM统一管理版本避免手动指定版本号踩坑。3.2 Gateway路由与Sentinel规则配置Gateway的路由配置在application.yml里大致结构是spring: cloud: gateway: routes: - id: order-route uri: lb://order-service predicates: - Path/order/** - id: user-route uri: lb://user-service predicates: - Path/user/**这里lb://表示走负载均衡服务名从Nacos注册中心查。路由配好后Sentinel的网关限流规则就可以针对order-route和user-route这两个route ID来配。网关限流规则的注册有两种方式一种是通过Sentinel控制台的网关流控菜单手动配另一种是通过代码或Nacos配置动态加载。生产环境推荐后者因为控制台配的规则默认存在内存里重启就没了。通过Nacos加载的方式需要写一个配置类在启动时从Nacos读取规则并调用GatewayRuleManager.loadRules()注册。这个配置类大概长这样Configuration public class GatewaySentinelConfig { PostConstruct public void init() { // 从Nacos读取网关流控规则 ListGatewayFlowRule rules new ArrayList(); GatewayFlowRule rule new GatewayFlowRule(order-route) .setCount(50) .setIntervalSec(1); rules.add(rule); GatewayRuleManager.loadRules(rules); } }这段代码是硬编码示例实际项目里应该从Nacos配置读取用NacosDataSource包装后注册。setCount(50)表示每秒50个请求setIntervalSec(1)表示统计窗口1秒。这两个参数配合起来就是QPS限流。3.3 服务端熔断降级的代码实现服务端的熔断降级最直接的方式是用SentinelResource注解。比如订单服务调用库存服务的接口SentinelResource(value deductStock, blockHandler deductStockBlockHandler, fallback deductStockFallback) public String deductStock(String skuId, int count) { return stockClient.deduct(skuId, count); } public String deductStockBlockHandler(String skuId, int count, BlockException ex) { return 请求被限流请稍后重试; } public String deductStockFallback(String skuId, int count, Throwable t) { return 库存服务暂时不可用已进入降级逻辑; }这里blockHandler处理的是被限流或熔断时的情况fallback处理的是业务异常。两个方法的签名要注意blockHandler方法参数比原方法多一个BlockExceptionfallback方法参数多一个Throwable且返回值类型要跟原方法一致。签名不对的话注解不生效而且不报错这个坑很隐蔽。熔断规则同样通过Nacos配置加载规则JSON里grade字段在熔断规则里表示熔断策略0是慢调用比例1是异常比例2是异常数。别跟限流规则的grade搞混限流规则里0是线程数、1是QPS两套规则的字段含义不一样这是Sentinel设计上容易让人迷惑的地方。3.4 压测验证与阈值调优规则配完不压测等于没配。我一般用JMeter或者wrk对网关发压观察几个指标网关的QPS是否被限制在阈值附近、被限流的请求返回码是否符合预期Sentinel默认返回429、后端服务的响应时间是否稳定、熔断触发后是否按预期降级。压测时有个细节Sentinel的统计是基于滑动窗口的窗口长度默认1秒分成若干格子。压测刚开始的前一两秒数据可能不准要等窗口填满再看。另外如果压测工具本身成为瓶颈测出来的QPS上不去那就不是限流生效了而是压测机扛不住这个要区分清楚。我一般会先用小流量确认链路通再逐步加压到超过阈值观察限流是否精确拦截。阈值调优的思路是先按理论容量估算一个初始值比如单机Tomcat最大线程数200按每个请求50ms算理论QPS上限4000但实际要考虑GC、IO等待等因素初始阈值设成理论值的60%到70%比较稳妥然后压测微调。调的时候一次只改一个参数改完重新压不然出了问题不知道是哪个参数导致的。4. 常见问题与排查技巧实录4.1 规则不生效的排查路径规则不生效是最高频的问题排查要按链路走。第一步看规则有没有加载成功Sentinel控制台的簇点链路里能不能看到对应的资源名看不到说明资源没被Sentinel识别可能是注解没生效或者依赖没引对。第二步看规则有没有推送成功Nacos配置的dataId和group是否跟代码里读的一致配置内容JSON格式是否合法。第三步看规则是否匹配resource名是否跟代码里的资源名完全一致大小写、前后空格都可能导致不匹配。我遇到过一个典型情况Gateway的网关限流规则配了但完全不生效查了半天发现是spring-cloud-alibaba-sentinel-gateway的版本跟Gateway的版本不兼容适配包里的过滤器没被注册。这种版本兼容问题没有报错只能靠对比版本矩阵和看启动日志里的过滤器注册情况来定位。所以版本对齐这件事再怎么强调都不为过。4.2 限流误杀与漏放的平衡限流阈值设得不准要么误杀正常流量要么该拦的没拦住。误杀的常见原因是阈值设太低或者统计窗口太短。比如设了每秒100的阈值但业务本身有周期性波动整点秒杀时正常流量就超过100这时候限流就把正常用户挡在外面了。解决办法是用Warm Up模式让阈值从低到高逐渐爬升给系统一个预热过程或者用排队等待模式让超出的请求排队而不是直接拒绝。漏放的原因往往是限流维度选错了。比如只按route维度限流但某个route下有多个API其中一个API特别耗资源route整体QPS没超但那个API已经把资源吃光了。这种情况要下沉到API分组维度对耗资源的API单独限流。还有一种漏放是集群限流没做单机限流每台机器独立计数集群总QPS是单机阈值乘以机器数流量不均时某些机器先到阈值被限其他机器还闲着。要精确控制集群总量得上Sentinel的集群限流模式部署一个token server统一计数。4.3 熔断后恢复异常的处置熔断触发后到了熔断时长Sentinel会进入半开状态放一个请求过去试探成功则关闭熔断器失败则继续熔断。这里可能出现的问题是半开状态下放过去的请求恰好又失败了熔断器重新打开如此反复下游明明已经恢复但熔断器一直关不掉。这种情况通常是探测请求本身有问题比如探测的是个重接口恢复初期扛不住。解决办法是调整熔断策略用异常比例而不是异常数让探测更宽容或者缩短熔断时长增加探测频率让恢复更快被感知。还有个情况是熔断器关了但降级逻辑还在走这通常是fallback方法里的逻辑有问题比如降级方法里又调了同一个下游服务形成循环。降级方法里绝对不能调原服务只能返回兜底数据或者走缓存这个原则要守住。4.4 常见问题速查表问题现象可能原因排查方向解决方式规则配了不生效资源名不匹配控制台看簇点链路资源名核对代码资源名与规则resource网关限流完全无效适配包版本不兼容看启动日志过滤器注册对齐Spring Cloud Alibaba版本限流误杀正常流量阈值过低或窗口过短对比压测QPS与阈值调高阈值或改Warm Up模式集群总量超限单机限流未做集群检查是否配置集群模式部署token server做集群限流熔断后无法恢复探测请求持续失败看半开状态探测日志改异常比例策略或缩短熔断时长降级逻辑死循环fallback里调原服务检查fallback方法调用链降级方法只返回兜底数据4.5 实操心得与避坑建议说几个文档里不会写但实际会踩的点。第一Sentinel控制台的规则默认存在内存重启丢失生产环境一定要接Nacos持久化而且要在服务启动时主动拉取一次规则不能只依赖推送否则服务重启到Nacos推送之间的窗口期规则是空的。第二Gateway的Sentinel限流返回的默认响应体是空的429前端拿到这个响应不知道怎么处理最好自定义一个BlockRequestHandler返回统一的JSON错误结构带上错误码和提示信息。第三压测环境跟生产环境的机器配置、网络延迟差异很大压测调好的阈值上生产要打折我一般按压测值的70%上线观察一周再逐步放开。还有一点关于Nacos配置的限流规则的dataId建议按服务名加环境后缀命名比如order-service-sentinel-flow-prodgroup用SENTINEL_GROUP这样多环境多服务的规则管理不会乱。规则变更后Nacos推送有延迟虽然通常是毫秒级但网络抖动时可能到秒级对规则实时性要求极高的场景要考虑这个延迟窗口。最后分享一个监控上的做法Sentinel控制台的实时监控只保留最近几分钟的数据历史数据要自己接。我一般把Sentinel的监控数据通过MetricsRepository定时拉取写到Prometheus或者直接落库配合告警规则做阈值预警。这样限流熔断触发时能第一时间知道而不是等用户反馈才发现。这套组合拳打下来流量治理这块基本就稳了剩下的就是根据业务变化持续调优没有一劳永逸的配置只有持续观察和调整。