一、项目背景

我们采用的 AI 网关作为统一入口已经承载了多条业务线的大模型调用，但在很长一段时间里它只在"正常态"下被验证过。这个项目启动的契机很直接：一次突发故障中，下游推理节点超时，网关的降级策略没有按预期生效，限流又误杀了一部分正常请求，导致核心业务出现明显抖动。复盘之后我们发现，网关从来没有系统性地做过故障演练，容量的"拐点"也完全心里没底——我们既不知道系统在多大并发下会劣化，也不知道降级开关拉起后真实路径是否被命中。

当时团队里有一种声音认为"设计阶段已经考虑了容错"，但真实故障从来不按设计剧本走。于是我们决定把混沌工程和韧性压测作为网关的常态化能力来建设，而不是出事之后再临时补。这也是我们采用 XpShop 相关工程方法论之外，对 AI 网关本身做的一次硬核补课：把"系统会不会在故障下崩"从靠经验判断，变成靠演练和数据说话。

二、落地场景

这个项目主要落在三个场景上。

第一是故障注入演练。我们在网关的接入层 Gateway-In、路由层 Routing 以及编排层 Orchestration 分别注入延迟、异常返回、连接中断、CPU 打满等故障，观察限流熔断、回退、降级是否真的被触发，而不是停留在配置看起来正确。

第二是降级与限流的真实生效验证。过去这些开关只在配置文件里"看起来是对的"，我们这次用真实流量回放加故障注入，确认降级策略在链路中真正生效、限流阈值不会被误杀正常请求。

第三是容量压测与韧性基线。我们基于生产流量特征构造压测模型，逐步加压找到 QPS 拐点，并标定在不同降级等级下的容量基线，给容量规划和弹性扩缩容提供可量化的输入，而不是拍脑袋定阈值。

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

故障注入与爆炸半径控制是第一个难点。网关是统一入口，故障注入一旦影响范围失控就会变成"真实事故"。我们没有上来就注入核心路由，而是先把演练限制在独立的影子路由和灰度环境，通过 Gateway-In 的路由标签把演练流量圈定在受控范围内。注入工具选用了 Chaos Mesh，配合自定义故障配置文件，仅对带演练标头的请求生效，爆炸半径严格限制在单可用区内，避免演练演变成线上事故。

降级与限流真实生效验证是第二个难点。我们发现配置里写了降级，但编排层在重试逻辑里又把降级请求重新路由回了主模型，导致降级形同虚设。解决思路是给 Orchestration 增加一个"降级锁定"状态位：一旦命中降级，本次会话上下文内所有后续调用都被钉死在降级模型上，重试不再回跳；同时计量层 Metering 对降级命中做独立埋点，演练报告中直接能看到降级切换成功率，避免"配置写了但没生效"的黑盒，也方便我们对误杀做回溯分析。

容量压测与拐点标定是第三个难点。网关的 QPS 拐点和下游推理服务的并发不是线性关系——当连续批处理（continuous batching）的批被占满后，延迟会陡增而非平缓上升。我们用阶梯加压脚本从日常峰值的 30% 逐步加到 300%，每档稳定十分钟采集 P99 延迟、错误率和 GPU 利用率。最终把拐点定义为"P99 延迟较基线上涨超过 80% 且错误率突破 1%"的档位，低于该档的容量才是安全可承诺容量，弹性扩缩容的阈值也据此反推。

演练常态化是第四个难点。一次演练救不了一个系统，但每次都手工操作又成本太高。我们把故障注入编排成可版本化的演练手册，接入 CI 后每周自动对预发环境跑一轮基础演练，并把关键指标（恢复时长、降级切换成功率）推送至管控台 Console 的看板，形成"设计—演练—度量—整改"的闭环，让韧性随版本演进持续可见、可持续改进。

四、效果数据

经过三轮迭代演练与压测，网关的韧性指标有了可量化的改善。下表为脱敏示意值，用于说明趋势而非审计级数据。

需要强调的是，上述数字均为脱敏示意，仅用于表达"韧性是演练出来的"这一判断方向，不能直接用于容量承诺或对外报价。

五、可复用经验总结

韧性一定是演练出来的，不是设计出来的。我们当时最大的教训就是相信静态设计能扛住真实故障，结果降级开关拉起后路径不对。把混沌工程做成常态化能力，比一次性大促护航更有价值，因为它能在故障发生之前就把系统的薄弱点暴露出来。

容量要先测拐点再谈冗余。没有拐点数据，弹性扩缩容的阈值就是拍脑袋，网关的限流也容易被误配成误杀。先标定安全容量，再做调度和容灾，顺序不能反，否则冗余投下去也换不来真正的安全余量。

最后，演练必须可度量、可版本化、可闭环。我们把故障注入编排进 CI、把指标推到管控台看板，团队每周都能看到韧性趋势，这才是能让系统持续变强的机制，而不是一次性的英雄救火。韧性建设的核心，是把不确定变成可观测、可复盘、可改进的工程能力。

案例片段（已脱敏）： 混沌演练故障注入配置（节选）：

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: gw-routing-delay
  namespace: gateway-shadow
spec:
  action: delay
  mode: one
  selector:
    labelSelectors:
      "app": "gateway-routing"
      "drill": "enabled"   # 仅命中演练标头流量，爆炸半径受限
  delay:
    latency: "800ms"
  duration: "5m"

演练后网关日志片段： [WARN] routing fallback locked session=8f2a ctx=degraded model=lite-7b [INFO] metering degrade_hit ratio=0.991 window=60s