服务网格不是”比 Nginx 更酷的反向代理”，它是把服务到服务通信从应用代码中抽离出来的基础设施层。这个抽象的代价是 sidecar 的运维复杂度，收益是统一治理。
核心问题
微服务架构中，服务 A 调用服务 B 时，应用开发者通常需要处理：
- 服务发现（B 的实例在哪里？）
- 负载均衡（打到哪个实例？）
- 重试与超时（失败怎么办？）
- 熔断（B 挂了怎么保护 A？）
- TLS（传输加密）
- 认证授权（谁可以调用 B？）
- 可观测性（调用链、指标、追踪）
这些 concerns 的本质是通信策略，不是业务逻辑。服务网格的赌注是：把它们统一交给一个专用基础设施层，比在每个服务里重复实现更可靠、更易治理。
Sidecar 模式：Envoy 的经典实现
Envoy 作为独立进程（sidecar）运行在每个应用 Pod 旁边，所有进出流量都经过它：
[App Container] ←→ [Envoy Sidecar] ←→ [Network]
所有 sidecar 共同构成一个透明通信网格：应用只与 localhost 通信，对网络拓扑、负载均衡策略、安全策略一无所知。
这个设计的三项核心收益：
- 语言无关：Java、Go、Python、Node.js 服务共享同一套通信基础设施
- 独立升级：通信策略的更新不需要协调各服务的发布节奏
- 统一治理：认证、授权、审计、限流在单一控制面管理
代价同样明显：每个 Pod 多一个容器（资源开销）、更复杂的调试链路（问题可能出现在 app 或 sidecar）、网络路径多一跳（延迟）。
从 Sidecar 到 Ambient Mesh
Istio 社区正在推动 ambient mesh（无 sidecar）模式，把网格功能拆成两层：
- Ztunnel：每个节点的轻量级 L4 代理，处理 mTLS 和流量捕获
- Waypoint proxy：按身份部署的 L7 代理，处理策略、可观测性
目标是保留统一治理的同时，降低 sidecar 的资源和管理成本。这个方向反映了社区对 sidecar 模式的反思：统一通信策略的价值毋庸置疑，但 sidecar 不一定是唯一实现方式。
控制面与数据面
服务网格通常分为两层：
- 数据面（Data Plane）：Envoy sidecar 本身，负责实际转发流量、执行策略
- 控制面（Control Plane）：Istiod 等组件，通过 xDS API（ADS/CDS/EDS/LDS/RDS/SDS）向数据面下发配置
控制面的关键能力是动态配置：当新服务注册、路由规则变更、安全策略更新时，控制面通过 xDS 推送到所有 sidecar，无需重启。
什么时候需要服务网格
服务网格不是微服务的默认选项。我会按以下顺序评估：
- 你是否已经在为每个服务重复实现通信 concerns？如果只是 3-5 个服务的简单系统，直接复用云厂商的负载均衡器可能更简单。
- 你的多语言服务是否需要统一的 mTLS 和认证？这是 sidecar 模式最不可替代的场景——你无法要求 Java 和 Node.js 团队用同一套库实现 SPIFFE/SPIRE。
- 你是否需要细粒度的流量管理？金丝雀发布、A/B 测试、故障注入在网格中可以做到请求级路由，而传统 ingress 通常只能做到服务级。
- 团队是否有能力运维 sidecar 生态？sidecar 的升级、排障、性能调优需要专门的知识储备。
与服务发现的关系
服务网格不替代服务发现，而是增强它。传统的 DNS 或 Consul 告诉你”实例在哪里”，网格在此基础上增加了：
- 实例的健康状态（主动健康检查 + 被动异常检测）
- 路由规则（按 header、权重、版本分流）
- 安全策略（mTLS、RBAC）
Envoy 把服务发现视为最终一致的过程，不假设发现系统返回的列表 100% 准确，而是通过健康检查和异常检测自己做二次确认。
实践原则
- 服务网格的 ROI 与服务数量和语言异构度正相关。10 个服务、3 种语言的组织可能比 50 个服务、1 种语言的组织更适合网格。
- 不要把网格当作”免费获得的可观测性”。虽然 sidecar 天然能收集指标和追踪，但有意义的服务图需要业务语义标注，这不是自动的。
- 关注 ambient mesh 的演进。如果你正在评估服务网格但担心 sidecar 成本，可以先在 L4 层（ztunnel）起步，按需升级到 L7（waypoint）。
相关页面：load-balancing-strategies · progressive-delivery · envoy