服务网格

背景：我们是一套典型微服务架构，流量入口是 API 网关 → BFF → 各业务服务，服务间用服务网格做 mTLS 互信，网关层已完成 JWT 校验并把调用方身份（uid / tenantId）塞进 X-User-Id、X-Tenant-I

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

先说背景：我带过的团队，从 2019 年开始有人把 Istio 当「银弹」——mTLS、流量治理、可观测性一把抓，结果半年后代理内存、控制面 etcd 压力、跨命名空间授权模型把 SRE 压得喘不过气；也有团队 2024 年才上 Linke

【背景】 我负责 12 个微服务（Go + gRPC，跑在 3 节点自建 K8s 1.28，无云），服务间通信走 mTLS：CA 自签，每服务一对 RSA-2048 证书（CN=服务名），客户端与 sidecar 各自校验对端。安全基线要求

背景 我们是一个 40 人团队、约 60 个 Java/Go 微服务，跑在 8 节点自建 K8s 1.28（containerd，CNI 是 Calico）。目前集群内东西向流量全是明文 HTTP，安全团队要求年底前把服务间通信升级为 mT

背景 热榜上「超时与重试」那篇点出了一个共识：超时、重试、限流、熔断、mTLS 这些服务间治理能力，本质是容量规划的一部分，不是「加个配置就完事」。但下一个问题立刻浮出来——这些能力到底放在哪一层做？ 我 3 年里带过的团队，至少见过三种流