网格迁移别跳过旁路流量服务网格上线前先确认健康检查、批处理任务和内部回调是否经过与业务流量相同的策略。有些连接并不走标准入口旁路请求一旦保留旧地址就会在故障时表现出完全不同的超时和重试行为。流量镜像只能观察不能让它改变原链路的资源分配。每个阶段都应能单独停住。控制面异常时新路由不继续扩散限流配置误配时回到直连路径的条件要足够简单。云原生服务网格的渐进迁移方案服务网格迁移最怕一次切断旧链路。更稳妥的做法是把路由、状态和回滚开关拆开验证再逐步扩大流量范围。旧架构直连模式的风险点在没引入 Service Mesh 之前客户端与服务端直接依赖 Spring Cloud Eureka 或 Nacos 进行服务发现。长连接建立后客户端本地维护连接池与重试逻辑。当这种旧架构叠加 AI 推理请求时问题会迅速被放大长尾延迟导致连接池耗尽传统 HTTP/1.1 连接池在面对大模型 Streaming 响应时单条连接被长时间占用后方的阻塞请求迅速挤爆客户端线程。熔断逻辑无法全局感知各个微服务节点各自为战。某个 AI 节点因为 GPU 显存溢出OOM响应变慢客户端 A 还在源源不断送流量而客户端 B 已经触发了本地降级。金丝雀发布无法按请求特征切流旧的 Nacos 权重调整只能做到节点级别的比例划分无法识别 Header 里的x-user-tier: vip或x-model-version: v2。分阶段切换路径迁移目标不该写成“零宕机”。实际要确认的是流量能否切回、状态是否可兼容、观测数据是否足以判断下一步。阶段一旁路部署与流量镜像第一阶段不要直接截断流量。我们在 Pod 中注入 Envoy Sidecar但默认仍然使用原有的 Nacos 路由逻辑。只在 Gateway 层使用 Envoy 将生产真实流量复制一份异步发送给 service-mesh 托管的新服务组。apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ai-inference-mirror-vs spec: hosts: - ai-service.internal http: - route: - destination: host: ai-service-legacy.internal weight: 100 mirror: host: ai-service-mesh.internal mirrorPercentage: value: 10.0这个阶段的核心任务是校验网格内部 Envoy 代理对大流式 HTTP/2、gRPC 协议的兼容性观察 Envoy 在高并发下的 CPU 与内存开销。阶段二控制面同步与双轨路由Nacos 与 Service Mesh如 Istio Pilot / Kuma的数据同步是最大的绊脚石。我们编写了一个轻量级 Controller将 Nacos 中的 Instance 实例变更事件实时转换为 Istio 的ServiceEntry。这种机制保证了无论是未注入 Sidecar 的老服务还是已经注入 Sidecar 的新服务都能在同一个 IP 池里相互寻址。面向推理请求的流量治理在全面接管流量后传统 Round-Robin 算法在 AI 场景下彻底失效。因为包含 2000 个 Token 提示词的请求和 10 个 Token 的请求消耗的 Compute 资源完全不同。我们利用 Envoy 的EnvoyFilter扩展接入基于节点实时队列深度Pending Requests的动态负载均衡策略apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: ai-inference-dr spec: host: ai-service-mesh.internal trafficPolicy: loadBalancer: localityLbSetting: enabled: true consistentHash: httpHeaderName: x-session-id connectionPool: tcp: maxConnections: 1024 http: http1MaxPendingRequests: 100 maxRequestsPerConnection: 10 outlierDetection: consecutive5xxErrors: 3 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 50outlierDetection的连续错误数、检测窗口和隔离时长需要按服务目标和流量特征配置。设置后仍应观察误隔离是否影响整体容量并保留人工介入和恢复节点的流程。迁移过程中的检查项存活探测与优雅退出Envoy 收到终止信号后的排空时间应与长连接时长、发布窗口一起验证。可通过preStop钩子和终止宽限期让正在输出的响应有机会完成或返回可识别的中断状态。Header 丢失与 TraceId 断裂旧系统可能自定义了X-Custom-Req-Id网格内部 OpenTelemetry 机制默认寻找x-request-id和traceparent。在 Gateway 入口处统一打补丁转换否则链路追踪会直接撕裂成两截。内存泄漏与 Buffer 限制大模型 Batch 响应容易触发 Envoy 的 Buffer 溢出。必须显式调大 Envoy 的per_connection_buffer_limit_bytes字段设为 4MB 以上避免大量请求在高吞吐时抛出 HTTP 502。只要遵循“镜像比对 - 双轨同步 - 动态切流”三步走原本风险极高的云原生架构迁移就能彻底变成可控的例行发布。