先说一个很多团队都会踩的场景网关做了 QPS 限流依然打挂了下游服务。这个场景用阿里巴巴开源的 Sentinel 来做流量治理会比只在网关写死一个阈值可靠得多。我理解 Sentinel 是一个以“资源”为圆心的流量治理框架把限流、熔断、热点参数保护和系统自适应保护统一到一套规则模型里再配合 Dashboard 做可视化的规则观察与运维。它不是单纯“拦请求”的工具更合适的定位是给系统留出可控的呼吸余地。这篇文章适合正在做微服务拆分、对接口稳定性有要求、想把限流规则从代码里解放出来的人下面这些经验更多是我在网关、订单服务和压测环境中反复调出来的体感不是官方文档的复述。1. 为什么流量治理会从“加机器”变成“精细控流”1.1 一次压测事故给我的教训之前我们团队的服务架构不算复杂一个网关后面挂了四个订单服务实例。平时 QPS 不高限流规则只放在网关层服务端几乎没有兜底。结果一次压测从 1000 QPS 开始跑网关看着还挺正常但订单服务 CPU 直接到 90%平均响应时间从 80ms 一路涨到 2300ms最后健康检查失败实例被摘掉流量又倾斜到剩余实例上整体雪崩。这个事故让我意识到网关限流是粗粒度入口控制它只能保证“进到系统里的流量不超标”不能保证“每个下游服务都被保护到”。订单服务依赖数据库连接、外部库存接口、Redis 缓存任何一条链路都可能成为瓶颈。如果只把阈值放在网关服务端完全裸奔那等于把稳定性押在单一节点上。1.2 突刺流量才是常态线上流量不是压测那样的匀速曲线。秒杀、运营活动、定时任务集中触发、爬虫、重试风暴都会带来大量瞬时的流量尖刺。如果规则是静态写死的要么阈值配高了挡不住要么阈值配低了误伤正常用户。Sentinel 解决这类问题的思路是把规则和业务代码解耦规则可以动态调整同时在一个资源上叠加不同类型的保护。比如接口 QPS 超了快速失败RT 持续变高自动熔断热点参数被刷时单独限制系统整体负载高了再兜底限流。它不是某一个功能的堆叠而是一套组合拳。1.3 选择 Sentinel 的三个理由规则动态化不需要改代码重启服务就能调整阈值。配合 Nacos、Apollo 这类配置中心还能做成规则下发平台。保护维度全支持 QPS、并发线程数、响应时间、异常比例、热点参数、系统负载等不同维度的规则覆盖了绝大多数稳定性场景。社区和生态成熟和 Spring Cloud Gateway、Spring Cloud Alibaba、Dubbo 都有适配接入成本比从零自研低很多。如果你之前用过 Hystrix应该知道 Hystrix 偏向线程池隔离规则基本是静态配置社区也基本停止维护。Sentinel 的做法更轻量默认用信号量 计数器模式额外开销小很多。2. Sentinel 的基础模型资源、规则、Slot 链与统计窗口2.1 资源是切入点Sentinel 里的“资源”可以理解成你想保护的一个入口。它可以是一个 URL、一个 Dubbo 接口、一个方法甚至是一条 SQL。接入时埋点位置决定了你能挡住什么。在 Spring 工程里最常用的埋点方式是SentinelResource注解SentinelResource(value createOrder, blockHandler createOrderBlock, fallback createOrderFallback) public Order createOrder(OrderForm form) { return orderService.create(form); }blockHandler是在触发限流、熔断等规则时走的逻辑fallback是业务方法抛出异常时走的兜底。很多同学会把这两个搞混前者是 Sentinel 在入口处拦截后者是异常处理两者负责的阶段不一样。有一点要特别注意SentinelResource注解需要引入sentinel-annotation-aspectj依赖并开启 Spring AOP 切面否则注解不会生效。我见过有人配了注解但完全没有规则以为限流生效了等到压测才发现流量根本没被统计。2.2 规则与效果器规则描述的是“什么条件下触发保护”效果器描述的是“触发之后怎么做”。Sentinel 默认支持快速失败、Warm Up 预热、匀速排队三种流控效果熔断后也可以选择快速失败或走 fallback。规则类型判断维度典型效果FlowRuleQPS、并发线程数快速失败、Warm Up、匀速排队DegradeRuleRT、异常比例、异常数熔断降级、快速失败ParamFlowRule热点参数 QPS精准拦截参数维度超卖SystemRule系统负载、CPU、入口 QPS全局自适应保护我通常建议先把 FlowRule 和 DegradeRule 配上这是保命的基本盘热点参数和系统规则属于进阶项根据实际业务需要再叠加。2.3 Slot 链与统计窗口Sentinel 统计的底层不是简单计数器而是一个叫 LeapArray 的滑动窗口结构。固定窗口的问题是59 秒的时候放进来 1 万请求00 秒的时候又放进来 1 万请求单独看每个窗口都没超阈值但瞬时压力其实已经翻倍。滑动窗口把 1 秒切成多个小格子默认切成 2 个 500ms 的窗口随时间推进不断滑动。这样哪怕请求都挤在窗口边界也不会被漏掉。统计越精细 CPU 开销也会越高所以默认切 2 格是性能和精度之间比较均衡的选择。Slot Chain 是规则执行的链条比如在一个请求进来时会依次经过流控 Slot、熔断 Slot、热点 Slot、系统保护 Slot。每个 Slot 只负责自己的检查谁触发谁就返回 BlockException。理解这个链条的意义在于当你看到请求被拦截时要先定位是哪一个 Slot 的问题而不是瞎调一个阈值。3. Dashboard 部署与客户端接入从可视化到规则下发的边界3.1 本地启动 DashboardSentinel Dashboard 是一个独立的 Java 应用下载官方 release 包后可以直接 jar 启动java -Dserver.port8080 \ -Dcsp.sentinel.dashboard.serverlocalhost:8080 \ -Dproject.namesentinel-dashboard \ -jar sentinel-dashboard-1.8.6.jar启动完成后浏览器访问http://localhost:8080默认账号密码是sentinel/sentinel。刚登录时机器列表是空的因为客户端要主动上报心跳Dashboard 才会感知到应用。这里有个细节-Dcsp.sentinel.dashboard.server这个参数对 Dashboard 本身也要配否则 Dashboard 自己上报的数据会串。客户端的-Dproject.name表示应用在控制台里的名字一个应用多个实例建议用同一个 project name方便看集群维度数据。3.2 客户端接入与参数语义如果项目没有用 Spring Cloud Alibaba需要手动加两个依赖dependency groupIdcom.alibaba.csp/groupId artifactIdsentinel-core/artifactId version1.8.6/version /dependency dependency groupIdcom.alibaba.csp/groupId artifactIdsentinel-transport-simple-http/artifactId version1.8.6/version /dependency然后在 JVM 启动参数里加上-Dcsp.sentinel.dashboard.serverlocalhost:8080 -Dproject.nameorder-service -Dcsp.sentinel.api.port87198719是客户端暴露的本地 API 端口Dashboard 会通过这个端口拉取规则和统计数据。如果被占用Sentinel 会自动尝试下一个端口但日志里会显示实际使用的端口。接入后日志里能看到类似[Sentinel] log output path的信息说明客户端已经正常初始化。第一次调用被保护的资源后Dashboard 上才会看到对应资源名这是因为 Sentinel 是懒加载统计模型没有流量就不会上报。3.3 规则持久化为什么不能直接依赖控制台官方 Dashboard 可以把规则下发到客户端但规则只存在客户端内存和控制台内存里。应用重启规则没了控制台重启规则也没了。所以它适合做联调、观察和临时验证不适合当生产环境的唯一配置源。生产环境的规则一定要落到配置中心比如 Nacos、Apollo、Redis。后面我专门讲推拉模式这一节只需要记住别把生产规则直接放在 Dashboard 里手工点。4. 规则配置与效果器限流、熔断、热点、系统保护怎么选4.1 FlowRule 配置例子限流规则是最常用的。以“创建订单”接口为例先定义资源名再通过 FlowRuleManager 加载规则FlowRule rule new FlowRule(createOrder); rule.setGrade(RuleConstant.FLOW_GRADE_QPS); rule.setCount(200); rule.setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_WARM_UP); rule.setWarmUpPeriodSec(10); FlowRuleManager.loadRules(Collections.singletonList(rule));这里的关键参数是grade和count。FLOW_GRADE_QPS表示每秒最多通过 200 个请求FLOW_GRADE_THREAD表示并发线程数超过 200 时直接拒绝。线程数维度适合保护那些执行时间不稳定、容易堆积线程的任务。CONTROL_BEHAVIOR_WARM_UP是我个人比较喜欢的效果器。它让流量从较低阈值缓慢爬升到目标值避免刚启动的服务被大量流量直接打崩。Warm Up 尤其适合缓存还没预热、连接池还没建立完整的场景。4.2 熔断降级规则限流解决的是“来太多”熔断解决的是“下游不行了”。当被调用的服务 RT 持续升高或者异常比例超过阈值就不应该再继续打进去而是快速失败或走 fallback。DegradeRule rule new DegradeRule(createOrder); rule.setGrade(RuleConstant.DEGRADE_GRADE_RT); rule.setCount(300); rule.setTimeWindow(10); DegradeRuleManager.loadRules(Collections.singletonList(rule));这个例子表示如果 createOrder 的平均响应时间超过 300ms持续一段时间后触发熔断熔断窗口为 10 秒。10 秒后进入半开状态放少量请求试探恢复情况。很多人只关注异常熔断却忽视了 RT 熔断。实际上高延迟对用户体感的伤害不亚于报错而且延迟会引起线程堆积最终拖垮整个服务。所以核心链路上RT 熔断和异常熔断我都建议同时配。4.3 热点参数限流热点参数限流解决的是“某个具体参数被刷”的问题。整体 QPS 不高但同一个商品 ID 被反复查询数据库扛不住或者某个用户 ID 在疯狂重试拖慢全局。ParamFlowRule hotRule new ParamFlowRule(queryStock); hotRule.setParamIdx(0); hotRule.setCount(100); ParamFlowItem item new ParamFlowItem(); item.setObject(商品ID10086); item.setCount(10); hotRule.setParamFlowItemList(Collections.singletonList(item)); ParamFlowRuleManager.loadRules(Collections.singletonList(hotRule));paramIdx表示资源埋点方法的第几个参数作为热点维度。默认所有参数值共享count的阈值如果某个特定值命中ParamFlowItem就走它自己的阈值。这里要提醒热点参数限流依赖入参来源如果用 Spring Cloud Gateway 做接入参数可能不在方法参数上而是在 HTTP Header 或 URL 参数里需要额外适配。不要想当然认为一个注解就能覆盖所有场景。4.4 系统保护规则系统规则是兜底策略它不针对某个接口而是根据当前系统的整体负载来自动调整入口流量。比如系统 Load 超过阈值就拒绝多余的入口流量。SystemRule rule new SystemRule(); rule.setHighestSystemLoad(10); rule.setAvgRt(500); SystemRuleManager.loadRules(Collections.singletonList(rule));这类规则适合放在核心服务入口作为最后一道防线。但不要把系统规则当常规限流用因为它的判断周期和粒度都比较粗不适合精确控制某个接口。5. Spring Cloud Gateway 接入 Sentinel路由、API 分组和避坑记录5.1 网关限流的特殊位置网关是所有流量的必经之路非常适合做第一层限流。但网关限流不能替代服务端限流因为网关并不知道下游每个实例的连接池容量、缓存命中率和数据库压力。我见过的正确姿势是网关层按路由维度限制总入口流量服务端按核心接口维度做精细化限流。两边阈值要有层级关系比如网关给订单路由限 500 QPS订单服务核心接口再限 200 QPS防止网关放行过多后服务端被打穿。5.2 基础依赖与配置使用 Spring Cloud Gateway 时Sentinel 提供了专门的适配包。需要引入com.alibaba.csp:sentinel-spring-cloud-gateway-adaptercom.alibaba.csp:sentinel-transport-simple-httpcom.alibaba.csp:sentinel-annotation-aspectj然后注册两个核心 BeanConfiguration public class GatewaySentinelConfig { Bean public SentinelGatewayBlockExceptionHandler sentinelGatewayBlockExceptionHandler() { return new SentinelGatewayBlockExceptionHandler(); } Bean public SentinelGatewayFilter sentinelGatewayFilter() { return new SentinelGatewayFilter(); } }SentinelGatewayFilter负责在请求链路中创建 Sentinel 统计入口SentinelGatewayBlockExceptionHandler负责在触发限流时返回统一的错误响应。如果 filter 注册顺序不对限流效果会很奇怪建议在配置类里显式控制顺序。5.3 路由维度 vs API 维度规则网关限流有两类资源粒度路由维度以routeId作为资源名一个路由一条规则。API 分组维度把多个路径聚合到一个 API 定义下比如/api/order/**和/order/**都算同一个资源。SetGatewayFlowRule rules new HashSet(); rules.add(new GatewayFlowRule(order-service) .setResourceMode(SentinelGatewayConstants.RESOURCE_MODE_ROUTE_ID) .setCount(500) .setIntervalSec(1)); GatewayRuleManager.loadRules(rules);很多人在刚开始接入时有个误区以为资源名是 URL 路径。实际上路由维度的资源名是routeId也就是你在 Spring Cloud Gateway 配置里给路由起的名字。如果规则配成了/order/**大概率不生效因为 Sentinel 在网关层拿到的资源名并不是路径。API 分组解决的是更灵活的场景。比如你有一个/api/payment/**的路由但只想对其中涉及支付的部分路径做更严格限制用 API 分组可以把这些路径聚合成一个独立资源进行限流。5.4 实际踩过的坑接入网关限流后我遇到过几个比较典型的坑这里分享出来第一Block 响应格式太简陋。默认的兜底响应只包含错误信息前端根本分不清是限流还是后端故障。建议通过GatewayCallbackManager.setBlockHandler自定义返回 JSON包含业务错误码、提示信息和触发规则类型这样排查问题会快很多。第二规则生效有延迟。网关适配器底层也是从本地规则仓库取规则如果使用loadRules加载修改后需要全量覆盖且多个网关实例不会自动同步。后来把规则数据源接到 Nacos才真正解决多实例一致性问题。第三和全局过滤器执行顺序冲突。如果项目里自定义了全局过滤器且执行顺序在 SentinelGatewayFilter 之前那么一些请求可能绕过统计。建议把 SentinelGatewayFilter 的 order 调小尽量早执行避免漏统计。6. 规则同步的推拉模式生产环境最终形态与稳定性核查点6.1 原生模式为什么不可取原生模式下每个客户端通过loadRules()本地加载规则规则只存在于各自内存。控制台修改规则时它会把规则推给对应机器但机器重启后规则丢失同时多实例场景下A 实例改了规则B、C 实例不知道流量稍大就会出现“一半实例在限流一半实例裸奔”的诡异状况。有一次我们调整订单超时熔断阈值只在一个实例上完成了验证另一个实例还是老规则结果线上流量随机路由老实例继续报错排查了很久才发现是规则不同步。从那以后我坚持一个原则生产环境的规则必须统一收敛到配置中心。6.2 拉模式与推模式的取舍在生产环境中规则同步方式主要分两种模式实现方式优点缺点拉模式客户端定时从文件、DB、配置中心拉取规则实现简单依赖少实时性差故障恢复慢推模式配置中心主动通知客户端变更实时性好规则统一管理需要改造数据源接入成本高我推荐用推模式。Sentinel 客户端本身提供了多种 DataSource比如NacosDataSource、ApolloDataSource、RedisDataSource只要把规则数据源注册到对应的 RuleManager配置中心一变客户端就会自动更新。还要记住一个重要概念这些规则都是单机维度的。三个网关实例都配置 100 QPS系统总入口其实是 300 QPS。如果要求全局精确限流还需要引入 Sentinel 的 ClusterFlow 模式或者提前按实例数拆分每台阈值。大多数业务场景下按单机阈值控制已经够用但架构评审时要心里有数。6.3 以 Nacos 为配置中心的推送方案先引入依赖dependency groupIdcom.alibaba.csp/groupId artifactIdsentinel-datasource-nacos/artifactId version1.8.6/version /dependency注册数据源ReadableDataSourceString, ListFlowRule flowRuleDataSource new NacosDataSource( localhost:8848, DEFAULT_GROUP, sentinel-flow-rules, source - JSON.parseObject(source, new TypeReferenceListFlowRule() {}) ); FlowRuleManager.register2Property(flowRuleDataSource.getProperty());这里的关键是sentinel-flow-rules这个 dataId里面的内容是一段 JSON 数组。在 Nacos 控制台维护好这段配置后客户端会监听变更并实时更新内存规则。生产环境上可以把 Dashboard 的规则发布能力改造为基础版本发布到 Nacos或者直接用 Nacos 控制台作为规则管理入口。控制台主要用于观察实时流量和查看资源拓扑规则配置的工作一般不必依赖控制台完成。6.4 稳定运行的核查点把规则放到配置中心之后还要做好几个核查点环境隔离不同环境用不同的 Nacos namespace 或 group避免测试环境规则污染生产。变更审计配置中心自带历史版本规则变更要通过配置中心操作记录方便回溯。格式校验规则 JSON 发布前要校验字段类型和枚举值格式错误会导致客户端解析失败。压测验证每次调整规则后至少压一轮核心接口确认新阈值不会误杀正常流量。有一点我最开始在实践里吃过亏规则变更后虽然客户端刷新了但并没有一个通用机制告诉我们“哪些资源用了哪些规则”。我建议在接入初期就把资源命名规范定好比如统一使用接口路径或业务语义清晰的名称否则后面资源多了规则和资源的对应关系会非常混乱。如果你也刚开始接 Sentinel先把 Dashboard 跑起来在网关和一个核心服务上各配一条 QPS 规则把从埋点到控制台观察的链路走通再考虑接 Nacos 做规则持久化。别一上来就追求大而全的规则平台流量治理本质上是一个持续迭代、逐步体系化的过程。