服务网格

Sidecar 模式

服务网格的核心思想是 Sidecar 模式：在每个服务 Pod 旁边运行一个代理进程（通常是 Envoy），所有进出服务的流量都经过这个代理。代理组成「数据平面」，负责实际的流量转发；集中的控制组件组成「控制平面」，把策略下发给所有代理。

这个设计最大的好处是语言无关——不管服务是用 Java、Go 还是 Python 写的，Sidecar 代理都能提供统一的 mTLS 加密、熔断、重试、全链路追踪，不需要各语言 SDK 各自实现。[1]

Istio 的复杂度争议

Istio 在 2017 年由 Google、IBM、Lyft 联合发布，功能强大但以复杂著称。早期版本需要部署 Mixer、Citadel、Pilot、Galley 等多个组件，运维复杂度极高。2021 年发布的 1.10 版本后架构大幅简化，但仍是 Kubernetes 上学习曲线最陡的组件之一。

为此出现了更轻量的替代品：Linkerd（CNCF 毕业项目，Rust 写的 Sidecar 代理，内存占用远低于 Envoy）、Cilium（基于 eBPF，绕过 Sidecar 直接在内核层做流量控制，性能更好）。2022 年后，「无 Sidecar 服务网格」成为新的趋势方向。