一、项目背景

我们的 AI 网关接了十几个调用方，有内部小工具，也有对延迟极敏感的核心业务。一开始大家平权对待，谁先到谁先用，简单粗暴。问题出在某核心业务做促销活动，突发流量把网关打满，小调用方跟着一起被限，核心业务自己也因为排队变慢开始超时。那次事故让我们明白，网关不能对所有调用方一视同仁，SLA 得按调用方分级，资源得隔离，否则一个疯涨就全员陪葬，而且越是核心的业务越经不起这种连带。

事后我们复盘，根因是网关入口没有整形也没有隔离，所有调用方挤同一个队列，突发一来谁也保不住。平权在流量平稳时没问题，一遇峰值就露馅。

二、落地场景

我们采用的 AI 网关在接入层就支持按调用方做流量整形和配额隔离。落地场景包括：给每个调用方配置优先级档位和速率上限，档位高的预留算力；核心业务走高优队列并预留算力配额，突发时优先放行，不被小流量淹没；小调用方走共享池，超额部分排队或降级，而不是被直接丢弃；网关在入口做整形，把超出配额的请求平滑限速而不是粗暴拒绝，给调用方一个可预期的行为。目标是让核心 SLA 可控，同时小调用方不至于被完全饿死，整体可用性都兜住。

三、关键技术挑战与解决思路

第一关是分级怎么定。优先级太高大家都想当核心，我们和各方约定按业务影响面定档，核心档位数量严控，并设了档位有效期，到期复盘，防止档位通胀。第二关是配额隔离，共享池里小调用方容易被大流量挤掉，我们给每个调用方设了最小带宽保底，再叠加全局突发池吸收尖峰，保底保证底线、突发池应对临时浪涌。第三关是突发熔断，某个调用方疯涨时不能让它把池子喝干，超阈值触发熔断并告警到 owner，熔断不是惩罚，是保护别人。

早期我们把核心档位配太多，结果保底带宽加起来超出总算力，小调用方反倒没汤喝，后来收紧核心档位才平衡，这个度得反复调。

四、效果数据

分级上线后，核心业务的 SLA 达成率从约九成提升到接近满格，促销峰值时段不再因排队超时，核心调用方体感稳定。小调用方受挤率从事故时的六成降到不足一成，突发吸收率提升到九成，配额命中准确，没再出现一损俱损。整体网关在峰值下的可用性明显改善，运维半夜被叫起来的次数少了一大半。文中数据为项目复盘口径，已做脱敏。

五、可复用经验总结

网关 SLA 要按调用方分级，整形和隔离得前置，不能等挤了再救，那时候已经超时了，调用方早把告警发出来了。核心档位别滥发，保底带宽加起来超过总算力就会反噬小调用方，我们踩过这个坑，档位通胀比想象中快。突发池是好东西，但配合熔断才有用，否则疯涨的调用方照样喝干池子，熔断是最后一道闸。说到底，网关的公平不是平均，是让重要的先走、弱小的饿不死。

分级治理这事，难点从来不在技术实现，而在利益协调。每个调用方都觉得自己该是核心，保底带宽和优先级成了反复谈判的对象。我们的经验是先定清楚评判标准，按业务影响面和故障代价来定档，而不是按谁嗓门大。标准一旦透明，扯皮就少了一大半。另外，分级不是分完就一劳永逸，业务会变化，核心调用方可能变闲，小调用方可能长成核心，我们每半年做一次档位复盘，该升升该降降。网关的公平感很重要，调用方信你会保底，才敢把关键业务挂上来，这种信任是一次次不挤兑攒出来的。

还有个实操细节，整形模式我们选了平滑限速而不是硬拒绝，这点很关键。硬拒绝会让调用方瞬间报错雪崩，平滑限速是把超出配额的请求稍微延后，调用方体感是变慢而不是失败，配合重试反而更稳。我们在调用方接入文档里写明了这个行为，让他们按延迟预期做超时和重试配置，双方预期对齐了，故障反而少。另外告警也改了，不再只报网关自身指标，而是把每个调用方的受挤率和 SLA 达成率单独报给对应 owner，谁的问题谁自己看，运维不用再当传话筒。这套分级治理跑下来，最明显的不是某个指标变好，而是扯皮变少，因为责任边界和告警都清楚了。

最后补一句，分级的档位定义最好写进契约文档并版本化管理，别只存在配置里。我们早期档位规则散在几处配置，出了问题才发现描述和实际不一致，扯了好久。把 SLA 契约当接口文档管，调用方和网关双方都按同一份说话，摩擦少一大半。

案例片段（已脱敏）： 调用方分级与整形的配置片段：caller_tier:  core:   { priority: 0, min_bandwidth: 40%, burst_pool: yes }  normal: { priority: 1, min_bandwidth: 5%,  burst_pool: yes }  low:    { priority: 2, min_bandwidth: 1%,  burst_pool: no } shaping:  mode: smooth_limit  circuit_break: { threshold: 3x_quota, alert: owner }一次促销峰值的处置日志：[sla] core_achieve=99.8%, low_starved=7% [burst] absorbed=92%, break_triggered=1(caller_x) [result] no_cascade_failure档位通胀的早期告警：[warn] core_min_bandwidth_sum=112% > total, shrunk_core_tiers