Service Mesh 解决了什么问题，架构是怎样的？

结论：Service Mesh 把服务间通信的治理能力（负载均衡、熔断、加密、观测）从业务代码下沉到基础设施层，通过 Sidecar 代理透明接管流量，让业务专注业务逻辑，解决多语言栈下治理逻辑重复实现、升级难的问题。

展开：架构分两层：数据平面是随每个 Pod 注入的代理（Envoy），所有进出流量被 iptables/eBPF 劫持到代理，东西向调用在此完成 mTLS 加密、重试、熔断、流量拆分；控制平面（Istiod）负责下发配置、证书签发、服务发现。典型收益：1）全链路 mTLS 零信任加密，业务零改造；2）按权重/Header 的流量管理，金丝雀发布变得声明式；3）统一遥测，指标、日志、分布式追踪开箱即用。成本同样明显：1）每条链路多两跳代理，增加延迟（亚毫秒到毫秒级）和资源开销；2）Istio 概念复杂（VirtualService、DestinationRule、Gateway 等），运维门槛高。演进趋势：Sidecarless 方向——Istio Ambient Mesh 用节点级 ztunnel + 按需 waypoint 代理替代 Sidecar，降低资源占用和注入侵入；Cilium 基于 eBPF 在内核层做部分数据面。选型建议：中小规模、语言统一（如全 Java/Spring Cloud）的团队不必上 Mesh；多语言、强安全合规（金融）场景收益最大。