Dubbo 流量控制这个问题我大概绕了三年才敢说摸到了点门道。高并发场景下系统通常并不是被真实流量打垮的而是被超时、重试、连接堆积这些连锁反应拖垮的。这篇文章从一个生产事故说起完整拆解 Dubbo 框架下服务端限流、消费端自我保护、Nacos 动态配置、网关前置拦截的一整套流量控制打法适合正在从“能跑”走向“扛得住”的团队参考。1. 高并发流量压力从哪里来先看清Dubbo的压力模型1.1 一次深夜事故流量没有想象中那么大先说一个我亲自经历过的事故。某个核心交易服务高峰期的 QPS 撑死也就 3000听起来不算高但那个晚上它硬生生把下游三个服务全部拖死最后把自己也拖死了。当时我们第一反应是“流量暴涨”可监控一看入口流量根本没涨多少。真正的问题出在调用链路上上游服务超时后不断重试重试的请求又打到另外一个服务上那个服务慢下来之后又引发更大面积的超时于是整个集群在半小时内陷入了“超时-重试-堆积-更慢”的循环。等我们反应过来线程池已经全被占满新请求全部排队连运维执行命令都开始卡顿。这个案例让我彻底明白了一个道理高并发场景下的 Dubbo 治理防的不是正常流量防的是异常流量引发的雪崩效应。正常流量再怎么涨只要容量规划合理无非是多加点机器但重试风暴和连接堆积一旦形成加机器都来不及因为每台新机器上线后会立刻被打满。所以做流量控制第一步不是急着调参数而是先把 Dubbo 的压力模型搞清楚请求从消费者发出经过注册中心找到提供者建立 TCP 连接进入提供者的线程池最后执行业务逻辑。这四个环节里面任何一个环节不做限制都会成为雪崩的起点。1.2 提供者和消费者视角的流量控制目标流量控制在 Dubbo 里其实分两个方向很多文章混在一起讲导致实操的时候不知道参数该配在谁那边。服务提供者关心的指标是我最多能同时处理多少个请求超过这个数量之后新来的请求应该立刻拒绝还是排队等待。这是典型的“自我保护”思路防止自己被大流量冲垮。对应的参数有executes、threads、accepts以及基于 TPS 的过滤器。服务消费者关心的是我最多能同时向某个提供者发起多少个调用如果对方已经慢了我不能无限地堆积请求。这是“上游保护”思路防止自己把下游拖垮。对应的参数有actives、timeout、retries。还有一个容易被忽略的维度是连接数。Dubbo 默认使用共享连接每个消费者和提供者之间维护一组 TCP 连接。很多人以为连接数越多吞吐越高实际上在高并发下连接数过多反而会导致内存占用飙升、线程上下文切换频繁性能未必成正比例增长。这就引出了下一节要讲的第一个关键点连接和线程池才是流量的第一道闸门。2. 最先要堵住的洞线程池、连接数与接受数设置原则2.1 Dubbo线程池模型默认值不一定适合你的业务Dubbo 的线程池模型说起来不复杂提供者启动一个固定的线程池默认是fixed大小是 200。每个请求占用一个线程执行业务逻辑任务队列默认是 0也就是SynchronousQueue线程不够用的时候直接拒绝。这个设计在早期是很实用的因为fixed线程池满了会快速失败不会像无界队列那样把请求都攒在内存里最终把 JVM 撑爆。问题在于200 这个默认值是拍脑袋拍出来的它不一定适合所有接口。我见过一个团队所有接口都走同一个线程池其中一个慢接口平均耗时 800ms另外几十个快接口平均只要 10ms。高峰期慢接口只要来上几十个请求线程池就被占了一半快接口全部开始排队。这种场景下线程池大小反而不是核心问题核心问题是慢接口拖累了整个进程。所以 Dubbo 提供了一些关键的线程池参数实际配置的时候务必搞清楚每一项的含义参数配置层默认值作用threads协议层200fixed线程池业务线程池大小决定最大并发处理能力queues协议层0线程池排队容量0表示不排队直接拒绝accepts协议层0每个提供者允许建立的最大TCP连接数0表示不限executes服务/方法层0同一方法最大并发执行数0表示不限actives消费者层0消费者端每URL最大活跃调用数0表示不限timeout消费者层1000ms一次RPC调用等待的最大时间retries消费者层2调用失败后的重试次数不含第一次实操中我的建议是threads不要拍脑袋设先通过压测找到单机能撑住的并发数再留 30%-50% 的余量。慢接口和快接口混在一起的服务优先考虑按线程池权重隔离或者直接把executes配到方法级别而不是一股脑全丢给同一个线程池。2.2 用利特尔定律把目标QPS换算成并发数很多人不知道executes到底该配多少我教大家一个最简单的换算方法——利特尔定律。它的公式是并发数 目标QPS × 平均响应时间。举个例子某个下单接口目标支撑 800 QPS压测得出平均响应时间是 45ms那么它需要的并发数是 800 × 0.045 36。也就是说这个接口的executes配 40 左右是合理的配 200 就太多了因为正常流量永远用不到 200 个并发反而给异常流量留下了巨大的吞噬空间。反过来算也很有用如果你的接口并发上限是 50平均响应时间 100ms那么理论上它能支撑的最大 QPS 是 50 ÷ 0.1 500。超过 500 QPS 之后请求就会开始排队、超时、报错。这个换算方法是我每次做容量评估必用的公式。配合executes使用你能把一个接口的流量上限提前算出来而不是等到线上被打爆了才猜。注意这个公式适用于理想情况实际还要考虑线程切换开销、GC停顿、网络波动所以建议把算出来的数值再打一个 0.8 的折扣留出安全边际。2.3 连接上限为什么不是越多越好accepts这个参数很多团队从来没配过。默认 0 表示不限连接数这在高并发下相当危险。Dubbo 的通信模型是长连接复用的消费者与提供者之间通过 Netty 维护连接。当服务规模大了比如一台提供者背后挂了 50 个消费者节点每个节点建立 20 条连接那这个提供者就要扛 1000 条连接。Netty 本身能扛住几千条连接但每条连接都有对应的内存缓冲区、心跳定时器等资源连接数上来之后GC 压力也会明显增大。我自己踩过的坑是某个提供者accepts没有限制结果消费者扩容之后建立了两千多条连接服务还没被流量打垮先被 Full GC 打垮了。后来在协议层配置了accepts: 1000超出的连接直接拒绝服务反而稳定了很多。不要盲目追求连接多连接够用就行通常一个消费者对同一个提供者维护 10-50 条连接就足够撑起很高的吞吐。还有一个细节要注意dubbo:protocol层还提供了threads和queues两个参数它们配合起来决定了请求进入线程池之后的排队行为。queues默认 0也就是SynchronousQueue线程池满了直接拒绝。如果你设置了一个很大的queues看起来请求不会立刻被拒绝但队列里积压的请求会占用大量内存而且等到队列里的请求真正被执行时消费者那边可能早就超时了。这种“伪排队”是非常坑的我建议queues保持默认 0不要随意调大。3. 服务端限流不让扛不住的请求进入业务逻辑3.1 方法级executes限流实战理解了线程池之后再来看服务端限流。Dubbo 原生最常用的限流方式就是executes它可以配置在服务级别也可以配置在方法级别。方法级别的配置方式XML 是这样的dubbo:service interfacecom.example.OrderService version1.0.0 dubbo:method namecreateOrder executes50/ dubbo:method namequeryOrder executes200/ /dubbo:service如果用的是注解和 YAML 配置思路类似重点是executes只对对应的method生效。这样做的好处非常明显快接口和慢接口彻底分开限流慢接口再怎么堵也不会占满整个服务的线程池。比如上面的createOrder只允许 50 个并发后面来的流量直接拒绝而queryOrder还能承受 200 个并发核心读链路还是通的。executes的生效机制是 Dubbo 内部维护了一个RpcStatus统计每次进入方法前会检查当前活跃请求数超过阈值就抛RpcException异常会被包装成调用失败返回给消费者。注意这个限流是基于JVM内存的只在当前提供者节点内生效。如果一个服务有 10 个节点每个节点executes50那么整个集群的实际并发承载量是 500不是 50。这也引出另一个决策点假如你的服务部署了 20 个节点你希望整个集群最多只接收 5000 并发那每个节点的executes应该是 250而不是 5000。做容量规划时一定要先想清楚“单机限流”还是“集群限流”。3.2 TPS限流与令牌桶思想的落地executes限制的是并发数但如果有些流量本身并发不高、却导致每秒请求数瞬间飙升比如秒杀抢购、限时活动这类场景还需要另一个维度的控制TPS 限流。Dubbo 内置了tpsLimit过滤器配置方式很简单。首先在提供者上启用过滤器dubbo:provider filtertpsLimit/然后给服务配置 TPS 上限dubbo:service interfacecom.example.OrderService dubbo:method namecreateOrder tps100/ /dubbo:servicetps的含义是每秒钟最多允许执行 100 次调用超过的请求直接拒绝。它的底层思想和令牌桶类似按时间窗口做统计超出的请求会被快速拒绝而不会像排队那样把请求积压起来。我不推荐把tps当成常规限流手段因为它不够灵活比如结束后决定放开限流还是得改配置发版本。更常见的使用方式是针对某些冲高型接口临时打开tpsLimit比如运营活动开始的前 5 分钟先让流量小范围试探一下确认系统稳定后再放开。高流量贯穿始终时executes配合超时控制的组合更实用。如果只是启用tpsLimit而没有配置具体的tps数值它默认是不限的这一点要特别注意别以为加上过滤器就万事大吉了。3.3 快速失败不能少有限保护下的优雅降级服务端限流本质上是在做一个取舍是让请求排队慢慢处理还是快速拒绝保住系统。Dubbo 默认的方式是快速失败。线程池满了拒绝、executes超了拒绝、tps超了拒绝拒绝后消费者会收到异常。很多团队怕拒绝觉得拒绝就会造成用户体验变差。但我要说一句从业者的经验在 Dubbo 这样的 RPC 框架里快速失败永远比排队强。排队意味着请求堆积、超时、线程池膨胀最后谁也做不了事。快速失败让流量快速触达“熔断”状态消费者才能及时感知下游故障从而暂停调用或者走降级逻辑。降级长什么样比如用户下单接口被限流拒绝后前端提示“当前下单人数较多请稍后再试”同时后端将请求路由到 MQ异步处理。这比让用户卡在加载里面强太多。因此一旦选择了限流策略降级预案就要跟着一起设计否则所谓限流只是把拒绝异常暴露给用户而已。我想再补充一个容易被忽略的点executes和tps都是应用层的限流它们发生在请求已经经过网络层、线程池之后进入业务方法之前。这意味着即使限流生效了网络层和线程池的资源还是被占用了一小段时间。所以服务端限流不能完全替代连接数限制和线程池容量规划它们是配合关系不是替代关系。4. 消费者的自我保护超时、重试和并发控制4.1 重试可能是高并发下最大的流量放大器如果说服务端限流是防守那消费者端的参数调优就是进攻时不能乱来。先讲重试因为这是高并发场景下最容易被忽视、也最容易引发事故的元凶。Dubbo 默认的重试次数是 2也就是一次调用失败后会在其他节点上再尝试两次。框架这样设计的初衷是为了提高调用成功率但在高并发系统里重试意味着同一笔请求会被放大成 3 次 RPC 调用。如果上游还有网关网关自己也配置了重试那放大倍数就更可怕了。我遇到过的真实场景下游数据库出现慢查询单次调用耗时从 30ms 涨到 800ms消费者端配置的超时时间是 3 秒所以调用没超时只是变慢了。这时候消费者不会触发重试但并发量上来了线程池被慢慢占满。等到某个瞬间响应时间超过 3 秒消费者开始报超时重试逻辑启动原本 100 个请求的流量一下子变成 300 个下游本来就已经吃紧的服务彻底被打崩然后大量的重试请求积压在消费者端消费者自己也崩了。所以配置重试的第一原则是写接口非幂等操作一律 retries0。写一笔订单如果因为超时重试很可能会产生多笔订单这是业务事故不是技术事故。读接口可以保留一次重试但要确保下游真的具备快速失败的能力。我的做法是所有支付、下单、扣减库存类接口retries0查询类接口最多retries1同时配合超时时间一起调整。4.2 超时时间不是越长越好连接超时和响应超时的匹配超时时间设置很多人有一个误区生怕超时时间太短导致误伤于是喜欢设置成 10 秒甚至 30 秒。这个思路在低并发下问题不大但在高并发下非常致命。原因很简单Dubbo 的线程池数是有限的。一个消费者进程默认处理 RPC 响应的线程就那么多如果你把超时时间设置为 10 秒意味着一个慢请求会占用一个线程 10 秒。假设这个消费者每秒接收 100 个慢请求10 秒后就有 1000 个线程被占用线程池早就打满了后续所有请求全部排队。从线程经济学的角度看RPC 的超时时间应该控制在 1-3 秒之间。内部服务的正常响应时间在几十毫秒到几百毫秒之间超过 3 秒基本可以断定服务出大问题了这个时候尽快失败让流量走降级或者熔断比死等都更有意义。另外注意一个关键匹配关系消费者超时时间一定要比提供者超时时间略长。Dubbo 的提供者也有自己的超时控制如果消费者设置 2 秒超时提供者业务逻辑执行了 3 秒才超时抛出那消费者收到的不是业务结果而是超时异常。这种情况下消费者报的是 TimeoutException提供者那边其实还在继续执行就容易导致双方状态不一致。4.3 消费者actives从源头拦住并发洪峰除了超时和重试消费者端还有一个参数actives值得重视。它的作用是限制消费者对某个提供者地址URL的最大活跃调用数。举个例子某个消费者希望调用订单服务时同一时刻最多只有 30 个请求在途。一旦超过 30多余的请求会在消费者端排队或者直接异常退出。这相当于在消费者侧加了一个本地并发限制防止上游突然涌来大量请求时消费者把所有压力一次性砸向下游。我通常在两种场景下使用actives一种是消费者服务本身并发能力有限比如它是一个比较重的聚合服务一次要调多个下游另一种是下游服务比较脆弱希望通过消费者侧的限流来保护下游而不是等下游自己崩掉。这里要提醒一点actives是消费者端基于 JVM 内存统计的它影响的是单个消费者进程对目标服务的调用并发不是集群层面的全局并发。如果一个服务有 20 个消费者节点每个节点actives20那对下游来说实际可能会有 400 个并发调用。所以下游重要服务必须同时配好服务端限流不能只依赖消费者限流。5. 集群与配置中心联动用Nacos动态调整流量边界5.1 Nacos在流量控制中到底帮了什么忙前面的限流参数无论是executes还是tps配置之后都需要重启服务才能生效。问题就在这里线上发生告警的时候我们往往不知道流量极限在哪需要一个试错过程。如果每次调参都要发版重启从发现问题到调整完成半个小时已经过去了事故早就扩散了。Nacos 在这里扮演的角色是配置中心和注册中心。作为注册中心它负责维护服务地址列表消费者通过它找到提供者作为配置中心它可以把限流参数放到动态配置里修改配置后通过监听机制推送给应用应用不用重启就能更新限流阈值。业内比较多的做法是服务里写一个自定义 Dubbo Filter在这个 Filter 里读取 Nacos 配置动态决定是否放行请求。整体设计看起来是这样的在 Nacos 配置中心放置一个配置文件比如限流配置项limit.execute200服务启动时加载这个配置并注册一个配置监听器自定义 Filter 在每次调用进入时从监听器持有的变量里读取当前并发阈值运维人员只要在 Nacos 控制台修改limit.execute的值配置监听器更新内存变量限流阈值就动态生效了。很多团队以为只有引入 Sentinel 才能做动态限流其实原生 Dubbo 配合 Nacos 自定义 Filter 完全可以实现而且更轻量。5.2 一个可落地的动态限流Filter实现下面给出一段核心代码方便大家理解整个机制。首先要引入 Nacos 配置的依赖然后在 Filter 中持有动态配置值public class DynamicLimitFilter implements Filter, Filter.Listener { private volatile int maxConcurrent 200; public DynamicLimitFilter() { // 从 Nacos 读取配置并注册监听 NacosConfigService configService ...; String config configService.getConfig(order-service-limit.yml, DEFAULT_GROUP, 5000); parseAndUpdate(config); configService.addListener(order-service-limit.yml, DEFAULT_GROUP, new AbstractListener() { Override public void receiveConfigInfo(String configInfo) { parseAndUpdate(configInfo); } }); } private void parseAndUpdate(String config) { // yaml 解析后更新 maxConcurrent代码省略 } Override public Result invoke(Invoker? invoker, Invocation invocation) throws RpcException { if (RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName()).getActive() maxConcurrent) { throw new RpcException(RpcException.LIMIT_EXCEEDED_EXCEPTION, 超过动态并发上限: maxConcurrent); } return invoker.invoke(invocation); } }这段代码的核心思路是用RpcStatus.getActive()获取当前方法活跃请求数和动态阈值maxConcurrent比较超过就抛异常。设置volatile是为了保证在配置更新后所有线程能立刻看到新值。这就是一套完整的动态限流方案代码量不大却非常实用。要注意的是Filter 必须注册到 Dubbo 的 SPI 机制里并且在提供者的filter中加上自定义的 Filter 名称否则不会生效。这一步网上资料很零散我当年踩过坑最后是在resources/META-INF/dubbo/目录下建了 SPI 文件把 Filter 实现类注册进去才生效。5.3 权重与预热上线新节点时的流量斜坡控制Nacos 联动还有一个容易被忽略的场景新节点上线时的流量控制。Dubbo 的负载均衡策略默认是加权随机权重默认 100。如果你直接上线一个新节点它会被均匀地分配流量。但新节点的缓存是空的JVM 的 JIT 还没有预热连接池也没建好直接上流量可能会被打一个措手不及。更危险的是如果这个服务本身已经接近容量上限新增节点瞬间扛不住会导致整个集群的稳定性进一步恶化。正确的做法是把新节点的权重先设置为 0等它完全启动、完成预热之后再把权重从 0 慢慢调到 100。在 Nacos 上权重可以作为一个动态参数下发给提供者消费者端会感知到权重的变化从而调整流量分配比例。我习惯的做法是新节点上线前权重置 0启动 2-3 分钟后调成 30观察 5 分钟无异常再调成 100。这个过程中如果发现节点 CPU、内存、RT 有任何异常直接把权重切回 0流量就会被路由走节点可以随时下线排查。这个操作比“重启大法”稳妥得多。6. 网关层与集群入口的流量拦截6.1 为什么服务内部的限流还不够服务内部做了executes限流、消费者做了actives限流是不是就高枕无忧了不是。还有一个更前置的防线网关。很多团队用 Nginx 或者 API 网关作为流量的总入口。所有外部请求先经过网关再被分发到后端的 Dubbo 服务。网关天然适合做粗粒度的限流因为在这里过滤掉一部分流量就不会占用后端的任何资源。我见过一个团队外部流量一分钟的峰值是 10 万次请求但真正有效的业务请求只有 5 万次剩下的一半都是重复提交、恶意刷接口、健康检查探活请求。这些请求如果全部打到 Dubbo 服务上即使限流了也会占用连接和线程资源。网关层做一层限制把异常流量挡在外面内部服务才能专心处理真正的业务。网关限流怎么设计最简单的方案是 IP 维度限流同一个 IP 在单位时间内最多允许请求 N 次超过的返回 429。再细一点可以按 URL 维度做限流低频接口配一个低阈值高频接口配一个高阈值。更复杂的是结合用户 ID、设备 ID、会话 ID 做组合限流。内部服务靠executes保证的是“能干活”网关靠限流保证的是“没用的流量别进来”两者叠加防护效果才完整。6.2 大促场景的快速止血集群切流与摘除节点除了网关集群入口的流量拦截还有一个常见操作摘除节点。假设线上某个 Dubbo 提供者集群共 10 个节点其中 1 个节点因为硬件问题开始持续超时。此时如果不处理消费者调用到这个节点时都会经历一次超时超时结束后再重试到其他节点这个“碰运气”的过程会浪费大量时间影响整体响应时间。快速止血的方式是把这个节点从注册中心摘除让消费者不再路由到它。在 Nacos 上可以手动下线服务实例或者把它的权重调整为 0。摘除之后节点上的存量请求会继续处理但新请求不会进来然后再慢慢排查问题。这里有一个实践经验摘除节点后一定要关注消费者端是否还有“正在建立的连接”。如果消费者维护了长连接池摘除注册中心不一定能立刻断开已有连接需要在消费者端也配置快速感知机制比如注册中心变更监听或者缩短服务的check间隔。否则可能出现节点已下线但流量还在持续打到的情况。6.3 入口拦截和IM类高并发场景的适配这套流量控制思路同样适用于 IM 类的高并发交互场景。IM 服务的特征是长连接多、消息频率高、单条消息体积小它的瓶颈往往不在 Dubbo 接口的 TPS而在连接数管理。比如一个 IM 的推送服务消费者端要频繁调用提供者的消息发送接口如果提供者的accepts设置得很大成千上万的长连接会占满线程池最终导致消息延迟飙升。这种场景下我建议重点配置连接数上限和消费者actives同时把消息发送接口和状态查询接口拆分到不同的 Dubbo 分组用分组来隔离流量而不是靠一个接口扛所有流量。网关层同样可以针对 IM 请求做连接数限制和心跳频率限制防止客户端异常重连产生“连接风暴”。高并发 IM 的流量治理本质上还是连接数、并发数、超时时间这三个维度的组合控制只是参数取值需要根据消息频率重新压测调整。7. 一次真实压测与线上复盘参数怎么一步步调出来的7.1 压测数据把每个参数调到有据可依理论讲完用一次实际压测数据来说明这些参数怎么配合。假设有一个orderQuery查询接口目标支撑单机 2000 QPS平均 RT 要求控制在 80ms 以内。调用利特尔定律算一下2000 QPS × 0.08 秒 160 并发。考虑到 GC 和网络抖动我建议executes配置在 200 左右留下 25% 的余量。然后对线程池进行调整假设单机 CPU 是 8 核业务逻辑以 IO 为主线程池大小设置为 200 是合理的如果逻辑以 CPU 计算为主200 个线程反而会增加上下文切换此时应该降低到CPU核数 1左右。最后配合消费者端的timeout设置为 1 秒retries设置为 0。因为查询接口虽然幂等但如果不控住重试慢查询时照样会放大流量。压测时记录三组数据并发 100QPS 约 800RT 45ms线程池利用率 50%并发 150QPS 约 1300RT 55ms线程池利用率 75%并发 200QPS 约 1800RT 70ms线程池利用率 90%。可以看到当线程池利用率超过 75% 之后RT 开始明显上升。这意味着executes200是这台机器的安全上限一旦 QPS 超过 1800RT 和线程池占用率就会快速恶化。基于这个数据我给该接口定的最终参数是executes200如果流量持续增长到 2500 QPS就加节点而不是继续调高并发数。7.2 线上事故复盘一次典型的“重试超时”双杀再复盘一次线上事故把前面提到的知识点串起来。某个账户积分服务调用关系是网关 - 用户中心 - 积分服务。某天积分服务依赖的数据库出现了一条慢 SQL单次查询耗时从 30ms 飙升到 500ms。用户中心调用积分服务的timeout配的是 3 秒表面看没有超时但 500ms 的 RT 让用户中心的线程池开始堆积。很快用户中心的actives也达到了上限部分请求直接失败。这时候最可怕的事情发生了网关注入了重试逻辑失败请求被重新转发到用户中心用户中心自己对积分服务也有默认的 2 次重试。两次重试叠加原本 1000 的 QPS 直接变成 3000积分服务被打到executes上限大量请求被拒绝拒绝后继续触发重试形成了一个死循环。整个链路在 10 分钟内从“变慢”恶化成“不可用”。这次的教训有三个一是重试次数必须区分场景写接口和读接口要区别对待不能全部依赖 Dubbo 默认值二是消费者超时和提供者执行时间要匹配不能出现消费者还在等、提供者已经超时丢弃的情况三是服务端限流和消费端限流必须同时配置不能只堵一头放任另一头。7.3 调整后的最终配置参考经历这次事故后我们把核心链路的 Dubbo 配置整理成了一张参考表每次新服务上线前都必须对照检查。下面是一份典型的 Dubbo 高并发配置片段dubbo: application: name: order-service registry: address: nacos://127.0.0.1:8848 protocol: name: dubbo port: 20880 threads: 200 queues: 0 accepts: 1000 provider: executes: 200 filter: tpsLimit retries: 0 consumer: timeout: 3000 retries: 0 actives: 50注意这里把provider.retries也设置为 0是为了防止提供者端内部的异常重试放大流量。实际项目中provider.retries一般是给clusterfailover用的如果你用的不是 failover 集群策略这个参数建议保持默认或者显式设置为 0。提示所有参数没有绝对正确的答案只有经过压测验证的答案。每个服务的容量模型不同照抄配置是最不可取的。凡是经历过线上故障才会真正理解流量控制的价值这篇文章写到这里我脑海里还在回想那次凌晨两点的故障复盘会。当时大家围着监控大屏看着线程池占用率一条线地从 30% 冲到 100%所有人都很沉默。后来我们把重试次数归零、超时时间缩短、加上服务端并发限制系统才慢慢稳下来。那次之后我把 Dubbo 流量控制的几个核心参数做成了检查清单贴在了服务发布的流水线文档里每次新服务上线都要逐项过一遍。流量控制不是一个高深的算法问题它是一组朴素的工程决策哪些流量该放进来哪些该挡在外面挡在哪里挡住之后怎么降级。Dubbo 提供了足够多的原生参数配合 Nacos 的动态配置能力完全可以搭建一套灵活可靠的流量治理体系。关键是你得理解每个参数背后的压力模型而不是盲目堆参数。最后再分享一个小技巧把executes、actives、tps对应的实时 QPS、活跃线程数、拒绝次数全部接入监控大盘线上出现流量异常时你能很快定位是哪一个环节先失守的。流量控制做得好的团队通常不是靠运气躲过故障而是靠这些数据提前预判了故障。
Dubbo流量控制实战：从线程池到Nacos动态配置的高并发治理
Dubbo 流量控制这个问题我大概绕了三年才敢说摸到了点门道。高并发场景下系统通常并不是被真实流量打垮的而是被超时、重试、连接堆积这些连锁反应拖垮的。这篇文章从一个生产事故说起完整拆解 Dubbo 框架下服务端限流、消费端自我保护、Nacos 动态配置、网关前置拦截的一整套流量控制打法适合正在从“能跑”走向“扛得住”的团队参考。1. 高并发流量压力从哪里来先看清Dubbo的压力模型1.1 一次深夜事故流量没有想象中那么大先说一个我亲自经历过的事故。某个核心交易服务高峰期的 QPS 撑死也就 3000听起来不算高但那个晚上它硬生生把下游三个服务全部拖死最后把自己也拖死了。当时我们第一反应是“流量暴涨”可监控一看入口流量根本没涨多少。真正的问题出在调用链路上上游服务超时后不断重试重试的请求又打到另外一个服务上那个服务慢下来之后又引发更大面积的超时于是整个集群在半小时内陷入了“超时-重试-堆积-更慢”的循环。等我们反应过来线程池已经全被占满新请求全部排队连运维执行命令都开始卡顿。这个案例让我彻底明白了一个道理高并发场景下的 Dubbo 治理防的不是正常流量防的是异常流量引发的雪崩效应。正常流量再怎么涨只要容量规划合理无非是多加点机器但重试风暴和连接堆积一旦形成加机器都来不及因为每台新机器上线后会立刻被打满。所以做流量控制第一步不是急着调参数而是先把 Dubbo 的压力模型搞清楚请求从消费者发出经过注册中心找到提供者建立 TCP 连接进入提供者的线程池最后执行业务逻辑。这四个环节里面任何一个环节不做限制都会成为雪崩的起点。1.2 提供者和消费者视角的流量控制目标流量控制在 Dubbo 里其实分两个方向很多文章混在一起讲导致实操的时候不知道参数该配在谁那边。服务提供者关心的指标是我最多能同时处理多少个请求超过这个数量之后新来的请求应该立刻拒绝还是排队等待。这是典型的“自我保护”思路防止自己被大流量冲垮。对应的参数有executes、threads、accepts以及基于 TPS 的过滤器。服务消费者关心的是我最多能同时向某个提供者发起多少个调用如果对方已经慢了我不能无限地堆积请求。这是“上游保护”思路防止自己把下游拖垮。对应的参数有actives、timeout、retries。还有一个容易被忽略的维度是连接数。Dubbo 默认使用共享连接每个消费者和提供者之间维护一组 TCP 连接。很多人以为连接数越多吞吐越高实际上在高并发下连接数过多反而会导致内存占用飙升、线程上下文切换频繁性能未必成正比例增长。这就引出了下一节要讲的第一个关键点连接和线程池才是流量的第一道闸门。2. 最先要堵住的洞线程池、连接数与接受数设置原则2.1 Dubbo线程池模型默认值不一定适合你的业务Dubbo 的线程池模型说起来不复杂提供者启动一个固定的线程池默认是fixed大小是 200。每个请求占用一个线程执行业务逻辑任务队列默认是 0也就是SynchronousQueue线程不够用的时候直接拒绝。这个设计在早期是很实用的因为fixed线程池满了会快速失败不会像无界队列那样把请求都攒在内存里最终把 JVM 撑爆。问题在于200 这个默认值是拍脑袋拍出来的它不一定适合所有接口。我见过一个团队所有接口都走同一个线程池其中一个慢接口平均耗时 800ms另外几十个快接口平均只要 10ms。高峰期慢接口只要来上几十个请求线程池就被占了一半快接口全部开始排队。这种场景下线程池大小反而不是核心问题核心问题是慢接口拖累了整个进程。所以 Dubbo 提供了一些关键的线程池参数实际配置的时候务必搞清楚每一项的含义参数配置层默认值作用threads协议层200fixed线程池业务线程池大小决定最大并发处理能力queues协议层0线程池排队容量0表示不排队直接拒绝accepts协议层0每个提供者允许建立的最大TCP连接数0表示不限executes服务/方法层0同一方法最大并发执行数0表示不限actives消费者层0消费者端每URL最大活跃调用数0表示不限timeout消费者层1000ms一次RPC调用等待的最大时间retries消费者层2调用失败后的重试次数不含第一次实操中我的建议是threads不要拍脑袋设先通过压测找到单机能撑住的并发数再留 30%-50% 的余量。慢接口和快接口混在一起的服务优先考虑按线程池权重隔离或者直接把executes配到方法级别而不是一股脑全丢给同一个线程池。2.2 用利特尔定律把目标QPS换算成并发数很多人不知道executes到底该配多少我教大家一个最简单的换算方法——利特尔定律。它的公式是并发数 目标QPS × 平均响应时间。举个例子某个下单接口目标支撑 800 QPS压测得出平均响应时间是 45ms那么它需要的并发数是 800 × 0.045 36。也就是说这个接口的executes配 40 左右是合理的配 200 就太多了因为正常流量永远用不到 200 个并发反而给异常流量留下了巨大的吞噬空间。反过来算也很有用如果你的接口并发上限是 50平均响应时间 100ms那么理论上它能支撑的最大 QPS 是 50 ÷ 0.1 500。超过 500 QPS 之后请求就会开始排队、超时、报错。这个换算方法是我每次做容量评估必用的公式。配合executes使用你能把一个接口的流量上限提前算出来而不是等到线上被打爆了才猜。注意这个公式适用于理想情况实际还要考虑线程切换开销、GC停顿、网络波动所以建议把算出来的数值再打一个 0.8 的折扣留出安全边际。2.3 连接上限为什么不是越多越好accepts这个参数很多团队从来没配过。默认 0 表示不限连接数这在高并发下相当危险。Dubbo 的通信模型是长连接复用的消费者与提供者之间通过 Netty 维护连接。当服务规模大了比如一台提供者背后挂了 50 个消费者节点每个节点建立 20 条连接那这个提供者就要扛 1000 条连接。Netty 本身能扛住几千条连接但每条连接都有对应的内存缓冲区、心跳定时器等资源连接数上来之后GC 压力也会明显增大。我自己踩过的坑是某个提供者accepts没有限制结果消费者扩容之后建立了两千多条连接服务还没被流量打垮先被 Full GC 打垮了。后来在协议层配置了accepts: 1000超出的连接直接拒绝服务反而稳定了很多。不要盲目追求连接多连接够用就行通常一个消费者对同一个提供者维护 10-50 条连接就足够撑起很高的吞吐。还有一个细节要注意dubbo:protocol层还提供了threads和queues两个参数它们配合起来决定了请求进入线程池之后的排队行为。queues默认 0也就是SynchronousQueue线程池满了直接拒绝。如果你设置了一个很大的queues看起来请求不会立刻被拒绝但队列里积压的请求会占用大量内存而且等到队列里的请求真正被执行时消费者那边可能早就超时了。这种“伪排队”是非常坑的我建议queues保持默认 0不要随意调大。3. 服务端限流不让扛不住的请求进入业务逻辑3.1 方法级executes限流实战理解了线程池之后再来看服务端限流。Dubbo 原生最常用的限流方式就是executes它可以配置在服务级别也可以配置在方法级别。方法级别的配置方式XML 是这样的dubbo:service interfacecom.example.OrderService version1.0.0 dubbo:method namecreateOrder executes50/ dubbo:method namequeryOrder executes200/ /dubbo:service如果用的是注解和 YAML 配置思路类似重点是executes只对对应的method生效。这样做的好处非常明显快接口和慢接口彻底分开限流慢接口再怎么堵也不会占满整个服务的线程池。比如上面的createOrder只允许 50 个并发后面来的流量直接拒绝而queryOrder还能承受 200 个并发核心读链路还是通的。executes的生效机制是 Dubbo 内部维护了一个RpcStatus统计每次进入方法前会检查当前活跃请求数超过阈值就抛RpcException异常会被包装成调用失败返回给消费者。注意这个限流是基于JVM内存的只在当前提供者节点内生效。如果一个服务有 10 个节点每个节点executes50那么整个集群的实际并发承载量是 500不是 50。这也引出另一个决策点假如你的服务部署了 20 个节点你希望整个集群最多只接收 5000 并发那每个节点的executes应该是 250而不是 5000。做容量规划时一定要先想清楚“单机限流”还是“集群限流”。3.2 TPS限流与令牌桶思想的落地executes限制的是并发数但如果有些流量本身并发不高、却导致每秒请求数瞬间飙升比如秒杀抢购、限时活动这类场景还需要另一个维度的控制TPS 限流。Dubbo 内置了tpsLimit过滤器配置方式很简单。首先在提供者上启用过滤器dubbo:provider filtertpsLimit/然后给服务配置 TPS 上限dubbo:service interfacecom.example.OrderService dubbo:method namecreateOrder tps100/ /dubbo:servicetps的含义是每秒钟最多允许执行 100 次调用超过的请求直接拒绝。它的底层思想和令牌桶类似按时间窗口做统计超出的请求会被快速拒绝而不会像排队那样把请求积压起来。我不推荐把tps当成常规限流手段因为它不够灵活比如结束后决定放开限流还是得改配置发版本。更常见的使用方式是针对某些冲高型接口临时打开tpsLimit比如运营活动开始的前 5 分钟先让流量小范围试探一下确认系统稳定后再放开。高流量贯穿始终时executes配合超时控制的组合更实用。如果只是启用tpsLimit而没有配置具体的tps数值它默认是不限的这一点要特别注意别以为加上过滤器就万事大吉了。3.3 快速失败不能少有限保护下的优雅降级服务端限流本质上是在做一个取舍是让请求排队慢慢处理还是快速拒绝保住系统。Dubbo 默认的方式是快速失败。线程池满了拒绝、executes超了拒绝、tps超了拒绝拒绝后消费者会收到异常。很多团队怕拒绝觉得拒绝就会造成用户体验变差。但我要说一句从业者的经验在 Dubbo 这样的 RPC 框架里快速失败永远比排队强。排队意味着请求堆积、超时、线程池膨胀最后谁也做不了事。快速失败让流量快速触达“熔断”状态消费者才能及时感知下游故障从而暂停调用或者走降级逻辑。降级长什么样比如用户下单接口被限流拒绝后前端提示“当前下单人数较多请稍后再试”同时后端将请求路由到 MQ异步处理。这比让用户卡在加载里面强太多。因此一旦选择了限流策略降级预案就要跟着一起设计否则所谓限流只是把拒绝异常暴露给用户而已。我想再补充一个容易被忽略的点executes和tps都是应用层的限流它们发生在请求已经经过网络层、线程池之后进入业务方法之前。这意味着即使限流生效了网络层和线程池的资源还是被占用了一小段时间。所以服务端限流不能完全替代连接数限制和线程池容量规划它们是配合关系不是替代关系。4. 消费者的自我保护超时、重试和并发控制4.1 重试可能是高并发下最大的流量放大器如果说服务端限流是防守那消费者端的参数调优就是进攻时不能乱来。先讲重试因为这是高并发场景下最容易被忽视、也最容易引发事故的元凶。Dubbo 默认的重试次数是 2也就是一次调用失败后会在其他节点上再尝试两次。框架这样设计的初衷是为了提高调用成功率但在高并发系统里重试意味着同一笔请求会被放大成 3 次 RPC 调用。如果上游还有网关网关自己也配置了重试那放大倍数就更可怕了。我遇到过的真实场景下游数据库出现慢查询单次调用耗时从 30ms 涨到 800ms消费者端配置的超时时间是 3 秒所以调用没超时只是变慢了。这时候消费者不会触发重试但并发量上来了线程池被慢慢占满。等到某个瞬间响应时间超过 3 秒消费者开始报超时重试逻辑启动原本 100 个请求的流量一下子变成 300 个下游本来就已经吃紧的服务彻底被打崩然后大量的重试请求积压在消费者端消费者自己也崩了。所以配置重试的第一原则是写接口非幂等操作一律 retries0。写一笔订单如果因为超时重试很可能会产生多笔订单这是业务事故不是技术事故。读接口可以保留一次重试但要确保下游真的具备快速失败的能力。我的做法是所有支付、下单、扣减库存类接口retries0查询类接口最多retries1同时配合超时时间一起调整。4.2 超时时间不是越长越好连接超时和响应超时的匹配超时时间设置很多人有一个误区生怕超时时间太短导致误伤于是喜欢设置成 10 秒甚至 30 秒。这个思路在低并发下问题不大但在高并发下非常致命。原因很简单Dubbo 的线程池数是有限的。一个消费者进程默认处理 RPC 响应的线程就那么多如果你把超时时间设置为 10 秒意味着一个慢请求会占用一个线程 10 秒。假设这个消费者每秒接收 100 个慢请求10 秒后就有 1000 个线程被占用线程池早就打满了后续所有请求全部排队。从线程经济学的角度看RPC 的超时时间应该控制在 1-3 秒之间。内部服务的正常响应时间在几十毫秒到几百毫秒之间超过 3 秒基本可以断定服务出大问题了这个时候尽快失败让流量走降级或者熔断比死等都更有意义。另外注意一个关键匹配关系消费者超时时间一定要比提供者超时时间略长。Dubbo 的提供者也有自己的超时控制如果消费者设置 2 秒超时提供者业务逻辑执行了 3 秒才超时抛出那消费者收到的不是业务结果而是超时异常。这种情况下消费者报的是 TimeoutException提供者那边其实还在继续执行就容易导致双方状态不一致。4.3 消费者actives从源头拦住并发洪峰除了超时和重试消费者端还有一个参数actives值得重视。它的作用是限制消费者对某个提供者地址URL的最大活跃调用数。举个例子某个消费者希望调用订单服务时同一时刻最多只有 30 个请求在途。一旦超过 30多余的请求会在消费者端排队或者直接异常退出。这相当于在消费者侧加了一个本地并发限制防止上游突然涌来大量请求时消费者把所有压力一次性砸向下游。我通常在两种场景下使用actives一种是消费者服务本身并发能力有限比如它是一个比较重的聚合服务一次要调多个下游另一种是下游服务比较脆弱希望通过消费者侧的限流来保护下游而不是等下游自己崩掉。这里要提醒一点actives是消费者端基于 JVM 内存统计的它影响的是单个消费者进程对目标服务的调用并发不是集群层面的全局并发。如果一个服务有 20 个消费者节点每个节点actives20那对下游来说实际可能会有 400 个并发调用。所以下游重要服务必须同时配好服务端限流不能只依赖消费者限流。5. 集群与配置中心联动用Nacos动态调整流量边界5.1 Nacos在流量控制中到底帮了什么忙前面的限流参数无论是executes还是tps配置之后都需要重启服务才能生效。问题就在这里线上发生告警的时候我们往往不知道流量极限在哪需要一个试错过程。如果每次调参都要发版重启从发现问题到调整完成半个小时已经过去了事故早就扩散了。Nacos 在这里扮演的角色是配置中心和注册中心。作为注册中心它负责维护服务地址列表消费者通过它找到提供者作为配置中心它可以把限流参数放到动态配置里修改配置后通过监听机制推送给应用应用不用重启就能更新限流阈值。业内比较多的做法是服务里写一个自定义 Dubbo Filter在这个 Filter 里读取 Nacos 配置动态决定是否放行请求。整体设计看起来是这样的在 Nacos 配置中心放置一个配置文件比如限流配置项limit.execute200服务启动时加载这个配置并注册一个配置监听器自定义 Filter 在每次调用进入时从监听器持有的变量里读取当前并发阈值运维人员只要在 Nacos 控制台修改limit.execute的值配置监听器更新内存变量限流阈值就动态生效了。很多团队以为只有引入 Sentinel 才能做动态限流其实原生 Dubbo 配合 Nacos 自定义 Filter 完全可以实现而且更轻量。5.2 一个可落地的动态限流Filter实现下面给出一段核心代码方便大家理解整个机制。首先要引入 Nacos 配置的依赖然后在 Filter 中持有动态配置值public class DynamicLimitFilter implements Filter, Filter.Listener { private volatile int maxConcurrent 200; public DynamicLimitFilter() { // 从 Nacos 读取配置并注册监听 NacosConfigService configService ...; String config configService.getConfig(order-service-limit.yml, DEFAULT_GROUP, 5000); parseAndUpdate(config); configService.addListener(order-service-limit.yml, DEFAULT_GROUP, new AbstractListener() { Override public void receiveConfigInfo(String configInfo) { parseAndUpdate(configInfo); } }); } private void parseAndUpdate(String config) { // yaml 解析后更新 maxConcurrent代码省略 } Override public Result invoke(Invoker? invoker, Invocation invocation) throws RpcException { if (RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName()).getActive() maxConcurrent) { throw new RpcException(RpcException.LIMIT_EXCEEDED_EXCEPTION, 超过动态并发上限: maxConcurrent); } return invoker.invoke(invocation); } }这段代码的核心思路是用RpcStatus.getActive()获取当前方法活跃请求数和动态阈值maxConcurrent比较超过就抛异常。设置volatile是为了保证在配置更新后所有线程能立刻看到新值。这就是一套完整的动态限流方案代码量不大却非常实用。要注意的是Filter 必须注册到 Dubbo 的 SPI 机制里并且在提供者的filter中加上自定义的 Filter 名称否则不会生效。这一步网上资料很零散我当年踩过坑最后是在resources/META-INF/dubbo/目录下建了 SPI 文件把 Filter 实现类注册进去才生效。5.3 权重与预热上线新节点时的流量斜坡控制Nacos 联动还有一个容易被忽略的场景新节点上线时的流量控制。Dubbo 的负载均衡策略默认是加权随机权重默认 100。如果你直接上线一个新节点它会被均匀地分配流量。但新节点的缓存是空的JVM 的 JIT 还没有预热连接池也没建好直接上流量可能会被打一个措手不及。更危险的是如果这个服务本身已经接近容量上限新增节点瞬间扛不住会导致整个集群的稳定性进一步恶化。正确的做法是把新节点的权重先设置为 0等它完全启动、完成预热之后再把权重从 0 慢慢调到 100。在 Nacos 上权重可以作为一个动态参数下发给提供者消费者端会感知到权重的变化从而调整流量分配比例。我习惯的做法是新节点上线前权重置 0启动 2-3 分钟后调成 30观察 5 分钟无异常再调成 100。这个过程中如果发现节点 CPU、内存、RT 有任何异常直接把权重切回 0流量就会被路由走节点可以随时下线排查。这个操作比“重启大法”稳妥得多。6. 网关层与集群入口的流量拦截6.1 为什么服务内部的限流还不够服务内部做了executes限流、消费者做了actives限流是不是就高枕无忧了不是。还有一个更前置的防线网关。很多团队用 Nginx 或者 API 网关作为流量的总入口。所有外部请求先经过网关再被分发到后端的 Dubbo 服务。网关天然适合做粗粒度的限流因为在这里过滤掉一部分流量就不会占用后端的任何资源。我见过一个团队外部流量一分钟的峰值是 10 万次请求但真正有效的业务请求只有 5 万次剩下的一半都是重复提交、恶意刷接口、健康检查探活请求。这些请求如果全部打到 Dubbo 服务上即使限流了也会占用连接和线程资源。网关层做一层限制把异常流量挡在外面内部服务才能专心处理真正的业务。网关限流怎么设计最简单的方案是 IP 维度限流同一个 IP 在单位时间内最多允许请求 N 次超过的返回 429。再细一点可以按 URL 维度做限流低频接口配一个低阈值高频接口配一个高阈值。更复杂的是结合用户 ID、设备 ID、会话 ID 做组合限流。内部服务靠executes保证的是“能干活”网关靠限流保证的是“没用的流量别进来”两者叠加防护效果才完整。6.2 大促场景的快速止血集群切流与摘除节点除了网关集群入口的流量拦截还有一个常见操作摘除节点。假设线上某个 Dubbo 提供者集群共 10 个节点其中 1 个节点因为硬件问题开始持续超时。此时如果不处理消费者调用到这个节点时都会经历一次超时超时结束后再重试到其他节点这个“碰运气”的过程会浪费大量时间影响整体响应时间。快速止血的方式是把这个节点从注册中心摘除让消费者不再路由到它。在 Nacos 上可以手动下线服务实例或者把它的权重调整为 0。摘除之后节点上的存量请求会继续处理但新请求不会进来然后再慢慢排查问题。这里有一个实践经验摘除节点后一定要关注消费者端是否还有“正在建立的连接”。如果消费者维护了长连接池摘除注册中心不一定能立刻断开已有连接需要在消费者端也配置快速感知机制比如注册中心变更监听或者缩短服务的check间隔。否则可能出现节点已下线但流量还在持续打到的情况。6.3 入口拦截和IM类高并发场景的适配这套流量控制思路同样适用于 IM 类的高并发交互场景。IM 服务的特征是长连接多、消息频率高、单条消息体积小它的瓶颈往往不在 Dubbo 接口的 TPS而在连接数管理。比如一个 IM 的推送服务消费者端要频繁调用提供者的消息发送接口如果提供者的accepts设置得很大成千上万的长连接会占满线程池最终导致消息延迟飙升。这种场景下我建议重点配置连接数上限和消费者actives同时把消息发送接口和状态查询接口拆分到不同的 Dubbo 分组用分组来隔离流量而不是靠一个接口扛所有流量。网关层同样可以针对 IM 请求做连接数限制和心跳频率限制防止客户端异常重连产生“连接风暴”。高并发 IM 的流量治理本质上还是连接数、并发数、超时时间这三个维度的组合控制只是参数取值需要根据消息频率重新压测调整。7. 一次真实压测与线上复盘参数怎么一步步调出来的7.1 压测数据把每个参数调到有据可依理论讲完用一次实际压测数据来说明这些参数怎么配合。假设有一个orderQuery查询接口目标支撑单机 2000 QPS平均 RT 要求控制在 80ms 以内。调用利特尔定律算一下2000 QPS × 0.08 秒 160 并发。考虑到 GC 和网络抖动我建议executes配置在 200 左右留下 25% 的余量。然后对线程池进行调整假设单机 CPU 是 8 核业务逻辑以 IO 为主线程池大小设置为 200 是合理的如果逻辑以 CPU 计算为主200 个线程反而会增加上下文切换此时应该降低到CPU核数 1左右。最后配合消费者端的timeout设置为 1 秒retries设置为 0。因为查询接口虽然幂等但如果不控住重试慢查询时照样会放大流量。压测时记录三组数据并发 100QPS 约 800RT 45ms线程池利用率 50%并发 150QPS 约 1300RT 55ms线程池利用率 75%并发 200QPS 约 1800RT 70ms线程池利用率 90%。可以看到当线程池利用率超过 75% 之后RT 开始明显上升。这意味着executes200是这台机器的安全上限一旦 QPS 超过 1800RT 和线程池占用率就会快速恶化。基于这个数据我给该接口定的最终参数是executes200如果流量持续增长到 2500 QPS就加节点而不是继续调高并发数。7.2 线上事故复盘一次典型的“重试超时”双杀再复盘一次线上事故把前面提到的知识点串起来。某个账户积分服务调用关系是网关 - 用户中心 - 积分服务。某天积分服务依赖的数据库出现了一条慢 SQL单次查询耗时从 30ms 飙升到 500ms。用户中心调用积分服务的timeout配的是 3 秒表面看没有超时但 500ms 的 RT 让用户中心的线程池开始堆积。很快用户中心的actives也达到了上限部分请求直接失败。这时候最可怕的事情发生了网关注入了重试逻辑失败请求被重新转发到用户中心用户中心自己对积分服务也有默认的 2 次重试。两次重试叠加原本 1000 的 QPS 直接变成 3000积分服务被打到executes上限大量请求被拒绝拒绝后继续触发重试形成了一个死循环。整个链路在 10 分钟内从“变慢”恶化成“不可用”。这次的教训有三个一是重试次数必须区分场景写接口和读接口要区别对待不能全部依赖 Dubbo 默认值二是消费者超时和提供者执行时间要匹配不能出现消费者还在等、提供者已经超时丢弃的情况三是服务端限流和消费端限流必须同时配置不能只堵一头放任另一头。7.3 调整后的最终配置参考经历这次事故后我们把核心链路的 Dubbo 配置整理成了一张参考表每次新服务上线前都必须对照检查。下面是一份典型的 Dubbo 高并发配置片段dubbo: application: name: order-service registry: address: nacos://127.0.0.1:8848 protocol: name: dubbo port: 20880 threads: 200 queues: 0 accepts: 1000 provider: executes: 200 filter: tpsLimit retries: 0 consumer: timeout: 3000 retries: 0 actives: 50注意这里把provider.retries也设置为 0是为了防止提供者端内部的异常重试放大流量。实际项目中provider.retries一般是给clusterfailover用的如果你用的不是 failover 集群策略这个参数建议保持默认或者显式设置为 0。提示所有参数没有绝对正确的答案只有经过压测验证的答案。每个服务的容量模型不同照抄配置是最不可取的。凡是经历过线上故障才会真正理解流量控制的价值这篇文章写到这里我脑海里还在回想那次凌晨两点的故障复盘会。当时大家围着监控大屏看着线程池占用率一条线地从 30% 冲到 100%所有人都很沉默。后来我们把重试次数归零、超时时间缩短、加上服务端并发限制系统才慢慢稳下来。那次之后我把 Dubbo 流量控制的几个核心参数做成了检查清单贴在了服务发布的流水线文档里每次新服务上线都要逐项过一遍。流量控制不是一个高深的算法问题它是一组朴素的工程决策哪些流量该放进来哪些该挡在外面挡在哪里挡住之后怎么降级。Dubbo 提供了足够多的原生参数配合 Nacos 的动态配置能力完全可以搭建一套灵活可靠的流量治理体系。关键是你得理解每个参数背后的压力模型而不是盲目堆参数。最后再分享一个小技巧把executes、actives、tps对应的实时 QPS、活跃线程数、拒绝次数全部接入监控大盘线上出现流量异常时你能很快定位是哪一个环节先失守的。流量控制做得好的团队通常不是靠运气躲过故障而是靠这些数据提前预判了故障。
 】原型模式)
