别再闭眼上 Mesh 了：透明代理 vs Sidecar，到底谁更香？

大家好，我是 Echo_Wish。

这几年搞云原生的同学，基本都绕不开两个词：

• 透明代理（Transparent Proxy）
• Sidecar 模式

很多团队一上来就：

“上 Service Mesh 吧！可观测、限流、熔断全都有！”

然后半年后发现：

• CPU 飙升
• 延迟抖动
• 运维复杂度翻倍
• debug 像在破案

今天我们不站队，我们站工程。咱就聊清楚：

透明代理 vs Sidecar，本质差异是什么？性能、可观测、运维成本怎么权衡？

说人话版本：

• 透明代理：系统层“偷听”流量
• Sidecar：容器层“陪跑”代理

一、什么是透明代理？

透明代理的核心是：

不改业务代码，不改调用地址，流量被系统层接管

典型方式：

• iptables 重定向
• TProxy
• eBPF
• 内核层流量劫持

例如一个最简单的 iptables 透明转发：

# 将所有 80 端口流量重定向到本地 15001
iptables -t nat -A PREROUTING -p tcp --dport 80 \
    -j REDIRECT --to-port 15001

应用毫无感知。

流量已经被拦截。

优点是：

• 业务零侵入
• 部署简单
• 性能开销较低（尤其 eBPF 方案）

但问题也很明显：

• debug 难度高
• 排查路径复杂
• 行为“隐形”

二、什么是 Sidecar？

Sidecar 的思路是：

每个 Pod 多带一个代理容器

典型实现就是 Service Mesh，比如：

• Istio
• Linkerd

它的结构是：

App Container  ↔  Envoy Sidecar

流量路径变成：

App → localhost → Sidecar → 目标服务

K8s 中的典型 Sidecar 示例：

apiVersion: v1
kind: Pod
spec:
  containers:
  - name: app
    image: myapp:v1
  - name: envoy
    image: envoyproxy/envoy:v1.28
    ports:
      - containerPort: 15001

优点：

• 可观测性极强
• 流量治理能力丰富
• 支持 mTLS
• 可做精细化流量控制

缺点：

• 资源开销大
• 网络路径变长
• 每个 Pod 都“变胖”

三、性能对比：真实世界没那么浪漫

1️⃣ 网络路径长度

透明代理：

App → 内核 → 目标

Sidecar：

App → Sidecar → 内核 → 目标

多了一跳。

在高 QPS 场景下，延迟差异明显。

我曾经在一个压测环境对比过：

当然场景不同数据不同，但趋势基本一致。

2️⃣ CPU 占用

Sidecar 是实打实的进程。

假设：

• 500 个 Pod
• 每个 Sidecar 占用 100m CPU

就是：

500 * 0.1 = 50 CPU 核

这不是小数。

而透明代理（尤其 eBPF 方案）几乎无感。

四、可观测能力对比

这部分 Sidecar 完胜。

以 Envoy 为例，可以直接暴露：

• 请求级指标
• 重试次数
• 熔断状态
• mTLS 信息
• Header 级别追踪

查看指标：

curl localhost:15000/stats

透明代理就没这么“豪华”。

如果你用 eBPF，可以采集 TCP 层信息：

bpftool prog show

但：

• 你拿不到完整 L7 语义
• 解析 HTTP 需要额外逻辑

也就是说：

透明代理擅长“性能”
Sidecar 擅长“可观测”

五、运维复杂度：谁更好管？

很多人觉得 Sidecar 很标准化。

但真实情况是：

Sidecar 运维成本极高

• 升级 Mesh 控制面
• 处理版本兼容
• 证书轮转
• 配置下发延迟
• Sidecar 注入异常

例如 Istio 注入失败：

kubectl get pod -o yaml | grep sidecar.istio.io

排查一次可能一下午没了。

透明代理更接近“基础设施”：

• 规则在节点层
• 运维面集中
• 不影响 Pod spec

但问题是：

一旦规则写错，影响整节点流量。

这属于“大爆炸风险”。

六、什么时候选透明代理？

适合场景：

• 高 QPS 场景
• 性能敏感
• 只需要基础流量观测
• 团队规模不大

尤其是用 eBPF 方案（例如 Cilium），性能几乎无损。

七、什么时候选 Sidecar？

适合场景：

• 需要 mTLS
• 需要复杂流量治理
• 需要细粒度可观测
• 微服务规模巨大

大厂、金融、强合规场景，Sidecar 更安全。

八、我个人的观点

很多团队“为了先进而先进”。

一上来就上 Service Mesh。

结果是：

• 人力成本上升
• 性能下降
• 运维复杂化

我越来越觉得：

架构的优雅，不是功能多，而是合适。

如果你只是想：

• 统计延迟
• 做简单限流

真的不一定要 Sidecar。

透明代理 + eBPF + OpenTelemetry，够了。

九、一个简单对比总结

结尾

工程世界没有“银弹”。

透明代理更像：

性能工程师的朋友

Sidecar 更像：

平台工程师的朋友

你要问我怎么选？

我会反问一句：

你现在真正缺的，是性能，还是可观测？

别被技术名词带节奏。

架构不是炫技，是权衡。