1. 背景
Service Mesh 最初的使命，是解决微服务架构下的“服务间通信”难题。
通过在每个服务旁边部署一个 Sidecar 代理（例如 Envoy），Service Mesh 能统一实现：
- 服务发现
- 负载均衡
- 流量治理（灰度、A/B 测试）
- 可观测性（Tracing、Metrics、Logging）
- 安全（mTLS、策略控制）
然而，随着微服务数量增长，Sidecar 模式逐渐暴露出问题：
- 资源开销大：每个 Pod 都有一个 Sidecar，CPU/内存消耗成倍增加。
- 运维复杂：代理版本、配置更新，都会带来额外运维负担。
- 性能损耗：流量必须先过 Sidecar，再到业务容器，增加了延迟。
因此，业界开始探索 无 Sidecar（Sidecarless Service Mesh） 的新模式。
2. 什么是无 Sidecar 化 Service Mesh？
无 Sidecar 化，简单来说就是 去掉 Pod 内的代理容器，把流量治理能力放到更底层：
- eBPF 模式：利用内核可编程能力，直接在网络层实现流量控制（如 Cilium Service Mesh）。
- Node 代理模式：一个 Node 运行一个共享代理，而不是每个 Pod 一个代理。
- 内置模式：部分流量治理逻辑直接集成进应用运行时。
👉 核心目标：减少资源消耗 + 提升性能 + 简化运维。
3. 技术演进路径
3.1 eBPF 驱动的无 Sidecar 化
eBPF 可以在 Linux 内核层拦截流量，实现：
- 透明流量转发
- mTLS 加密解密
- 可观测数据采集
代表项目：Cilium Service Mesh（直接用 eBPF 替代 Envoy Sidecar）。
3.2 Node 级别代理
在每个 Node 上运行一个统一的代理，所有 Pod 的流量通过它转发。
- 减少代理数量
- 更易于集中配置管理
- 适合大规模集群
代表项目：Istio Ambient Mesh（把 Sidecar 拆分为 Node 级 ztunnel + 上层控制面）。
3.3 应用运行时集成
部分能力直接进入语言/框架运行时，比如：
- Go/Java 微服务框架内置服务发现、流量治理
- WASM 插件机制，按需加载治理逻辑
这种方式更加轻量，但需要开发者配合，破坏了 Service Mesh 的“透明性”。
4. 对比：有 Sidecar vs 无 Sidecar
| 特性 | Sidecar 模式 | 无 Sidecar 模式 |
|---|---|---|
| 部署方式 | 每 Pod 一个代理 | Node 级代理 / 内核层 |
| 性能 | 流量多一跳，延迟更高 | 延迟更低，吞吐更高 |
| 资源消耗 | 高（代理数量随 Pod 增长） | 低（集中式治理） |
| 隔离性 | 强，每个 Pod 独立 | 相对弱，共享代理 |
| 运维复杂度 | 高 | 低 |
5. 应用场景
- 高性能集群：延迟敏感的业务（金融、游戏、实时通信）。
- 大规模微服务：成千上万 Pod 的情况下，Sidecar 模式的资源开销不可接受。
- 边缘计算：轻量级计算节点，更适合无 Sidecar 模式。
6. 未来展望
无 Sidecar 化并不是要完全取代 Sidecar，而是形成一个新的选择：
- 对小规模集群：Sidecar 模式依旧简单直接。
- 对大规模分布式系统：无 Sidecar 化将逐渐成为主流。
- 长期趋势：eBPF + 无 Sidecar Mesh 可能成为云原生网络的“标配”。
7. 总结
Service Mesh 正在经历一次架构升级：
- 从 Sidecar 模式（以 Envoy 为代表）
- 向 无 Sidecar 化（eBPF、Node Proxy、Runtime 集成）演进
这场演进的目标是：
- 更低的延迟
- 更少的资源消耗
- 更简单的运维体验
未来，Service Mesh 的形态可能会与容器一样 —— 无处不在，却几乎“隐形存在”。
