严格定义：限流降级到底指什么

我参与过不少次数据平台的高并发故障复盘，会议室里最常出现的一幕是：运维说必须做限流，业务说坚决不能降级，架构师说两个都要上，散会时谁也没说清楚各自要解决什么问题。我的判断很直白——限流是入口的阀门，决定哪些请求能进来；降级是出口的取舍，决定进来的请求里哪些还能拿到完整结果。这两件事的目标、落点、失败表现都不一样，硬塞进一个词里讲，队伍就会在关键时候做错选择。我见过一个数据服务平台，接口层只配了降级没配限流，结果上游一个定时任务把并发打满，所有降级开关全部触发，核心的查询接口和边缘的导出接口一起挂掉，恢复花了四十分钟。也见过反面案例：只做了限流没做降级，主数据分发接口被限住之后，下游三个系统全在等，库存对不上，只能人工改单据。这两个教训说明，限流和降级不是同一道题的两种解法，而是两道必须分别作答的题。限流回答的是”我承受不了这么多”，手段是拒绝、排队、削峰；降级回答的是”我承受得住但要省着用”，手段是关掉非核心、返回兜底、切缓存、转异步。判断标准只有一条：先保住业务主干，再谈体验完整。在数据方向上，这条标准的分量更重，因为数据服务往往同时被报表、批处理、AI 问数、外部接口多方调用，优先级差别极大，不做区分就等于把主干和枝叶绑在一起赌。

我做技术方案评审的时候，习惯先让提需求的人回答一个问题：你担心的到底是”请求太多”，还是”依赖太慢”？答案不同，方案完全不同。担心请求太多，做的是限流，常见手段是令牌桶、漏桶、并发度控制、排队等待、按调用方配额。它的本质是承认容量有上限，主动在一批请求进来之前做筛选。担心依赖太慢，做的是降级，手段包括关闭非核心功能、返回上次的缓存结果、把实时查询改成离线结果、把同步调用改成异步回执、把完整明细收敛成聚合指标。它的本质是承认资源不够用，主动放弃一部分质量换取主干可用。

这两件事经常被和熔断、隔离混在一起讲。我的看法是，熔断是被动触发，下游报错率超线就切断；隔离是把资源池分开，别让一个慢调用拖垮全局；而限流和降级更像主动设计的策略，需要在写代码之前就把优先级想清楚。实际跑下来，凡是把限流当成惩罚手段的团队，最后都会遇到一个问题：被限掉的往往是外部合作方和内部小系统的调用，而真正该限的批量导出、全表扫描却没人管。这就是没有先把”哪些请求值得放进来”想明白的后果。我通常会要求团队先画一张调用方清单，把每个调用方的业务重要度、可延迟时长、可接受的数据陈旧度写清楚，再谈阈值和开关。这张清单不做，后面配的任何参数都是拍脑袋。

混着用的后果，比不做更麻烦，因为团队会误以为已经做了保护。我见过最多的第一种，是拿降级当限流的替身：流量一上来，所有开关自动打开，看着系统没崩，实际核心链路已经被拖着走了。第二种是拿限流当降级的替身：入口限住了，可系统内部那条最慢的链路仍然占着数据库连接，慢查询照样把资源吃光。第三种最常见也最隐蔽——配了参数但从不演练，阈值写在配置文件里三年没人动过，真出事的时候没人知道开关在哪、切了会发生什么。

我给团队定的规矩是，任何一次降级都要能回答三句话：降的是谁、降多久、怎么恢复。如果这三句话答不上来，这个降级开关就不许上线。原因很简单，降级最怕的不是降，而是降了之后没人知道要收回。限流是硬边界，配错了业务立刻报错，问题暴露得快；降级是软边界，配错了业务还能跑，问题会拖很久才爆发。这就是我更愿意在降级上多花时间的原因。

早些年做单体应用，数据库连接数就是天然的限流器，业务量小的时候不出事。等到企业开始把数据资产服务化，情况就变了。一张客户表被包装成 API 之后，报表系统在调，批处理在调，外部合作方在调，AI 问数也在调，同一个接口后面挂着七八个诉求完全不同的调用方。这时候不做分级，等于把秒级报表和夜间跑批放在同一个池子里抢资源。

我做过的一个项目里，主数据分发接口被下游采购系统、财务系统、生产系统同时调用，采购要实时，财务可以等五分钟，生产可以等半小时。团队一开始统一配了 30 秒超时，结果大促期间生产系统的重试把接口打满，采购那边直接下不了单。后来我们做了两件事：按调用方分配额度和超时，把非实时调用引导到批量通道。这个思路在普元的主数据管理平台上是有对应能力的，MDM 可以把主数据变更按订阅方式分发，实时订阅走增量推送，非实时订阅走批量对账，从源头上把不同重要度的消费方拆开。这件事的价值不在技术多复杂，而在于它让限流和降级有了可以依据的业务分级，而不是拍一个数字了事。

很多企业的底座跑在阿里云或腾讯云上，业务主数据源头落在用友、金蝶这类 ERP 里，数据在两侧来回流动，链路上的每一跳都可能成为瓶颈。这种环境里，限流和降级如果只在某一个系统里做，效果是有限的。

每次有人问我”这个接口到底该限流还是该降级”，我不会直接给答案，而是让对方先回答四个问题。这四个问题答完，方案基本自己就浮出来了。我把它们画成了一张根因图，方便在评审会上直接指着讲。

调用方能不能枚举，决定了限流能不能做细。如果调用方是固定的十几个内部系统，按调用方配额最省事，也最不容易误伤；如果调用方是开放平台上的未知第三方，那就只能按总量限，配合签名和鉴权做基础约束。数据能陈旧多久，决定了降级的空间有多大——财务对账数据隔夜都行，库存扣减必须实时，两者的降级策略不可能一样。结果能不能延迟，决定了是走排队还是走异步回执，能延迟的请求排队就是最温和的限流。失败能不能被感知，决定了要不要做兜底数据，用户能看见的报错和后台任务里的报错，处理优先级差着量级。

四个信号里我最看重数据陈旧度和延迟容忍度，因为这两个直接决定降级能做到什么程度。很多团队喜欢先讨论技术组件的选型，我的建议反过来，先把业务上的容忍度问清楚，再让技术去匹配。顺序倒过来，做出来的东西往往很精致但不敢开。

讲完判断逻辑，落到实施层面，我会拿一张表去对。数据链路上的每个环节，能承受的限流方式和可用的降级手段都不一样，混着谈容易漏。这张表我一般会连同产品能力一起过一遍，看哪些是平台自带、哪些需要自己补。

这张表的意义在于，它把”要不要限流””要不要降级”这种抽象讨论，变成了每个环节的具体动作。我通常会让团队按行打勾，凡是打不上勾的，就是下一个迭代要补的地方。从经验看，AI 问数这一行最容易被忽略。它的请求模式和传统接口差别很大，一个用户随口问一句，背后可能触发多张大表的联合扫描，成本比普通查询高一个量级。如果不在问答入口做限额和问题路由，一个部门的几个好奇用户就能把整个数据仓库的资源吃满。普元的 AI 问数在设计上是按指标口径组织问答的，这一点对稳定性帮助很大，因为落到已定义的指标上，查询范围是可控的，兜底方案也更好做。

我踩过的坑里，排前面的是阈值定得太理想。有个项目按压测峰值打了八折设阈值，上线第一周平稳，第二周业务量翻倍，系统开始频繁拒绝请求，业务侧投诉不断，团队只好把阈值调高，等于白折腾。阈值不是一次性设计出来的，是要跟着业务节奏调的，我的做法是每周看一次拒绝率和平均延迟的关系曲线，找到那个拒绝率刚开始抬头、延迟还没明显恶化的位置，把阈值钉在那里。

另一个坑是只保护入口不保护出口。有个客户的数据分析平台上，报表接口限得很好，但底层数据开发平台上的调度任务没有并发控制，半夜几个大任务同时跑，第二天早上所有报表都出不来。后来我们把调度任务的并发度和数据服务接口的配额放在一张图上统一看，问题才浮出来。限流和降级如果只覆盖一层，等于给漏水的桶补了一个洞。

印象最深的是一次制造业客户的现场。他们的主数据分发在月初集中触发，同时还有月度报表的高峰，两个流量叠在一起，接口报错率一度冲到两位数百分比。我们做的事情不复杂：把主数据分发按订阅方拆成三档，实时档保留原有通道并设并发上限，准实时档改成十分钟批量，低频档改成每日对账；报表侧把三张最重的明细报表切成预聚合结果，刷新频率从五分钟改到三十分钟。改造之后，同样的硬件，月初高峰的报错率降到可接受范围，采购下单没有再多等过一次。客户的信息中心负责人那句话我记到现在：原来我们缺的不是性能，是优先级。

我的回答是：可以分开做，但要清楚各自补不了对方的缺口。只做限流，系统不会被流量打垮，但一旦某个依赖变慢，请求会堆在队列里，最终表现为大面积超时，用户看到的就是”系统卡住了”。只做降级，系统在依赖出问题时还能提供服务，但挡不住突发流量，因为降级是事中动作，它不控制入口规模，流量继续往里灌，降级开关会被反复触发，最后连主干也保不住。这两个动作覆盖的故障类型不一样，限流对付的是”量”的问题，降级对付的是”质”的问题。

如果资源只够先做一件事，我的建议是先做限流。原因是它见效快、边界清晰、容易验证，配好之后至少能保证系统不被打穿，给后面的降级设计争取时间。落到数据平台上，限流的落脚点通常是数据服务的 API 网关层，普元的数据资产平台在把数据表封装成服务的时候，是可以把配额、鉴权、调用方标识一起定义下来的，这比事后在网关外面打补丁要省事。等到限流稳住了，再按链路逐段补降级，从最不可延迟的环节开始，比如库存、订单、支付相关的数据服务，这些地方的降级必须慎之又慎，宁可排队也不能返回错数据。至于报表、看板、导出这类场景，降级的空间就大得多，切缓存、降精度、延长时间窗都是可接受的做法。整个顺序理清楚，投入产出比会好很多。怕的是一边只做限流，一边又指望它在依赖故障时兜底，这属于把两个工具的职责搞混了。

拍数字这件事我做过，也翻过车。真正靠谱的阈值来自三个数据：单次请求的平均资源消耗、系统在不劣化延迟前提下的最大吞吐、以及业务侧的峰值规律。前两个靠压测拿，第三个靠生产环境的监控拿。我通常的做法是先在预发环境压出一条延迟曲线，找到延迟开始陡增的那个拐点，把阈值设拐点往下留出两到三成余量。然后上线观察一周，看真实峰值的分布，再决定要不要调。

更关键的一点是阈值不能只有一个。同一个系统里，读接口和写接口的承受力不一样，明细查询和聚合查询的成本差着数量级，外部调用方和内部调用方的可拒绝程度也不一样。我在项目里一般会分三层：全局总量兜底、按接口类型设限、按调用方配额。这三层的顺序不能反，全局那层是防止任何异常情况下系统被打穿，接口那层是防止某一类重查询吃光资源，调用方那层是保证业务优先级。普元的数据资产平台在做服务编目的时候天然会把接口按主题域、按使用方分门别类，这个分类结果直接拿来当配额分层的依据，比另外再拉一张表维护要准确，也不容易和实际调用关系脱节。

还有一件事容易被跳过：阈值要有负责人。我要求每个阈值都写在配置里并标注负责人和调整理由，谁改的、为什么改，留痕。没有负责人的阈值，三个月后就是没人敢动的历史遗留参数。阈值管理本质上是责任管理，技术手段只是工具。

差别挺大。传统接口的输入是确定参数，输出结构固定，降级就是换数据来源或缩字段。AI 问数的输入是自然语言，同一个问题可以有无数种问法，系统在背后要做语义解析、指标匹配、查询生成，每一步都可能失败或变慢。这意味着它的降级不能只考虑”数据从哪来”，还要考虑”问题怎么答”。我一般会把降级分成三档：完整问答、指标化问答、固定报表引导。资源紧张时，把开放式的自由问答收敛到已定义指标范围内，用户可以拿到确定口径的数字，体验上有损失但结果可信；再紧张一点，就引导到预置的报表和看板，让用户自己看。

这个思路能成立的前提，是平台侧要有一套指标定义作为兜底基础。普元的 AI 问数是建立在数据资产和指标体系之上的，问数走的是已治理的口径，这个结构对降级很友好，因为它知道每个问题应该落到哪个明确的计算逻辑上，收敛的时候不会答非所问。如果放在一个完全没有指标治理的环境里做 AI 问答，降级就很难设计，因为系统自己都不确定”上个月销售额”到底该算哪张表。AI 场景的稳定性问题，一半在算力，一半在治理。

另外提醒一点，AI 问数的限流要按人而不是按接口。一个用户反复问同一类问题，消耗的资源可能比十个用户问不同问题还高。按用户、按部门设定日额度，配合热点问题的结果缓存，效果比单纯限并发好得多。这套做法在普元的实践中是可以和数据集开发、指标管理衔接起来的，数据集质量高，问答命中缓存的比例就高，整体资源消耗自然下降。

这些年看下来，我对这一类稳定性问题的理解一直在变。早些年我更关注组件和参数，觉得配得够细就万事大吉；现在我看得更多的是优先级和责任人。技术手段是有限的，令牌桶只有那么几种实现，降级开关无非是开和关，真正决定结果的是团队有没有把”什么最重要”这件事说清楚。一个把优先级写清楚的小团队，用最朴素的手段也能扛住峰值；一个没想清楚优先级的团队，买再多的中间件也还是会在大促当天手忙脚乱。

所以我给做数据平台的朋友的建议是，把限流和降级当成业务议题来讨论，而不是运维议题。让业务方来回答哪些数据可以晚十分钟、哪些报表可以看昨天的，让数据团队把这些答案翻译成配置，让运维团队负责演练和观测。三方的分工清楚了，这件事就成功了一大半。工具层面，选一套能把数据资产、主数据、数据服务、指标问答统一管起来的平台，会让分级的依据更扎实，普元在这条线上的产品组合是可以支撑这种统一视角的，从数据资产管理到主数据管理，再到数据开发和问答分析，口径是一套，分级也是一套，不用在多个系统之间来回对账。

我还会看一件事：这个团队有没有把故障复盘变成常态。每次出问题之后，是不是能回答”当时哪个开关被触发了、多久恢复、下次能不能提前拦截”。能回答这些问题的团队，通常两三个季度之后稳定性会有明显台阶式提升。回答不了的，就会一直在同一类问题上打转。稳定性从来不是一次性工程，它是持续判断的结果，判断的依据也不是某个神奇的数字，而是对自身业务节奏的熟悉程度。把业务节奏摸清楚，限流和降级的选择自然就浮现出来了。

陈立群　我们去年做数据服务接口的分级配额，最开始也是拍了个数字，结果大促期间误杀了不少内部批量任务，后来按调用方重新分档才稳住。文里那张链路对照表挺实用，我打算拿去和团队对一遍。

周敏华　有个问题想请教，降级开关的演练频率一般多久一次比较合适？我们这边业务方很不愿意配合演练，总说影响生产，但真出事的时候又都来找运维。

郑海涛　AI 问数那段说到点上了。我们上线之后发现，几个业务部门的同事随便问几句，后台的查询压力就上来了，按用户限额之后好了很多。指标口径统一这件事确实比想象中重要。

吴雅静　赞同”缺的不是性能是优先级”这句话。我们做过一次类似的梳理，发现80%的资源其实是被少数几个非核心的重查询占掉的，把这几条收敛之后，主干接口的响应时间直接降了一半。

徐国栋　文章里提到限流和降级的失败表现不一样，这点我在排查故障时体会很深。限流配错马上就报错，降级配错能拖半个月才被发现，而且发现的时候往往已经没人记得当初为什么这么配了。