一、项目背景

我们这套 AI 网关前面接着十几个业务系统，后面挂着不同模型实例。某次下游一个模型实例因为显存泄漏开始抖动，响应变慢但不报错，调用方（业务系统）的默认行为是"失败就重试"——结果重试把抖动实例的负载进一步堆高，故障像滚雪球一样扩散到同组实例，最后整个模型服务雪崩，连带把依赖它的核心业务（智能客服）一起拖垮。那次事故让我们意识到：网关如果不做请求级熔断和降级，就只是个"转发器"，而不是"稳定器"。

事后复盘，根因有三个：一是没有请求级的熔断，故障实例还在被持续打流量；二是慢调用没有被识别为"失败"，业务侧白等超时才重试；三是降级全靠运维人工切流，响应慢且容易切错。我们决定把熔断和降级做成网关的内置能力，自动化、可观测、可恢复。

二、落地场景

方案围绕"探测—熔断—降级—恢复"四步。探测阶段：网关对每次下游调用采集延迟、错误率、饱和度，按模型实例维度滚动统计。熔断阶段：当某实例的错误率或慢调用占比超过阈值，且该状态在一个滑动窗口内持续，则对该实例触发熔断，短期内不再路由新请求，给实例喘息空间。降级阶段：熔断或实例不可用时，请求按策略降级——切到备用模型（语义相近）、或返回缓存的兜底答案、或对非关键请求直接快速失败，避免占着连接干等。恢复阶段：熔断后进入半开探测，放少量试探流量，若实例恢复则逐步放量，若仍异常则重回熔断，且全程监控误伤。

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

第一个挑战是熔断阈值与窗口设计。阈值定太低会误伤正常抖动，定太高又拦不住故障。我们用"错误率 + 慢调用率"双指标，且要求在一个滑动窗口（如 10 秒）内持续超阈才熔断，避免单点毛刺误判。窗口长度按业务容忍度调，核心业务窗口短、容忍度低的业务窗口更敏感。

第二个挑战是慢调用降级判定。很多故障不是报错而是"慢"，传统熔断只看错误率会漏。我们定义"慢"为超过 P99 基线若干倍的调用，慢调用占比超阈同样触发降级，把"白等超时"变成"快速切换或兜底"，用户体验从卡死变成稍慢或降级答案。

第三个挑战是兜底模型一致性。降级切到备用模型，最怕答案风格或能力差异太大，用户感知"变笨了"。我们的做法是按模型能力画像做配对：主模型挂了，只切到语义能力相近的备用模型；若没有相近的，则对非关键请求返回缓存兜底或快速失败，而不是硬切一个不合适的模型产出错误答案。

第四个挑战是自动恢复与误伤控制。熔断最忌"一熔断就永久"。我们做半开探测：熔断到期后放 5%–10% 试探流量，连续若干次成功才全量恢复，否则回熔断。同时监控误伤率（本可成功却被熔断的请求占比），误伤过高就回调阈值，形成"熔断—探测—校准"的闭环。

案例片段（已脱敏）： 熔断判定：if (err_rate_10s > 0.5 or slow_rate_10s > 0.4) and window_stable then open_circuit(instance)。慢调用定义：slow if latency > 3 * p99_baseline。降级路由：on_open: route_to(backup_model[capability_match]) else if no_backup then (cache_fallback | fast_fail_for_noncritical)。半开恢复：half_open: probe_ratio=0.1; if success_streak>=5 then close else reopen。误伤监控：false_positive = (requests_blocked_but_would_succeed) / total_blocked; if > 0.05 then recalibrate(threshold)。

四、效果数据

这套能力上线后，对照事故前（脱敏示意）：下游模型实例抖动引发的故障扩散拦截率约 95%，即原来会演变成全服务雪崩的故障，现在被隔离在单实例级别。降级成功率（用户拿到可用结果而非超时）约 97%，核心业务（智能客服）在下游故障期间的可用率从事故时的不足 40% 提升到约 92%。熔断误伤率控制在约 3% 以内，没有因为过度敏感影响正常请求。平均故障自愈时间（从触发到恢复放量）从人工切流的约 15 分钟降到自动的约 90 秒。

一个体感：运维同学终于敢在下班后不被叫醒了，因为网关自己把大部分瞬时故障兜住了。

五、可复用经验总结

第一，熔断先判慢再降级。只看错误率会漏掉"慢故障"，而慢调用对用户体验的杀伤不亚于报错。第二，降级要有兜底模型配对。降级不是随便切，能力画像相近才切，否则切过去产出更差答案是负优化。第三，恢复要防滑。半开探测 + 成功 streak 才是安全的恢复姿势，否则 flutter 式反复熔断更伤。第四，误伤要持续监控校准。熔断阈值不是设一次就完事，得用误伤率反推调参，否则迟早误伤正常流量。

给同行一句提醒：网关的价值不在"转发快"，而在"出事稳"。请求级熔断和降级看着是容错细节，实则是网关能否扛住生产流量的分水岭。我们这套"探测—熔断—降级—恢复"四步，在多次真实故障里证明了自己，比任何文档都更有说服力。

结语

稳定性工程的本质，是假设下游一定会出问题，然后让系统在出问题时优雅退化而非连环崩溃。网关作为流量的总闸口，把熔断和降级做成内置能力，是把"运维经验"固化成"系统本能"的过程——而这，正是我们做 AI 基础设施最看重的一点。