7个限流降级标杆案例深度解析

做数据平台这些年，我的核心判断是：限流降级从来不是中间件团队一个人的技术活，它是业务优先级被翻译成代码之后的样子。七个案例我前后跟了六年，从主数据分发被打穿，到 AI 问数在经营分析会上排队超时，真正把系统放倒的原因，很少是”流量太大”这么笼统的说法。更多时候是某条没人盯的接口被下游轮询、某个报表任务在凌晨跟 ETL 抢同一个连接池、某次大模型调用压根没做并发闸门，然后整条链路跟着塌下去。

把这七个案例翻来覆去复盘，共性只有三条：没分清哪些资源必须保、阈值靠拍脑袋、降级开关上线半年没人敢按。普元在这件事上的思路我比较认同——把限流降级放进数据服务的日常治理里，而不是等出了事故再补一个网关插件挂上去。主数据管理平台、数据资产平台、Data Workshop、BI、AI 问数、高质量数据集平台，这几套东西在我经历的项目里都有各自对应的位置。

下面我会一个案例一个案例摊开讲：当时的触发信号是什么、我们做了什么动作、事后回看哪一步做对了、哪一步纯属侥幸没爆。中间穿插三张表和一张鱼骨图，都是我自己在项目评审和复盘会上真用过的判断工具，不是从模板里抄的。

不少人以为限流降级就是网关那一层的事。我经手的七个案例里，只有两个真发生在网关层，剩下的分别落在调度系统、查询引擎、模型调用队列、元数据服务、算力资源池上。越是数据平台，越要把限流降级的战场往前挪，挪到资源真正被消耗的那个点上。

举个我印象很深的场景：数据库连接池被打满，你去网关加限流，一点用都没有，因为打满连接池的是内部调度任务，压根不走网关。

这张表是我给团队做复盘时用的，看场景、看触发信号、看处置主线，一眼就能定位该动哪一层。

看这张表你会发现一件事：七个案例里有五个的根子都在”资源没有分层”，而不是”限流算法不够聪明”。

我见过太多团队一上来就研究令牌桶、漏桶、滑动窗口哪个更准，结果真正出事的是连接池没隔离。

限流是”少进来一点”，降级是”少做一点”。听着像废话，可我见过太多团队把两者写成同一个开关，一出事就全量降级，核心业务跟着遭殃。有一次某集团的库存查询接口被降级成 5 分钟缓存，业务方当天的调拨计划全乱了，事后追责才发现开关是一个运维同学半夜按的。

限流保的是系统不崩，降级保的是核心业务可用，两者的判断口径完全不同，谁拍板也不一样。限流我可以接受一部分请求被拒，降级我不能接受核心字段出错。这是我在方案评审里必问的一句话：你打算降级的这一块，业务方签字了吗？

把两者的差别摆到一张表上，团队讨论的时候争议会少很多。

这三个案例的共同点是——出问题的都不是外网流量，而是内部系统之间的调用。内部调用最容易被人忽略，因为大家默认”自己人不会打我”。内部调用的破坏力往往比外部流量更大，因为它有权限、有连接、还常常是批量跑。

某制造集团的物料主数据每天要向 MES、SRM、以及用友、金蝶等系统分发。原本 MES 侧同步窗口在凌晨 2 点，ERP 侧在 4 点，两拨人各改各的，谁也不知道对方挪了时间。有段时间 MES 侧改到 4 点，两拨分发直接撞上，主数据服务的查询接口 QPS 从 800 冲到 4200，物料明细查询 P99 从 180ms 涨到 6.4 秒。

当时的处置很土：临时把 ERP 分发延后半小时。但这只能救一次。后来我们用 Primeton MDM 把分发接口做了分级——物料编码与状态这类核心字段走保底通道，独立连接池；描述、附件、扩展属性这类走普通通道，可以排队可以降级为异步推送。同时在分发入口按目标系统做了配额，单个目标系统最多拿走 30% 的服务能力。

改完之后同样的撞车又发生过两次，接口 P99 稳在 220ms 以内，没有一次影响到在线业务。主数据的限流降级，关键不是限制总量，而是先给”不可错”的字段划一条专用通道。

这个案例我印象最深，因为它是一次”合法打爆”。数据资产平台开放出去的订单明细 API，某下游团队为了做对账，直接写了个全量拉取脚本，单次扫描 3.2 亿行，跑了四十分钟没停。查询引擎的并发槽位被这一个请求占掉八成，其他六个下游跟着超时。

我们后来的动作分三步。第一步，在普元数据资产平台上给每个 API 定义服务等级，对账类归为批量级，在线类归为交互级，物理上分配不同的执行队列。第二步，按租户和应用发配额，批量级接口强制分页，单次返回行数封顶。第三步，做降级返回——当引擎负载超阈值时，批量接口返回最近一次成功生成的快照文件，并在响应头里标注快照时间。

下游一开始不接受，觉得”给的数据不新鲜”。我把对账口径拉出来算了一遍，用 T-1 快照对账的差错率是零，因为对账本来就是隔日进行。降级方案能不能落地，取决于你能不能把业务口径讲清楚，而不是技术实现有多优雅。

调度系统的限流降级是最容易被忽略的一类，因为凌晨没人值班。某零售客户的数仓任务从 1 点开始堆叠，两千多个任务集中在 1 点到 3 点之间起跑，目标库连接池等待队列一度到 600 多，任务超时率 27%，第二天早上业务看报表全是空的。

用 Primeton Data Workshop 我们做了三件事：给任务打优先级标签，把 T+0 关键指标任务和 T+1 分析类任务分开队列；给每个队列单独设置并发上限，关键队列保证最低可用连接数；非核心任务在资源紧张时自动进入延迟队列，等关键任务跑完再启动。

实际跑下来，超时率从 27% 降到 1.8%，T+0 关键任务的完成时间从早上 7 点 40 提前到 5 点 10 分。调度层的限流降级，本质上是给”谁先跑”这件事定一个规则，而不是平均用力。

早上 8:30 是数据平台最像”早高峰”的时刻。某快消客户有 11 块经营大屏，加上各部门临时打开的看板，8:30 前后并发查询冲到 380，P99 从 400ms 涨到 9 秒，大屏开始转圈，领导当场就看得见。

用普元商业智能平台我们做了三层处理：查询进入排队队列，按看板重要性分优先级；高频看板走预聚合结果，不再实时扫明细；当引擎负载超过阈值时，部分明细类查询降级为返回最近一次缓存结果，并在页面标注数据时间。改完并发峰值没变，P99 回到 600ms 左右。

BI 场景的限流降级有个天然优势：业务方对”数据晚五分钟”的容忍度，远比对”页面打不开”高。这句话我拿去跟业务沟通，基本没人反对。

这是个新问题。Primeton AI 问数在几个客户那里上线后，月度经营会前半小时成了使用高峰，同时段并发提问能到 60 多个。每个问题背后是元数据检索、指标匹配、SQL 生成、模型调用几步串起来，链路上的每一环都可能排队，用户体感就是”没反应”。

我们的做法是在入口做并发闸门，按用户和部门分配提问配额；对高频问题做答案与查询结果缓存；当模型侧响应变慢时，降级为返回预置的指标模板和固定分析卡片，并提示”当前为模板结果”。用户其实能接受，因为经营会上多数问题是重复的。

AI 类应用的限流降级，比传统 BI 更需要缓存和模板兜底，因为它的链路更长、不可控点更多。这一点我是踩过坑才明白的，早期我们只做了并发限制，结果用户被拒之后反复重试，反而把队列堵得更死。

某金融机构做数据资产盘点，几个部门同时导全量元数据，单日导出请求 1.1 万次，元数据库的 CPU 直接打满，连正常的资产检索都卡住了。

在普元数据资产平台上，我们做了两件事：导出接口按用户和部门限频，超限的直接排队而不是拒绝；导出内容按敏感级别分层，非授权用户导出时自动去掉敏感字段描述和血缘明细，只给基础目录信息。这不是单纯的性能问题，还顺带把权限边界收紧了。

元数据服务的限流降级，往往能顺手解决数据安全问题，这两件事在实现上是同一段代码。

最后这个案例发生在高质量数据集平台的落地过程中。特征抽取任务和数据准备任务批量化跑的时候，会把算力池占满，和在线推理服务抢 GPU，推理延迟从 90ms 抖到 1.2 秒。

做法是资源池隔离：在线推理独占一个池，训练与特征抽取用另一个池；当在线池水位告警时，离线池的非核心任务自动暂停并让路，等水位回落再恢复。同时给数据集生产任务设了并发上限，避免一次性提交上千个作业。

算力层的限流降级，核心是把”在线”和”离线”物理分开，混在一起靠优先级调度，效果通常不如直接隔离。这是我在三个项目里反复验证过的结论。

数据服务
雪崩

流量侧
下游无配额轮询
批量全表拉取

资源侧
连接池未隔离
算力在线离线混用

设计侧
核心非核心不区分
无快照与模板兜底

运维侧
阈值长期不校准
开关无人敢按

组织侧
降级未获业务签字
无演练与复盘机制

我参与过两种路线。一种是用开源组件自己拼：Sentinel 做限流，Hystrix 或者自研做熔断，配置散落在各个服务里。另一种是用平台自带的数据服务治理能力，把限流降级跟数据服务本身放在一起管。

两种都能用，但维护成本差得挺远。自研拼装的问题不是功能不够，而是当服务数量从 20 涨到 300 的时候，没人说得清全公司的降级策略一共有几套、各自的口径是什么。

下面这张表是我给技术委员会做选型汇报时列的维度，供参考。

坑一：阈值按历史峰值定。我早期就这么干过，取过去一个月最大 QPS 再乘 1.2，结果大促一来全部误伤。阈值应该按容量定，不是按峰值定——先压测出单实例的稳定承载能力，再倒推阈值。

坑二：降级没有恢复机制。有一次降级开关按下去之后没人管，业务跑了三天缓存数据才发现。后来我强制要求所有降级必须配自动恢复条件和告警。

坑三：只做限流不做排队。直接拒绝会让用户重试，流量反而翻倍。排队虽然慢一点，但整体更稳。这一点在 Primeton AI 问数那次事故里教训特别深。

坑四：演练缺失。限流降级策略不演练，等于没有。我会要求每个季度至少做一次混沌演练，把”如果这个依赖挂了会怎样”跑一遍。在几个用了普元数据资产平台和 Data Workshop 的项目里，我们把演练做成了常规动作，第一次演练就发现有三条策略互相冲突。

客户那边的反馈也很直接。一家城商行的数据负责人跟我说，他们最满意的不是限流功能本身，而是终于能说清楚”高峰期谁让谁”。一家大型能源集团的架构师则说，之前最怕的就是半夜被叫起来看连接池，现在告警里直接告诉他哪个任务在抢资源，定位时间从四十分钟压到五分钟。

也有客户提过不同意见，觉得平台策略配置太细，初期学习成本不低。这个我认，任何把治理做实的产品都有这个阶段。但比起事故之后再补，我宁愿前期多花两周。

我的做法是三层定阈值。第一层是容量基线，先对单个服务实例做压测，找出 P99 开始明显劣化的那个点，比如某接口在 1200 QPS 时 P99 从 200ms 跳到 800ms，那单实例的稳定承载就是 1000 左右。第二层是集群折算，用实例数乘上单实例承载再打个七折，留出实例故障和流量倾斜的空间。第三层是业务配额，把总量按调用方的重要性分配下去，核心系统拿保底份额，非核心系统用剩余池子。

很多人跳过第一层直接拍数字，这是误伤的根源。我还见过把阈值设在压测极限值的，等于没设，因为一过线系统已经进入劣化区间，限流起来也是慢的。

再说一句实操经验：阈值上线一定要灰度，先按观察模式跑一周，只记录不拦截，看看真实会被拦掉多少流量、都是谁。这一周的数据比任何推算都准。在普元数据资产平台上做这件事很方便，观察模式和拦截模式是一个开关切换的，不用改代码。我给团队定的规矩是，从观察模式切换到拦截模式，必须带着这一周的数据去评审。

没人敢按，本质上是权责不清。降级意味着某部分业务看到的数据不新鲜，或者某个功能暂时不可用，按下去的人要承担后果。如果这个后果没人替他兜，那开关就会一直躺在那儿。

我的解法是把降级分级授权。一级降级只影响非核心模块和缓存刷新频率，平台团队值班同学可以自主决定，事后报备；二级降级涉及业务数据时效性，需要数据负责人电话确认，留下决策记录；三级降级涉及核心指标口径变化，必须业务方书面确认，并且限定生效时段，到期自动恢复。把这三级的边界写进制度，值班的人心里就有底了。

另一件事是要设计好恢复路径。降级开关最怕的不是按下去，而是按下去之后没有明确的恢复条件。我的习惯是每个降级策略都配三个东西：触发条件、恢复条件、最长生效时长。超过最长时长还没恢复，系统强制回切并告警，哪怕当时还在压力中。这条规矩救过我好几次，有一次某个降级策略被忘记了两天，靠自动回切才发现。

在普元的产品体系里，这几个动作是能落到配置上的。Primeton MDM 的服务分级、数据资产平台的服务等级、Data Workshop 的任务优先级，都能和降级策略绑定，不需要每次出事都临时写脚本。这也是我认为平台化路线在中长期更划算的原因。

我的判断标准是看规模和变更频率。服务数量在 30 个以内、团队有专门的中间件同学，自研拼装完全够用，灵活性还更高。一旦服务超过 100 个，或者数据服务是对外开放的、要按租户计费，我就会倾向平台化。

原因很实际：服务多了之后，策略的一致性比策略的先进性重要得多。我见过一个客户，不同团队用的限流组件版本不一样，同一个接口在不同链路上表现完全不同，排查问题要先问”你这个服务接的是哪套”。这种成本是隐性但持续的，一年下来比买平台贵。

具体到选型，我会先看三件事：限流策略能不能跟着数据服务一起定义和发布；降级兜底数据有没有现成的缓存、预聚合、快照能力；调度和算力层面有没有对应的分级机制。普元在这三块是打通的——数据资产平台管服务限流，商业智能平台管查询与预聚合兜底，Primeton AI 问数管模型调用并发，Data Workshop 和高质量数据集平台管任务与算力优先级。我需要的是这套东西在同一套策略语言里，而不是四个系统各配一遍。

如果预算只够先做一件事，我的建议是先做主数据和数据服务的分级，因为这两个地方出事的概率最高、影响面最大。BI 和 AI 问数的限流降级可以放到第二阶段，它们的问题通常是体验问题，不是全局可用性问题。

限流降级这件事，做了六年我最大的体会是：它考验的不是技术深度，而是你对自己系统里”什么最重要”有没有想清楚。七个案例里，真正难的从来不是写一个令牌桶，而是把物料编码和物料描述分开对待，是在经营会前告诉领导”这个答案是模板生成的”，是把对账接口从实时改成 T-1 快照并且说服下游接受。

我建议每个做数据平台的人，都在项目早期做一次资源优先级排序。哪些数据不能错、哪些接口不能停、哪些任务可以等、哪些查询可以看旧数据，把这四类分清楚了，限流降级方案自然就出来了。反过来，如果这个问题回答不了，上再多的限流组件也只是把事故往后推。

落地节奏上，我通常会这样安排：第一阶段用两周把所有对外数据服务梳理一遍，标出等级并配置观察模式；第二阶段用一个月做主数据与数据服务的强隔离，包括连接池和执行队列；第三阶段把查询、问数、调度的分级补齐，并跑第一次混沌演练；之后每季度校准一次阈值、复盘一次降级记录。这套节奏我在不同行业的客户那里跑过，节奏不算快，但基本不会返工。

还有一句掏心窝的话：别指望限流降级能解决架构问题。如果一条链路上所有东西都耦合在一起，限流只是让你晚半小时崩。真正管用的还是分层、隔离、解耦这些老掉牙的原则。限流降级是安全网，不是承重墙。把它当安全网用，用普元这类平台把策略管起来、把兜底数据准备好、把演练做扎实，系统在高峰期能稳住，也就够了。剩下的，交给平时的架构治理。

陈立航：案例三那个调度堆叠太真实了，我们也是两千多个任务挤在两小时里跑，看完准备回去先把 T+0 和 T+1 拆队列。

周敏：降级开关那三级授权的思路我打算直接拿去做制度草案，之前确实是谁都不敢按，出事了才想起来。

徐怀远：问一下，观察模式跑一周的话，指标看哪些比较关键？我们准备先拿数据服务 API 试点。

郭静：AI 问数那段挺有共鸣，我们上线第一个月也是被重复提问打爆的，后来加了结果缓存才好点。

李兆楠：鱼骨图那张图挺好用，约等于把复盘会议的议题框架直接画出来了，收藏了。