在工程实践里，我们经常会把问题归咎于外部服务。这次事故也不例外——调用的大模型接口完全正常，返回速度和结果都没问题，但我们的系统却在短时间内陷入了全面不可用。回头看，根本原因其实不是模型，而是我们自己把系统架构设计得太脆弱了。
-
高并发下的瓶颈暴露
事件发生在业务高峰期，系统需要同时处理大量请求，每条请求都要调用大模型生成文本。最开始，只是偶尔出现延迟稍高的情况，平均响应从几百毫秒升到一两秒，我们当时以为只是暂时波动。然而，随着请求量持续增长，延迟逐渐积累，超时开始频繁出现。模型本身没有问题，接口返回正常，只是系统的线程池和请求队列完全无法承受这样的并发压力。 -
自动重试反而加速崩溃
为了提高成功率，我们在调用链路里加了自动重试逻辑。单看逻辑没毛病：请求失败就再试一次。但在高并发场景下，这种设计成了推手。一次失败触发的重试请求迅速累积，加上原本的请求流量，系统负载直线飙升。短时间内，不仅模型调用延迟增大，整个服务的响应也开始变慢，甚至出现排队超时。这种典型的“重试风暴”，让原本可控的情况彻底失控。 -
阻塞链路导致级联故障
问题进一步加剧是因为模型调用是在同步链路中完成的。每一次请求的超时，都占用一个线程直到结束。随着线程池逐渐耗尽，后续请求无法获得执行资源，哪怕是与模型调用无关的功能，也开始出现延迟甚至失败。级联效应迅速蔓延，系统整体表现出类似雪崩的症状。这个阶段，真正的瓶颈已经从外部接口转移到我们自己的架构上。 -
缺乏熔断，让系统无自我保护能力
当我们回顾整个事故，发现一个关键点：没有熔断机制。下游接口明显处于高负载状态时，上游仍然持续发送请求，系统没有任何保护。直到人工干预，手动关闭部分服务，整体才逐渐恢复。这个过程让我们深刻理解到，熔断并不是可选优化，而是保证系统在压力下仍然生存的基础能力。 -
降级才是真正的救命稻草
事后，我们对整个调用链路进行了调整。模型调用不再是强依赖，失败时可以返回兜底结果；重试次数被严格控制，并在失败率超过阈值时触发熔断；非关键场景允许跳过模型调用，让系统核心功能继续运行。这些改变没有让系统更“聪明”，但显著提高了它在异常情况下的韧性。
工程经验总结
通过这次事故，我们学到最重要的一点：问题从来不在模型本身，而在我们对系统边界和失败假设的忽略。任何外部服务，包括大模型接口，都可能在高并发或异常情况下失效。只有把失败预期放到设计层，系统才能在现实环境下平稳运行。模型可以很强大，但如果系统设计不合理，再强大的模型也救不了。
在后续的压测和异常演练中，我会顺手用支持多模型切换的 AI model APIs 平台（例如 GPT Proto wavespeed...）来模拟不同厂商在超时和限流下的表现，提前验证熔断和兜底逻辑的有效性。