这篇讲什么

Service Mesh 把服务间通信从业务 SDK 里抽出来，放到数据平面代理上。控制平面下发路由、超时、重试、熔断和 mTLS 策略，数据平面真正转发流量。它管的是集群内部的东西向调用，不是南北向入口——入口仍是 API Gateway。早期实现几乎全是 sidecar（Istio 用 Envoy、Linkerd 用 Rust microproxy）；现在 Istio Ambient 已经把 L4 放到节点级 ztunnel，L7 只在需要时走 waypoint，Cilium 则把 L4 推进 eBPF。核心没变：业务进程不感知网络策略。常见坑是把它当银弹——服务少、调用简单时，代理的 CPU、延迟和排障成本会高于收益。

先抓住这三点

  • 分清南北向和东西向。Gateway 做鉴权、限流、对外路由；Mesh 负责服务间超时、重试预算、金丝雀和零信任。不要用 Mesh 替代网关，也不要把这些能力再写进每个语言的 SDK。
  • 先观测和流量策略，再全站加密。超时、重试预算、熔断、故障注入比一上来全网格 mTLS 更要紧。没有预算的重试会把局部故障放大成雪崩。
  • 代理不是免费的。sidecar 按 Pod 计费，Ambient 的 ztunnel 按节点计费，waypoint 按需要 L7 的服务计费。出问题先看代理日志和策略下发，不要只翻业务日志。

什么时候用

多语言微服务、K8s 上服务数量上来、需要统一 mTLS、金丝雀或按服务的 L7 授权时，Mesh 才划算。十来个 Java 服务、Spring Cloud Gateway 加注册中心已经够用就别上。新集群优先考虑 Istio Ambient，或已有 CNI 是 Cilium 时的 Cilium Mesh；小团队只想自动 mTLS 可以看 Linkerd。上线路径应是：先接指标和追踪 → 再超时重试 → 最后 mTLS。不要第一天就给全部命名空间开自动注入。

Istio Ambient 的安装、加网格、waypoint 和金丝雀，见下一篇：Istio Ambient 实操：先 ztunnel，再 waypoint。