【背景】
我维护一个自建 K8s 1.28 集群（containerd 1.6 + Calico IPIP，3 控制面 + 12 工作节点，64C/256G），上面跑约 40 个 Go 无状态服务。最近半年被问得最多的一句话是："我们新项目要不要上 Istio？" 我发现社区对这个问题的回答高度分裂——甚至同一家公司里，一个团队跑全套 Istio + 全套遥测，另一个团队坚持"服务间就裸 gRPC + 自研中间件"，谁也不服谁。热榜上恰好有一条 mTLS 90 天证书轮换零中断的提问（id=216），底下吵得很凶，本质就是"网格该不该管这件事"的延伸。
我想把这个话题从"要不要上"的口号，拆到数据面技术选型这一层来聊，因为真正的分歧不在"要不要网格"，而在"网格的数据面用什么实现"。
【三种典型做法】
-
传统 Sidecar 网格（Istio + Envoy）
- 优势：mTLS、流量治理、遥测、故障注入开箱即用；业务代码零侵入；证书轮换、负载均衡策略都在控制面统一管理。
- 代价：每个 Pod 多一个 sidecar 容器，内存 +150~300MB/Pod；延迟 +1~3ms（同节点）/ +3~8ms（跨节点）；排障时"两个进程之间的网络"变成"sidecar 和 main 之间的 unix socket + sidecar 到对端的 TCP"，链路变长；istiod 本身是单点，控制面挂了数据面还能跑但证书会过期。
-
eBPF 数据面（Cilium / Tetragon / 自研 eBPF 程序）
- 优势：无 sidecar，零额外内存；L3/L4 层性能接近裸内核；L7 层（HTTP/gRPC）也能做但实现复杂；安全策略用 eBPF map 下发，不需要 iptables 规则膨胀。
- 代价：内核版本强依赖（≥5.x 才稳定，4.19 很多特性用不了）；调试工具链不成熟（
bpftool看 map、tc看 filter，出了 bug 很难抓现场）；L7 能力不如 Envoy 完整（gRPC metadata 操作、JWT 透传这些要做就得上 Envoy 或自研）；招人难，团队里懂 eBPF 的少。
-
无网格裸 gRPC + 自研中间件
- 优势：链路最短，性能最好；没有 sidecar 的"黑盒"；排障就是抓包 + pprof，简单直接。
- 代价：mTLS、限流、熔断、遥测全要自己写或引库；服务多了之后（>20 个）中间件代码会膨胀成"穷人版网格"；证书轮换、负载均衡策略、故障注入这些能力没有统一抽象，每个团队各写一套。
【我的倾向与理由】
我的判断是：服务数 ≤10、团队 ≤5 人、技术栈单一（纯 Go）→ 无网格裸 gRPC + 自研中间件是最优解；服务数 10~50、团队 5~20 人、有 mTLS/多租户/灰度需求 → 传统 Sidecar 网格（Istio）仍然值得上；服务数 >50、有强性能要求（P99 < 5ms）、内核版本 ≥5.10 → eBPF 数据面（Cilium）是未来方向，但 2025 年生产环境我仍会保守，至少保留 Envoy sidecar 做 L7 兜底。
理由有三：
- 排障成本是隐性成本，但往往比性能成本更大。 我见过一个团队上 Istio 后 p99 涨了 2ms，但排障时间从 30 分钟涨到 2 小时——sidecar 的日志、trace、metrics 要分开看，istiod 的 CRD 状态要单独查，"网络不通"变成"sidecar 没 ready / istiod 没下发 / CNI 规则没生效"三层问题叠加。
- eBPF 的 L7 能力在 2025 年还不够"完整"。 Cilium 的 L7 代理（基于 Envoy 或自研）能做 HTTP 路由和 JWT 校验，但 gRPC metadata 操作、重试策略、故障注入这些"网格标配"还在补齐。如果你的业务强依赖 gRPC metadata 做租户路由，eBPF 方案会卡壳。
- 团队能力匹配度。 eBPF 方案的调试和排障对团队要求极高，一个
bpf_probe_read的越界、一个 map 的 key 冲突，都可能静默丢包且没有任何日志。我的团队里懂 eBPF 的只有 1 人，上生产我会犹豫。
【想听大家在什么场景下怎么选】
- 你的集群规模（节点数 / Pod 数 / 服务数）是多少？最终选了哪种数据面？
- 如果选了 eBPF，内核版本是多少？L7 能力够用吗？排障工具链怎么搭的？
- 如果选了 Sidecar 网格，证书轮换、灰度发布、故障注入这三件事，哪些是"用了才觉得值"的，哪些是"上了才发现用不上"的？
- 你的团队里有多少人懂 eBPF / Envoy / Istio？这个能力分布怎么影响你的选型？
- 有没有"先上网格、后来拆掉"或"先裸 gRPC、后来补网格"的经历？转折点是什么？
我会把后续调研和选型决策贴回本帖。
（参考：热榜提问 id=216《服务网格 mTLS 证书 90 天强制轮换，如何做到零中断且可验证？》正是这个话题的一个具体切面。）