Service Mesh 接入 AI 服务：先评估收益，再接受复杂度

Service Mesh 提供了丰富的功能，例如流量治理、mTLS 加密、重试机制、熔断保护以及可观测性。这套组合拳在微服务场景中确实非常实用。然而，当 AI 推理服务需要接入云原生平台时，许多团队会本能地希望将推理服务也纳入 Mesh 管理。但请注意，Mesh 并非免费的午餐，需要慎重权衡。

Sidecar 的资源开销、流式响应的处理方式、长连接的稳定性、超时参数的配置，以及调试时的复杂性，每一个环节都可能影响 AI 服务的最终表现。因此，在决定是否接入之前，必须仔细核算收益，并评估复杂度带来的成本。

一、先看治理需求

flowchart TDA[AI Service] --> B{Need Mesh?}B -->|mTLS| C[Mesh Candidate]B -->|Traffic Split| CB -->|Simple Internal| D[Plain Service]

如果只是集群内部简单的调用，现有的 Ingress 或应用层网关通常已经足够，Mesh 并非必需。但若需要更精细的流量切分、服务间 mTLS、统一的熔断策略，或者跨语言的可观测性，那么 Mesh 的价值就会凸显出来。

这里有一个关键点：不要因为平台已经部署了 Mesh，就盲目将所有 AI 服务接入。推理服务的流式输出和长超时特性，与普通短请求 API 完全不同。必须单独验证，不能采用一刀切的方案。

二、超时和重试要谨慎

retries:attempts: 1timeout: 60s

Mesh 默认的超时和重试策略，通常是为普通短请求设计的。但模型推理请求不同，它可能持续几十秒，流式响应中间也可能出现较长间隔。如果 Mesh 在半路中断，用户看到的就是生成内容被截断。重试机制更不能随意启用，重复的模型调用不仅增加成本，还可能产生副作用。

更佳的做法是，让 AI 服务在应用层明确控制重试逻辑。Mesh 负责连接治理和基础熔断，而业务级的重试、幂等、降级等逻辑，最好保留在推理网关或应用服务内。

三、Sidecar 开销要压测

measure:cpu_overheadmemory_overheadp99_latency_deltastreaming_interrupt_rate

Sidecar 会消耗 CPU 和内存，同时增加链路跳数。对于普通服务，这种影响可能不大。但对于高并发的流式推理、长连接、大响应体场景，情况完全不同。不能仅凭功能列表决定架构，必须通过实际压测来验证。

压测时，要覆盖流式响应、长上下文、并发连接以及错误场景。尤其需要关注 Sidecar 重启、配置下发、证书轮换等操作时，流式请求是否受到影响。这些细节往往才是决定成败的关键因素。

四、边界要文档化

mesh_policy:enabled_servicestimeout_rulesretry_rulesexcluded_pathsowner

一旦接入 Mesh，平台团队和业务团队都必须清楚：哪些策略由 Mesh 管理，哪些由应用管理。例如，限流在网关层，重试在应用层，mTLS 在 Mesh 层，模型路由在推理层。边界不清晰，出问题时容易互相推诿。

文档中还应包含排障方法，例如如何查看 Envoy 指标，如何判断是 Sidecar 超时还是应用超时，如何临时旁路 Mesh。Mesh 带来了能力，同时也带来了更复杂的排障路径。

如果团队缺乏足够的 Mesh 运维经验，建议先从少量低风险的 AI 服务开始试点。待观测、超时和流式响应问题跑通后，再逐步扩大范围。平台能力应循序渐进地落地，不能指望用复杂系统一次性赌成功。

退出机制也需要提前准备。如果某个 AI 服务接入 Mesh 后延迟明显上升，或流式响应不稳定，应能快速切回普通 Service 路径。进行基础设施层的架构实验时，务必给自己留一条退路。

五、总结

Service Mesh 接入 AI 服务的前提是：确认治理收益、谨慎配置超时和重试、通过压测验证 Sidecar 开销，并清晰界定 Mesh 与应用的职责边界。基础设施并非越多越稳。只有当你能解释清楚收益，又能承受住复杂度时，Mesh 才能真正成为 AI 服务治理的一部分，而非新的不确定性来源。