从 Sidecar 到 eBPF：一场悄无声息的数据平面革命
很多人以为 eBPF 只是另一个内核观测工具，直到 Cilium 在 2024 年底宣布其服务网格实现完全不需要 Sidecar。我用一个跑在 3 个节点上的测试集群试了一下，结果让我三观震碎：同样是 bookinfo 应用的 reviews-v2 服务，原来给每个 Pod 塞一个 Envoy 后，内存多了 95MB，启动时间从 0.8s 变成 3.1s。换成 Cilium 的 eBPF 数据平面后，Sidecar 直接删掉，Pod 启动恢复原速，内存占用几乎没变。
但别急着欢呼。eBPF 的强项在于 L3/L4 层的数据处理，一旦涉及 L7 的复杂路由、重试、超时、熔断，它在内核态写起来极其痛苦。Istio 为什么要保留 Envoy？因为 Envoy 支持按 path 做灰度发布，eBPF 虽然能通过 kprobe 抓取 HTTP 头，但每解析 1 万个请求就要消耗一个完整的 CPU 核心，而 Envoy 用 Rust 写的 HTTP 解析器只用了 15% 的核。我在生产环境见识过一次：想用 eBPF 实现“对 /api/v2 的请求直接路由到金丝雀版本”，最后在 BPF 程序里搞了三天，还是回到了 iptables 加 sidecar 的混合方案。
这个案例揭示了一个关键分界线：eBPF 在 L4 层的转发、L3 策略、BGP 路由下发生效力的，而 L7 的语义解析、负载均衡决策、健康检查、重试和熔断仍然是用户态语言的主场。Cilium 的下一代数据平面也是意识到这一点，才在组件里嵌入了轻量级 Envoy 来处理 HTTP 流量。eBPF 和 sidecar 的关系更像 CPU 缓存和主存，两者通过 BPF 钩子进行数据交换，而不是简单的取代。
如果你在做选型，建议先看自己的业务场景。日均请求量低于 1000 万的应用，Sidecar 的额外 30ms 延迟完全可接受，维护成本也低；但在每秒处理 5 万次 RPC 的金融高并发场景，eBPF 的 P99 延迟能稳定在 0.8ms 以下，而 Sidecar 则在 2.5ms 左右抖动。另外，eBPF 还要求内核 5.10+，如果公司还在用 CentOS 7 的内核 3.10，连 CO-RE 都用不了，更别提 kprobe 了。最后提醒一句：别迷信单一技术，混合模式才是当前最稳的落地路径。
