1. 服务网格概述
1.1 服务网格定义
服务网格（Service Mesh）是云原生时代用于处理服务间通信的基础设施层。它通过将通信逻辑从业务代码中剥离，下沉为独立的代理层，实现对微服务间流量的统一管控。最经典的实现模式是 Sidecar 代理——每个服务实例旁挂一个代理（如 Envoy），所有进出流量都经过该代理，从而在不修改业务代码的前提下获得可观测性、安全加密与流量治理能力。
核心思想：将网络通信的复杂性从应用容器中移出，交给基础设施层统一处理。
1.2 服务网格核心价值
服务网格的三大核心价值构成其技术底座，也是与传统微服务架构的关键差异所在。
| 核心价值 | 能力描述 | 典型场景 |
|---|---|---|
| 可观测性 | 自动采集服务间调用的指标、日志与链路追踪，无需业务埋点 | 调用链分析、黄金信号监控、故障根因定位 |
| 安全 | 提供 mTLS 双向认证、细粒度访问控制、证书自动轮换 | 零信任网络、跨命名空间鉴权、敏感服务隔离 |
| 流量管理 | 支持灰度发布、蓝绿部署、熔断、重试、超时、限流等策略 | 金丝雀发布、A/B 测试、故障注入演练 |
1.3 与传统微服务架构对比
传统微服务架构中，每个服务都需要自行集成服务发现、负载均衡、熔断、认证等 SDK，导致业务代码与基础设施逻辑高度耦合。服务网格通过 Sidecar 代理将这部分能力完全剥离，形成以下关键差异：
| 对比维度 | 传统微服务架构 | 服务网格架构 |
|---|---|---|
| 通信治理 | 嵌入 SDK（如 Hystrix、Ribbon），升级 SDK 需重新发布 | Sidecar 代理统一管控，策略热更新，业务无感 |
| 可观测性 | 手动埋点，代码侵入性强，维护成本高 | 自动拦截流量，零侵入采集指标、日志与链路 |
| 安全策略 | 依赖应用层实现，证书管理分散 | mTLS 自动加密，证书统一签发与轮换 |
| 多语言支持 | 每种语言需独立实现 SDK，生态碎片化 | 代理层语言无关，统一治理所有服务 |
| 运维复杂度 | SDK 版本管理、配置同步、灰度升级困难 | 控制面统一管理，数据面独立升级，运维标准化 |
| 资源开销 | SDK 内嵌，无额外代理开销 | 每个 Pod 额外运行 Sidecar 代理，增加少量 CPU/内存 |
选型提示：服务网格并非银弹。对于服务数量少于 10 个、技术栈单一、无复杂流量治理需求的团队，传统 SDK 方案可能更轻量。服务网格在 20+ 微服务、多语言异构、需要精细化流量管理的场景下优势显著。
1.4 服务网格的典型分层结构
服务网格通常分为 数据面（Data Plane） 和 控制面（Control Plane） 两层：
- 数据面：由一组 Sidecar 代理组成（如 Envoy），负责处理服务间所有网络流量，执行路由、负载均衡、健康检查、认证、可观测性数据采集等任务。
- 控制面：负责管理和配置数据面的代理，下发路由规则、安全策略、监控配置，并收集代理上报的遥测数据。典型实现包括 Istio 的 Istiod、Consul Connect 等。
常见误区：服务网格不等于 Istio。Istio 是服务网格的一种控制面实现，Envoy 是数据面代理。市场上还有 Linkerd（基于 Rust 代理）、Consul Connect、Kuma 等不同技术栈的网格方案。本课程聚焦 Istio + Envoy 这一最主流的组合。