Service Mesh：何时真的需要

Service Mesh 是什么

把"服务间通信"的能力从应用代码里抽出来，放到一个和应用并跑的 sidecar 代理里：

[ Pod                                ]
  ┌──────────┐         ┌──────────┐
  │ App 容器 │←──────→│ Sidecar  │←─→ 出 Pod 网络
  └──────────┘         │ (Envoy)  │
                       └──────────┘

应用以为在打 localhost:8080——sidecar 拦截、加密、路由、重试、观测。

它解决什么

能力	没 Mesh 时怎么办
mTLS：服务间自动加密	每个应用自己实现 / Nginx 配
流量管理：金丝雀 / 蓝绿 / 镜像	自己在 LB / 应用代码里写
可观测：自动 metrics / traces	应用埋点 + SDK
断路 / 重试 / 限流	应用代码里加（Hystrix / Resilience4j 等）
零信任 / 授权策略	自己实现

如果你所有服务都在 K8s 里 + 跨服务调用密集 + 多语言栈——Mesh 帮你统一这些能力，不用每个语言都写一份。

主流实现

Mesh	代理	复杂度	备注
Istio	Envoy	高	功能最全，2022 起捐给 CNCF
Linkerd	自研 Rust（micro-proxy）	中	性能好、更易上手
Consul Connect	Envoy	中	HashiCorp 出品，支持多 K8s + VM
Cilium Service Mesh	eBPF（无 sidecar）	中	用内核 eBPF 替代 sidecar，新方向
AWS App Mesh / Istio on EKS	Envoy	中	云托管版本

⚠ 不要轻易引入 Mesh 的原因

复杂度爆炸：每个 Pod 多一个容器；调试时多一层；新手心智成本大
资源开销：sidecar 吃 CPU 和内存（每 Pod 一份）
延迟增加：每个调用走两次代理（出方 + 入方）
故障面变大：sidecar 自身可能挂、配置可能错，影响所有服务
学习陡峭：Istio CRD 几十个，团队培训成本高

何时真的需要

微服务数量 数十到数百+（不是 5 个）
跨多语言栈，统一在应用层做太重复
严格 zero-trust / 合规要求 mTLS
已经有平台团队能持续维护 Mesh

何时不需要

单体或几个服务
全 Java / 全 Go 等单语言栈，能用语言层方案（Spring Cloud / go-kit）
团队规模 < 50 人，运维能力跟不上

替代或更轻量方案

需求	不上 Mesh 也能做
API 入口路由	API Gateway（Kong / Traefik / cloud-native）
服务发现	K8s Service / Consul
重试 / 熔断	应用层库（Polly / Resilience4j）
Traces	OpenTelemetry SDK 自己埋
mTLS	cert-manager + 应用代码

先看自己缺什么——单点解决比上 Mesh 简单 10 倍。

eBPF Mesh：未来？

Cilium 用 eBPF 在内核层做 mesh，不需要 sidecar——少一层 Pod 容器、少一份延迟。社区在快速演进。如果你正在选型，可以纳入考虑，但生产成熟度还需要时间观察。