服务网格到底该不该在生产上全面铺开？Istio 的三秒 vs 你的 P99

先说背景：我带过的团队，从 2019 年开始有人把 Istio 当「银弹」——mTLS、流量治理、可观测性一把抓，结果半年后代理内存、控制面 etcd 压力、跨命名空间授权模型把 SRE 压得喘不过气；也有团队 2024 年才上 Linkerd 2.15+，跑得很顺，但功能边界比 Istio 窄很多。2026 年了，mesh 生态明显成熟了一截，但「要不要全量上」这个问题，我见过的分歧反而更大了。

常见分歧（至少四种做法）：

1. 「全量上」派：所有 sidecar 统一走 mesh，业务代码不再自己写重试/超时/熔断，治理左移到基础设施层。优点是策略一致、可审计；代价是代理内存（典型每 pod 多 80~200MB）、控制面单点、跨集群/跨命名空间配置复杂度指数上升。
2. 「按需上」派：只有强安全诉求（东西向 mTLS）或强治理诉求（灰度/金丝雀）的服务进 mesh，其余走原生 Service + 自研 SDK。灵活，但策略分裂，新人心智负担重。
3. 「ambient / ztunnel」派：等 Istio ambient 或 Linkerd 的 daemonset 模式稳定后再上，避免 sidecar 模型本身的成本。我们内部 2025 年试点过 ambient，跨 namespace mTLS 已经可用，但故障注入和高级路由还没完全对齐 sidecar 模式。
4. 「不上」派：K8s 原生 + 服务框架（Spring Cloud / gRPC 拦截器）够用，mesh 是过度设计。小团队我认同，但 50+ 服务、多团队共建时，SDK 一致性会先崩。

我的倾向（先给结论）：

• 默认不上，除非你同时满足：东西向 mTLS 是硬要求、服务数 ≥30、有专门的 platform 团队 own 控制面。
• 满足条件后，先 ambient 后 sidecar（如果版本允许）；ambient 的故障注入能力补齐前，关键链路灰度用原生 Ingress Gateway / 自研网关做。
• 不要把 mesh 当「免费的重试/熔断」用——代理层的重试会放大雪崩，业务层的幂等和限流不能省。这条我见过两次事故。
• 控制面资源要给足：istiod 至少 4C8G 起步，etcd 独立部署、独立监控，别和 K8s 主 etcd 混用。

想听大家聊的：

1. 你们生产上 mesh 的实际覆盖率是多少？全量 / 50% / 只上核心链路？
2. ambient vs sidecar 你们怎么选？踩过什么坑？
3. 代理内存 / CPU 开销在你们环境里大概什么量级？有没有压测数据可以分享？
4. 你们有没有把「业务层重试/限流」和「mesh 层重试/限流」做过明确分工？怎么划的？
5. 控制面高可用你们怎么做？istiod HA、etcd 独立、跨 AZ 这些有没有实战经验？

不追求标准答案，想收集不同规模团队（<10 服务 / 30~100 / 500+）的真实取舍和数字。