凌晨2:17某内容社区App的监控群炸了。不是因为我们发布了新版本也不是数据库慢查询而是上游某模型供应商的推理集群出现区域性的算力调度异常。故障持续了40分钟等供应商那边恢复我们自己的系统却花了两个多小时才完全喘过气来。更讽刺的是这40分钟里我们的信息流接口P99从80毫秒涨到接近2秒网关线程池一度耗尽消息队列开始积压连数据库连接池都出现告警——一个只服务于“AI摘要”这个子功能的第三方API差一点把整个内容分发主链路拖进雪崩。这篇文章我想把这个事故拆给你看一个模型供应商故障为什么会拖垮整个AI应用从故障传导路径、线程模型、重试机制、缓存策略到事前的架构改造和事后的应急操作全部摊开讲。无论你正在做LLM应用、智能客服、AI写作工具还是内容产品只要你的核心功能依赖外部大模型API这篇都值得读完再收藏。1. 一次“上游抖动”引发的连锁事故问题现场还原1.1 事故时间线从一次抖动到全网接口不可用先把当时的现场记录下来。我们的App信息流里有一个AI摘要功能用户刷新Feed后端会调用供应商A的模型服务为每条内容生成一段摘要。这个功能上线了大半年一直很稳。21:07供应商A的健康检查接口出现偶发超时报警等级P4值班同学没太在意21:17我们网关的P99延迟从80ms直线拉升到1.8秒P4升级为P221:25核心信息流接口开始出现超时报错用户反馈“内容加载不出来”21:32应用服务器的Tomcat线程池被打满新请求直接排队消息队列消费也开始积压21:40我们手动关闭AI摘要开关系统在几分钟内快速恢复21:47供应商A公告称其推理集群算力调度异常已逐步恢复。注意故障期间我们自己没有发过任何版本数据库各项指标完全正常CDN也健康。问题就被一层层放大了。1.2 崩溃的不是“模型服务”而是我们自己的应用进程当时最让我后背发凉的一点是我们自己的PID一点没变进程没挂内存也正常但所有线程都卡住了。原因很简单我们在网关里用同步阻塞的方式调用AI摘要服务摘要服务内部又用同步HTTP调用供应商A的接口。供应商A那边的响应从原来的300毫秒变成10秒、30秒我们这边的线程就像堵在高架上的车一样一辆都动不了。线程池是有限的一旦所有线程都被慢请求占着新的正常请求自然没人处理。这就像食堂只有一个打饭窗口前面有人一直不刷卡后面排队的人越来越多最后食堂门口都堵死了连只是路过想买杯水的人都进不去。我们犯的错误就是把AI摘要这个“非核心功能”的请求硬生生变成了核心链路的“挡路者”。1.3 “没有明显业务报错”才是最危险的状态还有一个值得专门说的事那40分钟里我们的日志系统里几乎没有明显的“业务错误”应用层面的错误率一度只上升了几个百分点。因为大量请求不是失败了而是“还没返回结果”。这种“慢而不挂”的状态非常棘手。错误可以通过监控直接告警但慢请求是隐性的它不会告诉你哪一行出了问题只会让你看到所有指标都在缓慢恶化。等到你反应过来线程池已经耗尽再想去查根因已经来不及了。2. 单点依赖为什么能变成整个系统的命脉2.1 一次普通请求背后的依赖链先还原一个请求的完整路径。用户下拉刷新Feed请求到达网关后网关要做的事包括鉴权、拉取内容列表、调摘要服务生成摘要、组装返回。摘要服务生成的逻辑是把文章标题和正文传给模型供应商的通用对话接口拿到返回的摘要文本后再拼进响应里。整个过程是典型的同步串行链路客户端 - 网关 - 信息流服务 - AI摘要服务 - 模型供应商API这条路线上每一环都有自己的超时时间、线程池和重试策略。任何一个环节配置不当都可能把上游的小故障放大成整个链路的大事故。而模型供应商API恰恰是最脆弱的一环——它依赖大规模算力调度不可控因素很多却处于整条链路的必经结点上。2.2 线程池占用这笔账算清楚才记得住以我们当时的情况举例。应用服务器的默认HTTP线程池配置了200个线程正常情况下信息流接口的平均响应时间是80毫秒200个线程足够扛住每秒几千的QPS。故障期间每个请求的响应时间变成了10秒。200个线程全部被同时占用时系统每秒能处理的请求数只有200/1020个。这意味着哪怕只有20个用户同时发起请求整个服务就已经无法处理更多请求了。数学不会骗人。上游响应延迟放大125倍下游吞吐量直接缩到原来的几十分之一。我们没有增加机器也没有发布任何东西但系统就是神奇地“不够用了”。2.3 重试机制本意是救火结果却成了纵火事故复盘时我们发现代码里到处都写着“失败自动重试”。当时的设计者认为这是提高成功率的常规操作但没有任何一个重试策略针对“供应商整体故障”这种场景做过考虑。默认的重试逻辑是失败后立刻重试1次2秒后再重试1次。当供应商A的接口持续超时每个请求不仅占住线程10秒还要在超时后立刻重试把200个线程的占用时间进一步拉长。从供应商A那侧的视角看我们这边的流量在故障期间不降反升达到了平时的3到4倍这又进一步加剧了它的调度问题。重试只适合处理偶发的瞬时抖动不适合应对持续故障。判断不了这一点重试就会变成流量放大器。3. 故障传导的三条典型路径从供应商抖动到用户刷不出内容3.1 路径一同步调用链上的阻塞放大第一条路径最直接也最容易被忽视。同步调用意味着你的线程必须等待供应商返回结果才能继续往下走。供应商慢你就慢像等一个一直不回复微信消息的人。我们当时的网关、信息流服务和摘要服务全部是同步调用。问题本来是“摘要服务变慢”但因为信息流服务在等摘要服务网关也在等信息流服务于是整条链路上所有服务的线程池同时被占满。从用户侧看到的很统一一直转圈刷不出来超时。所以“拖垮整个AI应用”的第一步不是供应商挂了而是同步依赖把所有下游服务一起挂在悬崖边上。3.2 路径二重试风暴把局部抖动变成流量高峰第二条路径就是上面提到的重试放大。大家可以想象这样一个场景一个深度模型服务平时承载我们每秒几百次的调用突然响应超时。我们的服务看不到真实情况只知道“这次请求失败了”于是自动重试。如果有30个并发请求同时失败每个重试3次供应商那侧感受到的压力会瞬间变成120个请求。更糟糕的是重试请求还很集中在同一个时间窗口内。这会让供应商的限流器更早触发最终导致我们连正常的请求也被拒绝。从“响应慢”演变成“被限流拒掉”整个故障的影响范围又扩大了一轮。3.3 路径三缓存缺失导致请求全量穿透复盘时我们发现一个扎心的事实我们的AI摘要结果几乎没有做缓存。用户每次刷新Feed都会重新调一次模型接口去生成摘要。系统正常的时候成本和延迟都还能接受但一旦供应商抖动没有缓存保护所有请求都会直接打到最薄弱的那一环。这就像下大雨时所有人同时跑到唯一一个小亭子避雨——亭子不倒才怪。正确的做法应该在系统里建“若干候补避雨点”哪怕这些避雨点是临时的、内容稍微旧一点的。3.4 缺失的隔离边界非核心功能为什么能拖死核心功能本质上我们犯的错误不是“用了外部模型API”而是没有给外部依赖画好边界。正确的隔离做法是核心信息流不该等待AI摘要的结果。摘要生成得出来就展示生成不出来完全可以先不显示或者用一个默认文案顶上。需求方当然希望每个内容都有摘要但工程上必须明确AI摘要是一个增强功能不是一个必不可少的功能。没有这层隔离任何非核心功能的故障都会传导到核心链路上。这就是标题里“拖垮整个AI应用”的根本原因。4. 给依赖装上“免疫系统”事前架构改造清单4.1 超时时间和重试次数最便宜但最容易被忽视的保命配置先说最简单、投入产出比最高的一项设置合理的超时时间和重试次数。之前我们的代码几乎没有给模型调用设置明确的超时最终默认值非常宽容。后来我们统一改成连接超时1.5秒、读取超时5秒并且只对第一次失败后的重试放行1次重试间隔加上随机抖动。你可能觉得5秒很短但对大多数通用模型接口来说正常情况下的响应应该在2秒以内5秒已经足够容忍波动同时又能防止线程被长期占用。这里的关键不只是把超时调短而是要在多个层级都做限制网络层、服务调用层、业务逻辑层。每一层都要有兜底否则总有一层会把超时时间悄悄放宽到30秒。4.2 熔断机制让故障范围受控超时只能解决“请求该等多久”的问题解决不了“故障期间该不该继续调用”的问题。为此我们给模型调用链路加上了熔断器。熔断器的逻辑不复杂在一个统计周期内如果模型接口的错误率超过阈值比如10秒内失败率超过50%就快速打开熔断开关后续请求不再真正调用模型服务而是直接走降级逻辑。过一段时间进入半开状态放少量请求试探供应商是否恢复恢复则自动合上熔断未恢复则继续打开。这个机制的作用是在供应商故障期间我们这边的模型调用量会直接降到接近零线程池资源被彻底释放核心链路恢复正常。哪怕供应商那边故障持续一个小时我们最多损失AI摘要这个子功能而不是整个App。4.3 缓存与兜底数据哪怕先给一个旧结果也行缓存这件事现在成了我们所有模型调用的标配。模型生成的摘要结果不再直接透传给用户后就丢弃而是按“内容ID 模型版本 参数组合”作为key存下来。用户第二次访问同一篇文章时直接命中缓存不产生新的模型调用。TTL设置到30分钟左右既能保证摘要内容不算过时又能很大程度稀释真实请求量。更关键的是缓存没有命中时的兜底策略。我们当时把摘要服务改成模型调用失败时返回缓存中最近一次成功的结果完全没有缓存且模型不可用时返回一个简短但通顺的文案比如“AI摘要暂时不可用”。这个策略听起来很简陋但它保证了信息流主链路永远有一个可以返回的东西而不是让请求卡死或报错。4.4 多模型路由与降级开关不要把鸡蛋放在一个篮子里如果预算允许考虑引入至少两个模型供应商并在前面加一层路由代理。主供应商健康时全部流量走主链路检测到异常后自动切到备选供应商。我们目前的实现是在摘要服务内维护一个简单的供应商列表每个供应商配一个健康状态。健康检查不只是调一个ping接口而是构造一个最小的真实请求去验证模型的可用性。主供应商连续失败3次就标记为不健康切入备选供应商。另外每个对模型有依赖的功能模块都要有一个独立的功能开关。上线时把开关打开事故时一键降级。开关最好做成远程配置中心下发避免改代码重新发布这种迟钝的操作。4.5 异步化改造能异步的就别同步等最后是架构层面的独立思考哪些模型调用必须同步返回哪些可以挪到异步链路里。拿我们的AI摘要功能举例它其实根本不需要在信息流请求内同步等结果。更合理的设计是信息流返回时摘要字段先留空客户端展示时走一个异步接口或者摘要服务消费消息队列后台异步生成摘要推送到前端后再补充展示。这种改造的成本比加缓存高但它带来的收益是巨大的——核心链路和模型依赖彻底解耦。就算供应商故障再久用户依然能刷内容、看文章、点赞评论只是摘要位置的内容更新慢一些。5. 事故当晚的救火手册供应商故障下的应急操作顺序5.1 第一步确认影响面而不是急着“修复”故障来临时最大的敌人不是故障本身而是慌乱。我见过很多团队在故障发生后第一时间就去联系供应商、翻日志、想要恢复结果手忙脚乱地连影响范围都没确认清楚。正确的第一步永远是回答三个问题有没有外部客户在受影响影响的是哪个功能范围是模型方故障还是我们自己的问题有没有外部客户受影响可以由网关的错误率和P99指标确认。影响的是什么功能范围可以通过链路追踪逐个服务排查确认。至于是不是模型方故障最简单的方法是直接看供应商的状态页和健康检查接口。这三个问题搞清楚后很多看起来复杂的故障已经定位了一半。5.2 第二步快速止损动作要快、范围要小确认影响面后不要等供应商恢复先做止损操作。按优先级顺序来打开降级开关关闭AI摘要、关闭其他非核心模型依赖功能调低模型调用的超时时间如果线上还能改配置把读取超时从5秒临时降到1秒启动熔断或限制模型API并发把发往供应商的流量压到最低全力保护核心链路切换备用供应商如果有的话直接切过去。这里要特别强调“动作要快、范围要小”的原因降级开关一开核心链路马上能恢复正常但如果你同时切了好几个开关一旦出现新问题你很难判断是哪个操作引起的。能用一个开关解决问题就不要动两个。5.3 第三步恢复验证与流量回切等供应商确认修复后不要立刻把流量全部切回主链路。先放5%的请求试运行10分钟观察错误率和延迟指标确认稳定后逐步放开到100%。回切时还有一种情况要警惕供应商刚恢复的时刻我们的重试队列里积压了大量请求如果瞬间全部回放供应商可能被再次冲垮。稳妥的做法是让积压任务以较低速率消费宁可让部分用户多看一会儿旧摘要也别再次制造流量高峰。5.4 故障复盘会上必须回答的问题故障结束后复盘不是走流程。我每次都会要求团队回答五个问题为什么超时时间是30秒而不是3秒为什么重试策略没有针对持续故障做退出机制为什么没有缓存兜底为什么没有熔断为什么线上没有一键降级开关如果答案里有“当时没想那么多”“一直没时间做”这样的理由那这次故障最大的价值就是把这些技术债暴露了出来。6. 供应商管理也是可靠性工程的一部分别等翻车才看合同6.1 技术视角的供应商可靠性指标很多团队选模型供应商时只看模型的跑分、单价和文档体验忽略了运维和可靠性视角。供应商故障会直接传导到用户侧怎么评估一个供应商在故障时的表现我认为至少要看五个维度。评估维度具体检查点为什么重要状态页与健康接口是否有实时状态页健康接口是否公开可用故障时能快速确认上游状态避免误判故障通知机制是否主动推送事故通知还是让客户自己发现主动通知能帮你提前止损而非被动挨打错误码设计429/503/500分别对应什么场景响应是否有明确header错误码清晰才能让熔断策略精准触发限流策略透明度限流阈值是多少达到后是拒绝还是排队是否可申请调整不透明的限流会在关键时刻杀你一个措手不及多区域与容灾能力供应商是否有多个可用区故障时能否自动转移供应商自己有没有冗余决定了它的恢复时间6.2 把“故障处理”写进合作条款里商务层面也要跟进。很多工程师觉得合同是法务的事其实SLA条款直接决定了故障时你能获得多少保障。至少应该在合同里明确故障通知时限、SLA的具体计算口径、故障补偿方式、以及供应商对限流策略的告知义务。我们之前就遇到过一个供应商SLA承诺99.9%但按他们的计算口径半夜那次1小时的故障根本不算入SLA因为“处于计划维护窗口内”。条款不抠清楚指望供应商主动给你补偿是不现实的。6.3 故障演练别让预案只停留在PPT里最后说一个很多人忽略的动作定期做故障演练。不需要真把供应商搞挂也不一定要在线上场景做。可以选一个预发环境模拟“模型接口超时率100%”的情况强迫团队按应急预案走一遍。看看降级开关能不能在一分钟内打开熔断器参数合不合理团队沟通流程有没有坑。我第一次组织这个演练时出了不少洋相降级开关是有的但配置中心的权限只掌握在一个人手里他不在线开关就没法操作。这种问题只有演练才能暴露等到真实故障才去发现代价就太大了。现在每次供应商出问题反而成了我检查系统架构的日子。说句实在话一个AI应用里最不稳定的往往不是你自己的代码而是外部依赖。超时、重试、熔断、降级、缓存、多路由这些机制都不炫酷但没有它们再强的模型能力也扛不住一次上游抖动。你在系统里给失败多留一扇门用户就少一次转圈卡死你自己也少一次凌晨三点盯着监控大屏捶胸顿足的体验。
凌晨2:17某内容社区App的监控群炸了。不是因为我们发布了新版本也不是数据库慢查询而是上游某模型供应商的推理集群出现区域性的算力调度异常。故障持续了40分钟等供应商那边恢复我们自己的系统却花了两个多小时才完全喘过气来。更讽刺的是这40分钟里我们的信息流接口P99从80毫秒涨到接近2秒网关线程池一度耗尽消息队列开始积压连数据库连接池都出现告警——一个只服务于“AI摘要”这个子功能的第三方API差一点把整个内容分发主链路拖进雪崩。这篇文章我想把这个事故拆给你看一个模型供应商故障为什么会拖垮整个AI应用从故障传导路径、线程模型、重试机制、缓存策略到事前的架构改造和事后的应急操作全部摊开讲。无论你正在做LLM应用、智能客服、AI写作工具还是内容产品只要你的核心功能依赖外部大模型API这篇都值得读完再收藏。1. 一次“上游抖动”引发的连锁事故问题现场还原1.1 事故时间线从一次抖动到全网接口不可用先把当时的现场记录下来。我们的App信息流里有一个AI摘要功能用户刷新Feed后端会调用供应商A的模型服务为每条内容生成一段摘要。这个功能上线了大半年一直很稳。21:07供应商A的健康检查接口出现偶发超时报警等级P4值班同学没太在意21:17我们网关的P99延迟从80ms直线拉升到1.8秒P4升级为P221:25核心信息流接口开始出现超时报错用户反馈“内容加载不出来”21:32应用服务器的Tomcat线程池被打满新请求直接排队消息队列消费也开始积压21:40我们手动关闭AI摘要开关系统在几分钟内快速恢复21:47供应商A公告称其推理集群算力调度异常已逐步恢复。注意故障期间我们自己没有发过任何版本数据库各项指标完全正常CDN也健康。问题就被一层层放大了。1.2 崩溃的不是“模型服务”而是我们自己的应用进程当时最让我后背发凉的一点是我们自己的PID一点没变进程没挂内存也正常但所有线程都卡住了。原因很简单我们在网关里用同步阻塞的方式调用AI摘要服务摘要服务内部又用同步HTTP调用供应商A的接口。供应商A那边的响应从原来的300毫秒变成10秒、30秒我们这边的线程就像堵在高架上的车一样一辆都动不了。线程池是有限的一旦所有线程都被慢请求占着新的正常请求自然没人处理。这就像食堂只有一个打饭窗口前面有人一直不刷卡后面排队的人越来越多最后食堂门口都堵死了连只是路过想买杯水的人都进不去。我们犯的错误就是把AI摘要这个“非核心功能”的请求硬生生变成了核心链路的“挡路者”。1.3 “没有明显业务报错”才是最危险的状态还有一个值得专门说的事那40分钟里我们的日志系统里几乎没有明显的“业务错误”应用层面的错误率一度只上升了几个百分点。因为大量请求不是失败了而是“还没返回结果”。这种“慢而不挂”的状态非常棘手。错误可以通过监控直接告警但慢请求是隐性的它不会告诉你哪一行出了问题只会让你看到所有指标都在缓慢恶化。等到你反应过来线程池已经耗尽再想去查根因已经来不及了。2. 单点依赖为什么能变成整个系统的命脉2.1 一次普通请求背后的依赖链先还原一个请求的完整路径。用户下拉刷新Feed请求到达网关后网关要做的事包括鉴权、拉取内容列表、调摘要服务生成摘要、组装返回。摘要服务生成的逻辑是把文章标题和正文传给模型供应商的通用对话接口拿到返回的摘要文本后再拼进响应里。整个过程是典型的同步串行链路客户端 - 网关 - 信息流服务 - AI摘要服务 - 模型供应商API这条路线上每一环都有自己的超时时间、线程池和重试策略。任何一个环节配置不当都可能把上游的小故障放大成整个链路的大事故。而模型供应商API恰恰是最脆弱的一环——它依赖大规模算力调度不可控因素很多却处于整条链路的必经结点上。2.2 线程池占用这笔账算清楚才记得住以我们当时的情况举例。应用服务器的默认HTTP线程池配置了200个线程正常情况下信息流接口的平均响应时间是80毫秒200个线程足够扛住每秒几千的QPS。故障期间每个请求的响应时间变成了10秒。200个线程全部被同时占用时系统每秒能处理的请求数只有200/1020个。这意味着哪怕只有20个用户同时发起请求整个服务就已经无法处理更多请求了。数学不会骗人。上游响应延迟放大125倍下游吞吐量直接缩到原来的几十分之一。我们没有增加机器也没有发布任何东西但系统就是神奇地“不够用了”。2.3 重试机制本意是救火结果却成了纵火事故复盘时我们发现代码里到处都写着“失败自动重试”。当时的设计者认为这是提高成功率的常规操作但没有任何一个重试策略针对“供应商整体故障”这种场景做过考虑。默认的重试逻辑是失败后立刻重试1次2秒后再重试1次。当供应商A的接口持续超时每个请求不仅占住线程10秒还要在超时后立刻重试把200个线程的占用时间进一步拉长。从供应商A那侧的视角看我们这边的流量在故障期间不降反升达到了平时的3到4倍这又进一步加剧了它的调度问题。重试只适合处理偶发的瞬时抖动不适合应对持续故障。判断不了这一点重试就会变成流量放大器。3. 故障传导的三条典型路径从供应商抖动到用户刷不出内容3.1 路径一同步调用链上的阻塞放大第一条路径最直接也最容易被忽视。同步调用意味着你的线程必须等待供应商返回结果才能继续往下走。供应商慢你就慢像等一个一直不回复微信消息的人。我们当时的网关、信息流服务和摘要服务全部是同步调用。问题本来是“摘要服务变慢”但因为信息流服务在等摘要服务网关也在等信息流服务于是整条链路上所有服务的线程池同时被占满。从用户侧看到的很统一一直转圈刷不出来超时。所以“拖垮整个AI应用”的第一步不是供应商挂了而是同步依赖把所有下游服务一起挂在悬崖边上。3.2 路径二重试风暴把局部抖动变成流量高峰第二条路径就是上面提到的重试放大。大家可以想象这样一个场景一个深度模型服务平时承载我们每秒几百次的调用突然响应超时。我们的服务看不到真实情况只知道“这次请求失败了”于是自动重试。如果有30个并发请求同时失败每个重试3次供应商那侧感受到的压力会瞬间变成120个请求。更糟糕的是重试请求还很集中在同一个时间窗口内。这会让供应商的限流器更早触发最终导致我们连正常的请求也被拒绝。从“响应慢”演变成“被限流拒掉”整个故障的影响范围又扩大了一轮。3.3 路径三缓存缺失导致请求全量穿透复盘时我们发现一个扎心的事实我们的AI摘要结果几乎没有做缓存。用户每次刷新Feed都会重新调一次模型接口去生成摘要。系统正常的时候成本和延迟都还能接受但一旦供应商抖动没有缓存保护所有请求都会直接打到最薄弱的那一环。这就像下大雨时所有人同时跑到唯一一个小亭子避雨——亭子不倒才怪。正确的做法应该在系统里建“若干候补避雨点”哪怕这些避雨点是临时的、内容稍微旧一点的。3.4 缺失的隔离边界非核心功能为什么能拖死核心功能本质上我们犯的错误不是“用了外部模型API”而是没有给外部依赖画好边界。正确的隔离做法是核心信息流不该等待AI摘要的结果。摘要生成得出来就展示生成不出来完全可以先不显示或者用一个默认文案顶上。需求方当然希望每个内容都有摘要但工程上必须明确AI摘要是一个增强功能不是一个必不可少的功能。没有这层隔离任何非核心功能的故障都会传导到核心链路上。这就是标题里“拖垮整个AI应用”的根本原因。4. 给依赖装上“免疫系统”事前架构改造清单4.1 超时时间和重试次数最便宜但最容易被忽视的保命配置先说最简单、投入产出比最高的一项设置合理的超时时间和重试次数。之前我们的代码几乎没有给模型调用设置明确的超时最终默认值非常宽容。后来我们统一改成连接超时1.5秒、读取超时5秒并且只对第一次失败后的重试放行1次重试间隔加上随机抖动。你可能觉得5秒很短但对大多数通用模型接口来说正常情况下的响应应该在2秒以内5秒已经足够容忍波动同时又能防止线程被长期占用。这里的关键不只是把超时调短而是要在多个层级都做限制网络层、服务调用层、业务逻辑层。每一层都要有兜底否则总有一层会把超时时间悄悄放宽到30秒。4.2 熔断机制让故障范围受控超时只能解决“请求该等多久”的问题解决不了“故障期间该不该继续调用”的问题。为此我们给模型调用链路加上了熔断器。熔断器的逻辑不复杂在一个统计周期内如果模型接口的错误率超过阈值比如10秒内失败率超过50%就快速打开熔断开关后续请求不再真正调用模型服务而是直接走降级逻辑。过一段时间进入半开状态放少量请求试探供应商是否恢复恢复则自动合上熔断未恢复则继续打开。这个机制的作用是在供应商故障期间我们这边的模型调用量会直接降到接近零线程池资源被彻底释放核心链路恢复正常。哪怕供应商那边故障持续一个小时我们最多损失AI摘要这个子功能而不是整个App。4.3 缓存与兜底数据哪怕先给一个旧结果也行缓存这件事现在成了我们所有模型调用的标配。模型生成的摘要结果不再直接透传给用户后就丢弃而是按“内容ID 模型版本 参数组合”作为key存下来。用户第二次访问同一篇文章时直接命中缓存不产生新的模型调用。TTL设置到30分钟左右既能保证摘要内容不算过时又能很大程度稀释真实请求量。更关键的是缓存没有命中时的兜底策略。我们当时把摘要服务改成模型调用失败时返回缓存中最近一次成功的结果完全没有缓存且模型不可用时返回一个简短但通顺的文案比如“AI摘要暂时不可用”。这个策略听起来很简陋但它保证了信息流主链路永远有一个可以返回的东西而不是让请求卡死或报错。4.4 多模型路由与降级开关不要把鸡蛋放在一个篮子里如果预算允许考虑引入至少两个模型供应商并在前面加一层路由代理。主供应商健康时全部流量走主链路检测到异常后自动切到备选供应商。我们目前的实现是在摘要服务内维护一个简单的供应商列表每个供应商配一个健康状态。健康检查不只是调一个ping接口而是构造一个最小的真实请求去验证模型的可用性。主供应商连续失败3次就标记为不健康切入备选供应商。另外每个对模型有依赖的功能模块都要有一个独立的功能开关。上线时把开关打开事故时一键降级。开关最好做成远程配置中心下发避免改代码重新发布这种迟钝的操作。4.5 异步化改造能异步的就别同步等最后是架构层面的独立思考哪些模型调用必须同步返回哪些可以挪到异步链路里。拿我们的AI摘要功能举例它其实根本不需要在信息流请求内同步等结果。更合理的设计是信息流返回时摘要字段先留空客户端展示时走一个异步接口或者摘要服务消费消息队列后台异步生成摘要推送到前端后再补充展示。这种改造的成本比加缓存高但它带来的收益是巨大的——核心链路和模型依赖彻底解耦。就算供应商故障再久用户依然能刷内容、看文章、点赞评论只是摘要位置的内容更新慢一些。5. 事故当晚的救火手册供应商故障下的应急操作顺序5.1 第一步确认影响面而不是急着“修复”故障来临时最大的敌人不是故障本身而是慌乱。我见过很多团队在故障发生后第一时间就去联系供应商、翻日志、想要恢复结果手忙脚乱地连影响范围都没确认清楚。正确的第一步永远是回答三个问题有没有外部客户在受影响影响的是哪个功能范围是模型方故障还是我们自己的问题有没有外部客户受影响可以由网关的错误率和P99指标确认。影响的是什么功能范围可以通过链路追踪逐个服务排查确认。至于是不是模型方故障最简单的方法是直接看供应商的状态页和健康检查接口。这三个问题搞清楚后很多看起来复杂的故障已经定位了一半。5.2 第二步快速止损动作要快、范围要小确认影响面后不要等供应商恢复先做止损操作。按优先级顺序来打开降级开关关闭AI摘要、关闭其他非核心模型依赖功能调低模型调用的超时时间如果线上还能改配置把读取超时从5秒临时降到1秒启动熔断或限制模型API并发把发往供应商的流量压到最低全力保护核心链路切换备用供应商如果有的话直接切过去。这里要特别强调“动作要快、范围要小”的原因降级开关一开核心链路马上能恢复正常但如果你同时切了好几个开关一旦出现新问题你很难判断是哪个操作引起的。能用一个开关解决问题就不要动两个。5.3 第三步恢复验证与流量回切等供应商确认修复后不要立刻把流量全部切回主链路。先放5%的请求试运行10分钟观察错误率和延迟指标确认稳定后逐步放开到100%。回切时还有一种情况要警惕供应商刚恢复的时刻我们的重试队列里积压了大量请求如果瞬间全部回放供应商可能被再次冲垮。稳妥的做法是让积压任务以较低速率消费宁可让部分用户多看一会儿旧摘要也别再次制造流量高峰。5.4 故障复盘会上必须回答的问题故障结束后复盘不是走流程。我每次都会要求团队回答五个问题为什么超时时间是30秒而不是3秒为什么重试策略没有针对持续故障做退出机制为什么没有缓存兜底为什么没有熔断为什么线上没有一键降级开关如果答案里有“当时没想那么多”“一直没时间做”这样的理由那这次故障最大的价值就是把这些技术债暴露了出来。6. 供应商管理也是可靠性工程的一部分别等翻车才看合同6.1 技术视角的供应商可靠性指标很多团队选模型供应商时只看模型的跑分、单价和文档体验忽略了运维和可靠性视角。供应商故障会直接传导到用户侧怎么评估一个供应商在故障时的表现我认为至少要看五个维度。评估维度具体检查点为什么重要状态页与健康接口是否有实时状态页健康接口是否公开可用故障时能快速确认上游状态避免误判故障通知机制是否主动推送事故通知还是让客户自己发现主动通知能帮你提前止损而非被动挨打错误码设计429/503/500分别对应什么场景响应是否有明确header错误码清晰才能让熔断策略精准触发限流策略透明度限流阈值是多少达到后是拒绝还是排队是否可申请调整不透明的限流会在关键时刻杀你一个措手不及多区域与容灾能力供应商是否有多个可用区故障时能否自动转移供应商自己有没有冗余决定了它的恢复时间6.2 把“故障处理”写进合作条款里商务层面也要跟进。很多工程师觉得合同是法务的事其实SLA条款直接决定了故障时你能获得多少保障。至少应该在合同里明确故障通知时限、SLA的具体计算口径、故障补偿方式、以及供应商对限流策略的告知义务。我们之前就遇到过一个供应商SLA承诺99.9%但按他们的计算口径半夜那次1小时的故障根本不算入SLA因为“处于计划维护窗口内”。条款不抠清楚指望供应商主动给你补偿是不现实的。6.3 故障演练别让预案只停留在PPT里最后说一个很多人忽略的动作定期做故障演练。不需要真把供应商搞挂也不一定要在线上场景做。可以选一个预发环境模拟“模型接口超时率100%”的情况强迫团队按应急预案走一遍。看看降级开关能不能在一分钟内打开熔断器参数合不合理团队沟通流程有没有坑。我第一次组织这个演练时出了不少洋相降级开关是有的但配置中心的权限只掌握在一个人手里他不在线开关就没法操作。这种问题只有演练才能暴露等到真实故障才去发现代价就太大了。现在每次供应商出问题反而成了我检查系统架构的日子。说句实在话一个AI应用里最不稳定的往往不是你自己的代码而是外部依赖。超时、重试、熔断、降级、缓存、多路由这些机制都不炫酷但没有它们再强的模型能力也扛不住一次上游抖动。你在系统里给失败多留一扇门用户就少一次转圈卡死你自己也少一次凌晨三点盯着监控大屏捶胸顿足的体验。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
