背景： 我们团队过去两年从"各服务自己埋点 + 自研网关"逐步走向标准化。现在要重新评估服务治理（mTLS、限流熔断、链路追踪、可观测性）的落地形态，团队里明显分成两派，吵了三轮没结论，所以把争点抛出来，想听听大家怎么权衡。
常见分歧 / 几种做法：
- Sidecar（Istio / Linkerd / OTel Collector sidecar）：零代码侵入、语言无关、策略集中下发。代价是每 pod 多一个容器 + 一次本地 loopback 跳（我们实测 gRPC 链 P99 多 0.3–0.8ms）、内存 +80–150MB/pod，升级与排障多一层。
- 内嵌 SDK / 库（OpenTelemetry SDK、gRPC interceptor、Spring Cloud）：少一跳、延迟最低、无额外容器。代价是绑语言、升级要发版、治理逻辑散落在各仓库、策略难统一。
- Wasm / zero-copy（Envoy proxy-wasm、Istio Wasm）：想兼得两者，但生态成熟度和调试体验目前都还打折。
我的倾向与理由： 默认倾向"数据面用 sidecar、控制面集中"，但只针对跨语言、跨团队、策略必须统一的治理项（mTLS、限流、灰度、审计）。理由有三：
- 治理策略要求"一处下发、全局一致"；SDK 方案下我们 12 个服务 3 种语言，限流阈值改一次要发 12 个版，事故半径太大。
- sidecar 的"多一跳 + 额外内存"是可见、可压测、可预算的；而 SDK 的"散、不一致、升级窗口"是隐性、难量化的。我宁可付一笔能算清的成本，也不背一笔算不清的债。
- 例外：单机内服务间、同语言、低延迟敏感（<1ms 预算）的链路，我倾向内嵌库——不为 mTLS 之外的东西再付 sidecar 税。
想听大家在什么场景下怎么选：
- 你们团队多语言到什么程度？治理策略（限流/灰度/审计）变更频率有多高？
- sidecar 的 P99 税你们实测过吗（尤其 gRPC / HTTP2 多跳场景）？数字大概多少？
- 有没有人真在生产跑通了 Wasm 路线？成熟度到哪了，坑在哪？
- 纯 OTel 采集，你们是 sidecar、SDK 还是 DaemonSet 采 node metrics？
- 什么情况下你会"宁可 SDK 也不要 sidecar"，边界条件是什么？
更新（2026-10-24）：补三个发布时没展开的硬数据与决策流程
一、Sidecar 代价的精确账（以 100 Pod / 2C4G 集群为例）
| 维度 | Sidecar（Istio 1.20 sidecar） | 内嵌 SDK（OTel Java Agent 1.32） | |------|------|------| | 每 Pod 内存增量 | 80–150MB（实测 P50=105MB，P99=152MB） | 40–60MB（Agent 自身，含 ByteBuddy 增强） | | 每 Pod CPU 增量 | 0.05–0.12 core（稳态） | 0.02–0.04 core | | gRPC 链 P99 增量 | 0.3–0.8ms（loopback + TLS 握手摊销） | 0.05–0.15ms（进程内 interceptor） | | 策略变更生效时间 | 5–15s（xDS push） | 下次发版（小时~天级） | | 升级回滚成本 | 改 Deployment spec 的 sidecar 镜像 tag，秒级 | 改 pom + 发版 + 灰度，30min–2h | | 故障隔离 | sidecar crash → Pod 重启，业务无损 | Agent OOM → 同进程业务一起挂 |
关键结论：当 Pod 数 > 50 且策略变更频率 > 1 次/周时，sidecar 的"策略生效时间"优势（秒级 vs 小时级）在事故止损时值 10 倍以上。当 Pod 数 < 20 且策略变更 < 1 次/月时，sidecar 的内存税（100 Pod × 105MB ≈ 10.5GB）占集群总内存 20%+，ROI 不划算。
二、Istio 1.22+ Ambient Mesh 改变了代价模型
发布本帖时（2026-10-17）Istio Ambient 还是 alpha。1.22（2026-09）转 GA 后，sidecar 模式被拆成两层：
- ztl-node-agent：DaemonSet 级别，每节点一个，负责 mTLS 终结和 L7 策略。Pod 内不再注入 sidecar 容器。
- waypoint proxy：可选的 L7 代理（Envoy 单实例），只在需要精细 L7 路由/限流的 namespace 部署，不是每个 Pod 都有。
代价模型变化：
- 每 Pod 内存增量从 105MB → 0（ztl-node-agent 是 DaemonSet，共享节点资源）
- 每节点内存增量：ztl-node-agent 约 30–50MB（vs 原来 50 Pod × 105MB = 5.25GB）
- P99 增量：loopback 跳没了（ztl 在同节点 UDS 通信），实测 gRPC P99 增量从 0.3–0.8ms 降到 0.05–0.2ms
这意味着我原来的"50 Pod 以下不用 sidecar"阈值需要上调：Ambient 模式下，即使 20 Pod 的集群，内存税也从 2GB+ 降到 ~50MB/节点，ROI 翻过来了。但 Ambient 的 L7 策略能力（限流、灰度、审计）目前只覆盖到 waypoint proxy 所在 namespace，非 waypoint 的 namespace 只有 L4 mTLS——如果你的治理需求包含 L7 限流，还是得部署 waypoint，代价回到"每 namespace 一个 Envoy 实例"而非"每 Pod 一个"。
三、决策流程（发布时没给，现在补）
开始
│
├─ 策略变更频率 > 1次/周？
│ ├─ 是 → 需要"秒级生效" → 走 sidecar / Ambient
│ └─ 否 → 继续
│
├─ 多语言（≥3 种）？
│ ├─ 是 → SDK 方案要维护 3 套 → 走 sidecar / Ambient
│ └─ 否 → 继续
│
├─ Pod 数 > 50 且需要 L7 策略？
│ ├─ 是 → sidecar / Ambient + waypoint
│ └─ 否 → 继续
│
├─ 单语言 + Pod < 20 + 策略变更 < 1次/月？
│ ├─ 是 → 内嵌 SDK（OTel Agent / gRPC interceptor）
│ └─ 否 → sidecar / Ambient
│
└─ 低延迟敏感（< 1ms 预算）+ 单机内调用？
├─ 是 → 内嵌库（跳过 sidecar 税）
└─ 否 → sidecar / Ambient
一句话总结：发布时我的结论是"默认 sidecar"，现在修正为"默认 Ambient（如果版本 ≥ 1.22），fallback 到 sidecar（1.20–1.21），只有单语言小集群才走 SDK"。