AI 云原生后端架构与智能服务网格治理的产品研发协作边界

“产品和研发怎样一起推进”首先要落到可观察、可回滚的工程动作上。本文从配置、调用链和运行指标三个层面梳理判断方法，重点说明应先收集什么证据、怎样做小范围验证，以及何时应停止扩张改动。

1. 一次超时配置覆盖引发的线上风波

在传统的云原生微服务体系中，Envoy 或 Istio 治理的都是响应时间相对固定的 HTTP/gRPC 服务。研发人员根据 p99 耗时设置超时时间、重试策略和熔断阈值，这套逻辑跑了许多年都没什么大问题。

但引入 LLM 之后，情况发生了变化。模型的首字延迟（TTFT）和总生成耗时受 Prompt 长度、并发 Batch 大小、甚至模型温度参数的影响极高。当产品提出“支持生成超长报告”的新需求时，他们往往只修改了业务层的参数，却不知道网格层面的 EnvoyFilter 依然按照老的 5 秒规则在拦截断流。

[前端请求] -> [API Gateway] -> [Envoy Sidecar] --(5s 超时硬拦截)--> [AI 推理服务 (需要 12s)]
                                      |
                                      +--> (触发 504 错误并自动重试 3 次，导致后端显卡被打爆)

更糟的是网格默认的重试机制。当 Envoy 判定超时后，会自动发起二次重试。对于普通幂等读接口这没问题，但对大模型推理服务来说，前一个请求还在 GPU 里算着，后一个重试请求又冲了进来，直接把推理集群的 KV Cache 挤爆，引发了雪崩。

2. 谁来定义协议：从 OpenMessage 格式到 Service Mesh Header 标头透传

要解决这种协作摩擦，第一步就是重新划定 API 的定义权。产品不能只关心输入框和输出框，研发也不能只给出一个抽象的 POST /v1/chat/completions 接口。

双方必须共同约定一套支持流式响应与状态透传的 Header 契约。网格层需要通过 HTTP Header 实时感知当前请求的特性，从而动态调整治理策略。

通过把“预期生成规模”和“流式标记”打包在标准 Header 中，网格层就可以通过 Lua 脚本或 WASM 插件动态读取这些字段：

• 当检测到 X-LLM-Priority: background 时，自动打标路由到低配离线推理节点；
• 当检测到 X-LLM-Stream: true 时，关闭网格的 Response Buffering，并把超时时间切到长连接心跳模式；
• 当检测到 X-Expected-Tokens > 1024 时，禁用网格自动重试，改由业务层显式处理失败。

这样一来，产品在配置台调整业务参数时，实际上是通过 Header 协议与网格做到了无缝协同，而不需要研发每次都手动去改 YAML 配置。

3. 流量治理规则的权限切分：EnvoyFilter 不是产品逻辑的垃圾桶

在很多团队里，容易走入另一个极端：既然网格这么强大，干脆把鉴权、敏感词过滤、Prompt 模板拼接全丢进 Envoy 的 WASM 插件里去搞。

这种做法很快就会让网格运维人员崩溃。WASM 插件一旦崩溃，影响的是整个 Pod 的 Sidecar 稳定性；而且产品频繁变更的规则（比如新增一个政治敏感词库），如果与 Envoy 治理逻辑绑死，会导致网格配置频繁热加载，带来不可预知的 CPU 抖动。

必须要明确责任边界：

+-----------------------------------------------------------------------+
| 基础设施与网格治理 (研发与运维共同维护)                                     |
| - 连接池上限、TCP KeepAlive、TLS 握手优化                              |
| - 基于 Header 的动态超时与流式路由分发                                   |
| - 节点健康检查与 GPU 实例探针熔断                                       |
+-----------------------------------------------------------------------+
                                  |
                                  v
+-----------------------------------------------------------------------+
| 业务与 AI 编排层 (产品与业务研发共同维护)                                   |
| - Prompt 模板校验、Token 配额扣减                                      |
| - 敏感词过滤、安全风控审查                                             |
| - 多模型降级（如 4o 失败自动切到 3.5）                                 |
+-----------------------------------------------------------------------+

Envoy 只做网络层的通畅与隔离，绝不触碰具体的 Prompt 文本内容。产品要加任何规则，都在业务层的 AI Gateway 或 Orchestrator 微服务里实现，网格只负责把流量安全地送到目的地。

4. 落地协同清单：从接口定义到熔断灰度发布的对齐机制

要让产品和研发真正拧成一股绳，不能光靠口头沟通，得把规范落到日常的流程检查表里：

1. 超时与重试的双向对齐：产品上线新功能前，必须在需求文档中写明该功能的“预期最长等待时间”。研发据此在网格层更新路由策略，同时在前端UI上做好“超时倒计时”或“异步通知”的心理预期铺垫。
2. 容量预估与灰度卡口：涉及模型版本升级（例如从 Llama-3-8B 升到 70B）时，产品必须提供业务并发预估。研发在 Envoy 中配置基于权重的 Canary 路由，先放 5% 的流量进入新模型节点，观察网格侧的 P99 耗时和 GPU 显存利用率，指标稳定后再逐步放量。
3. 降级预案的共同签字：当云厂商 API 爆满或者本地 GPU 节点宕机时，系统该如何表现？这是产品和研发必须提前商定的。是在前端提示“系统繁忙”，还是降级到小参数模型输出简版结果？这些逻辑要写进微服务的 Fallback 策略中，而不是等线上报错了大家才临时开会抓瞎。

大模型云原生架构的治理，本质上是用工程的严谨度去锚定大模型的不确定性。产品懂得了网格的边界，研发理解了业务的波动，智能服务网格才能真正发挥出高可用的价值。