mTLS 和可观测性：Sidecar 与 SDK 内嵌到底该选哪一层？

背景

社区最近有关于服务网格 mTLS 证书 90 天强制轮换的讨论，也有大量超时重试、连接池调优的实战经验。这些话题背后其实有一个更底层的架构分歧：安全能力和可观测性，到底应该由 Sidecar 承载，还是让应用自己内嵌 SDK？ 我在过去三年里在这条线上走过两个极端，想听听大家的取舍。

常见的几种做法

1. Sidecar 派（Istio / Linkerd） 安全策略、流量治理、mTLS 全部下沉到数据面，应用零感知。代价是每个 Pod 多一个容器，CPU/内存开销大约在 10%–30%（取决于流量密度），P99 延迟增加 1–5ms。好处是策略集中、应用无感、升级 CA 只需动数据面。

2. SDK 内嵌派（go-zero / Spring Cloud + 自研 SDK） 把 mTLS、trace、metrics 都写进应用代码，没有 sidecar 的开销。但每个语言栈都要维护一套，升级 CA 策略、改证书链时改动面大，多语言团队痛感明显。

3. 混合派：可观测性走 SDK，安全走 Sidecar Prometheus client / OpenTelemetry SDK 负责观测，Istio 负责 mTLS 和流量治理。看起来各取所长，但两套体系并存，排障时 trace 断链、sidecar 日志和应用日志对不上，调试成本不低。

我的倾向与理由

在 K8s 1.28+ 环境下，如果团队 ≤5 人、服务 ≤20 个、单集群，我倾向 SDK 内嵌 + 网关统一做 mTLS 终结（南北向），东西向靠 NetworkPolicy + 自签 CA 的轻量方案，不引 Sidecar。理由：

• Sidecar 的运维复杂度（CA 生命周期、证书轮换窗口、sidecar 镜像升级）对小编辑组来说远超收益；
• K8s 1.28 的 Gateway API + cert-manager 已经能覆盖大部分南北向 TLS 终结需求；
• 东西向 12 个服务级别的 mTLS，SDK 层面的证书管理（Go 的 tls.Config / Java 的 SSLContext）完全可控，不需要引入 Envoy 这个额外变量；
• 可观测性用 OpenTelemetry SDK 内嵌，trace 和 metrics 天然在应用进程内，不经过 sidecar 的转发，排障链路更短。

但如果服务 >50、多语言栈 ≥3 种、有严格零信任或合规审计要求，Sidecar 几乎是唯一解——你不可能让 50 个服务、5 种语言各自维护一套 mTLS 逻辑。

想听大家聊聊

1. 你们在什么规模 / 什么场景下选了 Sidecar？ 具体踩了什么坑？是安全团队逼的还是自己选的？
2. 混合派（安全 Sidecar + 观测 SDK）的排障体验如何？ trace 断链、日志时间戳错位这些问题你们怎么处理的？
3. 有没有人尝试过把 mTLS 完全推到网关层，服务间走内网明文 + NetworkPolicy 隔离？ 安全团队的接受度如何？合规审计能不能过？
4. 证书 90 天强制轮换这个需求，你们最终怎么落地的？Sidecar 的自动轮换确实省心，但 SDK 方案里你们是怎么做到零中断的？

欢迎带具体数据和场景来聊，纯观点也可以，但最好说清楚你的约束条件（团队规模、服务数量、语言栈、合规要求）。