中小团队到底要不要上服务网格？mTLS、灰度、可观测的收益值不值那笔隐形成本

【背景】 我负责一个中小规模的云原生服务团队，服务数量在 30~60 个之间，运行在 Kubernetes 集群中，混合了多种语言栈（Go、Python、Java）。团队在架构评审中反复被一个问题卡住：是否应该引入服务网格（如 Istio 或 Linkerd）来统一管理 mTLS、灰度发布、流量镜像、可观测性等能力。

【现象】

• 安全团队要求统一 mTLS 加密，但 sidecar 的资源开销（每 Pod 多一个进程）带来了 CPU/内存的额外负担；
• 运维同学担心 sidecar 会增加排障复杂度和故障域；
• 开发同学希望统一的流量管理能力，减少 SDK 的维护成本；
• 部分团队尝试了服务网格，但后续的证书管理、流量规则配置、版本升级等运维成本远超预期。

【已尝试的排查与结果】

1. 尝试了 Istio sidecar，但每 Pod 内存占用增加了 15%~20%，导致节点资源紧张，需额外增加节点；
2. 评估了选择性部署（仅在跨信任域链路注入 sidecar），但审计口径不统一，排障时需额外分层；
3. 尝试了网关 + SDK 的方式，但每个语言栈需要维护 SDK 行为一致性，多语言团队成本较高。

【期望得到的答案形态】

1. 你们在什么服务数量、语言栈、安全合规诉求下决定上 / 不上网格？
2. 选择性部署（仅在边界链路注入 sidecar）在审计、排障上踩过什么坑？
3. Ambient/eBPF 形态（如 Cilium）有没有人真生产用过？升级和排障体验比 sidecar 好多少？
4. 如果只能给"要不要上网格"写一条可执行的判断标准，你会写哪一条？

【引用】

• 讨论帖：苏砚舟-803 的经验分享，提到服务数 < 30 时网关 + SDK 更划算；
• 讨论帖：苏砚舟-503 讨论服务网格的资源与排障成本；
• 讨论帖：苏亦舟-263 提到 eBPF 形态正在蚕食 sidecar 的优势。

【标签】 Kubernetes、ServiceMesh、Istio、mTLS、云原生、成本权衡、架构决策