Sidecar 还是内嵌 SDK：服务治理与可观测性到底该外置成独立容器，还是打进应用进程？

背景： 我们团队过去两年从"各服务自己埋点 + 自研网关"逐步走向标准化。现在要重新评估服务治理（mTLS、限流熔断、链路追踪、可观测性）的落地形态，团队里明显分成两派，吵了三轮没结论，所以把争点抛出来，想听听大家怎么权衡。

常见分歧 / 几种做法：

1. Sidecar（Istio / Linkerd / OTel Collector sidecar）：零代码侵入、语言无关、策略集中下发。代价是每 pod 多一个容器 + 一次本地 loopback 跳（我们实测 gRPC 链 P99 多 0.3–0.8ms）、内存 +80–150MB/pod，升级与排障多一层。
2. 内嵌 SDK / 库（OpenTelemetry SDK、gRPC interceptor、Spring Cloud）：少一跳、延迟最低、无额外容器。代价是绑语言、升级要发版、治理逻辑散落在各仓库、策略难统一。
3. 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"，边界条件是什么？