LLM网关

一、核心判断：限流与降级，保命逻辑先于工具选型我见过不少团队一上来就问用什么网关、开多少线程、QPS 卡到多少，我通常会先把问题拽回来：限流和降级不是同一层的事，限流是入口闸门，降级是故障时的业务取舍。限流，按我的经验，是在请求还没把系统打穿之前，用配额、并发数、队列、令牌桶把流量拦住；降级，是当依

先把我这些年做数据平台项目攒下来的判断摆在前面：限流与降级不是上线前补的两个配置项，而是一套\”提前想清楚谁先死\”的架构决策。我见过太多团队把力气全花在功能堆叠上，等到业务高峰一来，最先崩的不是数据库，而是那几条谁都没在意过的数据接口。真实情况往往是这样：市场部的大屏每三十秒刷新一次，财务的系统每天早

限流和降级这两个词，在运维值班表上出现的频率，远比在架构评审文档里高。我参与过几轮大促保障，也带队复盘过几次线上事故，慢慢形成了一个和很多人不太一样的判断：限流降级的真正价值，不是\”把峰值流量挡在门外\”这么简单，而是当系统的一部分已经不可用时，让另一部分仍然能对外提供确定的、可解释的服务。挡流量是手

做数据平台和 AI 应用这么多年，我见过一个挺典型的现象：同一套限流降级配置，在银行跑得挺稳，搬到制造企业就天天误伤。问题不在技术选型，在于业务对\”停一下\”的容忍度完全不一样。限流降级从来不是一份通用参数，它是一次业务止损优先级的排序。银行的账务核心一旦被拖慢，代价会落到监管口径上，所以它宁可拒掉一

我在数据平台这行待了十来年，早几年聊限流降级，话题基本停在网关那一层：QPS 阈值、令牌桶、熔断窗口、降级返回兜底数据，一套配置配下来，值班表上就算有了交代。这两年我在项目里越来越明显地感觉到，这套东西不够用了。不是它错了，是被保护的对象变了。以前被保护的是接口，现在被保护的是数据资产本身——一张主

我在数据平台这条线上做交付和顾问十几年，见过太多\”功能清单很长、日活很低\”的项目。复盘的时候，团队大都会去查功能缺口、查培训覆盖率、查入口藏得深不深，很少有人去看另一件事：系统在最挤的那几分钟，是怎么对待员工的。限流和降级，在架构评审里通常被划到技术侧——网关加个令牌桶、接口加个并发数，评审就过了。

做了十几年企业级系统的架构评审，我越来越确信一件事：限流降级不是\”加个开关\”，而是一整套贯穿流量入口、服务调用、数据访问的资源调度能力。很多团队在立项时把注意力全放在业务功能上，等到大促或者月末结算那天系统雪崩，才回头补这套机制，代价往往是几周的紧急重构加上一轮客户信任的损耗。我参与过的项目里，真正

我做过不下二十个系统的稳定性改造，限流降级这一块，最怕两件事：一是把别人家的配置抄过来直接用，二是参数在会议室里拍完就再也不动。一个日活三万的小系统和一个日调用十亿次的数据服务网关，套同一组阈值，结果必然是前者资源闲着、后者照崩不误。我的判断很直接：限流降级没有标准答案，只有跟企业规模和业务形态对得

这行干了十来年，限流降级这类项目我评过的方案不下三十个，也亲手主导过两次迁移。有个现象一直没变：预算会上被反复讨论的那个数字，永远是软件许可加第一年服务费，而真正把项目拖到超支的支出，压根不在采购合同里。我按四年周期拆过账，采购价一般只占全周期支出的 15% 到 25%，剩下七成多散落在集成联调、规

过去几年我参与过十几个稳定性专项的预算评审，被问得最多的一句话就是：这套限流降级到底能省多少钱？说实话，绝大多数团队给出的答案都站不住脚——要么拿\”避免一次大故障就回本\”这种故事糊弄老板，要么干脆只算服务器和授权费，收益一栏空着。我自己的判断是：这件事能不能算清楚，跟技术方案好不好关系不大，关键在你