AI 云原生后端架构与智能服务网格治理别让演示效果骗了你本文用可复现的示例场景说明排查和设计方法阈值、容量与超时设置需要结合实际流量、依赖版本和压测结果确认不能直接照搬。单机笔记本跑通模型调用跟在 Kubernetes 集群里靠 Envoy 代理智能分流完全是两码事。很多人在本地用docker-compose搞了个 Demo觉得大模型网关路由和流量治理已经搞定了等把模型服务接入 Istio 网格准备压测时才发现 Envoy 频繁抛出503 Service Unavailable或者模型推理的流式 ResponseSSE走到 Sidecar 就被阶段性截断。搞 AI 云原生后端第一步不是急着用 Helm 安装一堆复杂的 Operator而是搭一套能真实模拟 Envoy 治理行为、支持 SSE 流式代理、而且能精准抓包分析的本地脚手架。本地 K3s Envoy 环境拉起与流量阻断设计直接在宿主机开 Python 进程调 LLM 接口会掩盖所有网络层与网格治理问题。我们建议在本地使用 K3s 配合单独编译的 Envoy 配置文件或者借助 Kind 搭建双节点集群。下面这套 Docker Compose 脚手架直接模拟了 Sidecar 模式下 upstream 模型推理服务断连与超时重试的控制面逻辑。version: 3.8 services: mock-llm-upstream: image: python:3.10-slim volumes: - ./upstream:/app command: python /app/server.py ports: - 8080:8080 envoy-mesh-sidecar: image: envoyproxy/envoy:v1.28.0 volumes: - ./envoy.yaml:/etc/envoy/envoy.yaml ports: - 10000:10000 - 9901:9901 depends_on: - mock-llm-upstream这个配置的核心在于 Envoy 的envoy.yaml怎么处理 HTTP/2 与长连接 SSE。不少人在本地调试时发现 LLM 的打字机效果没了变成一次性吐出所有文字根源就是 Envoy 的 buffer 设置以及 downstream/upstream 的 HTTP 协议协商没对上。flowchart TD Client[本地 Client / Curl] --|HTTP/1.1 SSE 请求| Envoy[Envoy Sidecar :10000] Envoy --|连接池复用 HTTP/2| Filter[智能网格治理 Filter] Filter --|路由决策 / 熔断检查| Upstream[Mock LLM Server :8080] Upstream -- 分块 Chunked 数据 -- Filter Filter -- 禁用 Buffer 实时透传 -- Envoy Envoy -- 流式响应 (SSE) -- ClientSSE 流式响应截断与 Buffer 配置排障上图展示了流量从客户端穿过 Envoy 代理到上游推理服务的路径。如果没有在 Envoy 的 HTTP Connection Manager 里关掉 response bufferingEnvoy 就会默认尝试把 response body 凑够一定大小再刷给下游。在envoy.yaml的filter_chains配置中针对大模型 API 的路由配置应显式关闭 response 缓存并针对可能耗时很长的 Reasoning 阶段调大stream_idle_timeout。static_resources: listeners: - name: llm_ingress_listener address: socket_address: { address: 0.0.0.0, port_value: 10000 } filter_chains: - filters: - name: envoy.filters.network.http_connection_manager typed_config: type: type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager stat_prefix: ingress_http stream_idle_timeout: 300s codec_type: AUTO route_config: name: local_route virtual_hosts: - name: backend domains: [*] routes: - match: { prefix: /v1/chat/completions } route: cluster: llm_service_cluster timeout: 0s max_stream_duration: grpc_timeout_header_max: 0s http_filters: - name: envoy.filters.http.router typed_config: type: type.googleapis.com/envoy.extensions.filters.http.router.v3.Router clusters: - name: llm_service_cluster connect_timeout: 5s type: STRICT_DNS lb_policy: ROUND_ROBIN http2_protocol_options: {} load_assignment: cluster_name: llm_service_cluster endpoints: - lb_endpoints: - endpoint: address: socket_address: address: mock-llm-upstream port_value: 8080很多工程师容易忽略timeout: 0s这个设置。对于传统 REST API设个 15 秒超时很合理但对于大模型首 Token 延迟TTFT或者思考链输出很长的场景默认的路由超时会导致 Envoy 直接向客户端发送504 Gateway Timeout。模拟 GPU 爆显存导致的连接骤断与重试风暴在本地搭建可复现脚手架最关键的一环是能“造假故障”。大模型后端最常见的线上故障就是 GPU 显存溢出OOM导致 vLLM 或 TGI 进程直接 Killed或者推理卡死停止响应。如果 Envoy 配置了简单的失败重试当 upstream 返回 500/503 时重试请求会瞬间涌向其他推理节点。如果此时所有节点都处于高负载状态这种重试直接引发雪崩。我们可以用一小段 Python 模拟脚本在本地 upstream 中按概率抛出 503 或者只连接不发送 Headerimport time from flask import Flask, Response, stream_with_context app Flask(__name__) app.route(/v1/chat/completions, methods[POST]) def chat(): def generate(): yield data: {choices: [{delta: {content: Hello}]}\n\n time.sleep(0.5) # 模拟中途 GPU OOM 导致连接中断 raise RuntimeError(Out of CUDA memory during generation) return Response(stream_with_context(generate()), mimetypetext/event-stream) if __name__ __main__: app.run(host0.0.0.0, port8080)当客户端发起请求输出到一半突然抛出异常Envoy 的日志里会记录UCUpstream Connection termination或者URXUpstream Reset Extreme。这时看 Envoy 管理端口http://localhost:9901/stats输出的 Prometheus 指标envoy_cluster_upstream_cx_connect_fail{envoy_cluster_namellm_service_cluster} 12 envoy_cluster_upstream_rq_rx_reset{envoy_cluster_namellm_service_cluster} 5如果统计指标里的rq_rx_reset持续上升说明模型服务不是优雅关闭而是进程直接崩溃。在网格治理中应通过 Outlier Detection异常实例剔除将该 Pod 隔离而不是盲目在 Envoy 侧做 Retry。本地验证网格治理策略的基准工具想要验证本地脚手架是否管用不能用 Postman 单点测试应使用能模拟长连接并发的工具。推荐使用hey或ghz如果走 gRPC 协议配合curl -N验证流式效果。执行 50 并发请求测试本地 Envoy 代理hey -n 200 -c 50 -m POST \ -H Content-Type: application/json \ -d {model:mock,messages:[{role:user,content:test}]} \ http://localhost:10000/v1/chat/completions如果在终端看到的 HTTP Code 分布中包含非 200 响应直接查看 Envoy 的 access.log重点关注%RESPONSE_FLAGS%字段。只要出现UOUpstream Overflow或UTUpstream Timeout就说明你的服务网格配置在大模型高并发下根本扛不住需要重新调整连接池max_connections和max_pending_requests。别把演示环境的顺利当作架构设计的成功。只有在本地把断网、截断、OOM、超时这几种情况都在 Envoy 代理层抓取并处置一遍AI 云原生后端的治理方案才算真正落了地。