1. 服务网格概述
1.1 服务网格的定义
服务网格（Service Mesh）是云原生时代用于处理服务间通信的基础设施层。它通过将通信逻辑从业务代码中剥离，下沉为独立的代理层，实现对服务间调用的流量管理、安全策略、可观测性的统一管控。
核心思想：服务网格不关心业务逻辑，只关心“服务如何到达另一个服务”。它让开发者只需关注业务代码，而将熔断、重试、超时、负载均衡、加密认证等分布式治理能力交给网格层。
服务网格的典型架构包含两个关键组件：
| 组件 | 角色 | 部署形态 |
|---|---|---|
| 数据平面（Data Plane） | 负责实际的流量转发、策略执行 | 以 Sidecar 代理模式注入每个 Pod |
| 控制平面（Control Plane） | 负责配置下发、证书管理、服务发现 | 独立部署的集中式组件 |
1.2 发展历程
服务网格的演进经历了三个阶段：
- 第一阶段：库依赖时代（2014 年前）
开发者直接在代码中引入 Hystrix、Ribbon 等熔断/负载均衡库。缺点是语言绑定、升级困难、治理逻辑与业务代码耦合。 - 第二阶段：Sidecar 代理萌芽（2014–2016）
Netflix Prana、Buoyant 的 Linkerd 率先提出将代理独立部署。2016 年，William Morgan 正式提出“Service Mesh”术语。 - 第三阶段：Istio 与标准化（2017 至今）
Google/IBM/Lyft 联合发布 Istio，基于 Envoy 代理，将控制平面与数据平面彻底分离，成为 CNCF 毕业项目，引领服务网格走向生产化。
关键里程碑：2017 年 Istio 0.1 发布，首次引入 Pilot、Mixer、Citadel 三大控制面组件，定义了现代服务网格的控制面架构范式。
1.3 与 Kubernetes 的关系
Kubernetes 提供了容器编排与基础服务发现能力，但不解决服务间的高级通信治理问题。服务网格在 Kubernetes 之上构建了第二层网络基础设施：
- Kubernetes 提供：Pod 生命周期管理、Service 抽象、DNS 解析、基础负载均衡。
- 服务网格补充：细粒度流量路由、灰度发布、mTLS 加密、分布式追踪、故障注入、熔断降级。
两者是互补而非替代关系。Kubernetes 是服务网格的最佳运行底座，服务网格是 Kubernetes 网络能力的延伸。
| 能力维度 | Kubernetes 原生 | 服务网格（Istio） |
|---|---|---|
| 服务发现 | Service + DNS | 基于 Envoy EDS 的实时端点发现 |
| 流量路由 | 仅轮询/会话保持 | 权重、Header、URI 匹配、镜像流量 |
| 安全通信 | 需手动配置 mTLS | 自动 mTLS + 证书轮换 |
| 可观测性 | 基础 Metrics | 全链路 Tracing + 访问日志 + 拓扑 |
1.4 Istio 在服务网格中的角色
Istio 是目前生产环境最广泛采用的服务网格实现。它在服务网格生态中扮演以下核心角色：
- 控制平面标准实现者：提供 Istiod 统一组件，整合了 Pilot（服务发现与配置下发）、Citadel（证书管理）、Galley（配置验证）的能力。
- Envoy 代理的编排者：Istio 默认使用 Envoy 作为数据平面代理，通过 xDS 协议动态下发监听器、路由、集群、端点等配置。
- 多集群/多网络连接器：支持跨集群、跨网络的服务互联，提供统一的网格边界。
- 安全策略执行者：通过 AuthorizationPolicy、PeerAuthentication 等 CRD 实现零信任安全模型。
注意：Istio 并非唯一服务网格实现。Linkerd、Consul Connect、Kuma 等也是成熟方案。但 Istio 在功能丰富度、社区活跃度、企业采用率上处于领先地位，是学习服务网格的首选。
1.5 Istio 整体架构图
下图展示了 Istio 的核心架构，包含控制平面 Istiod 与数据平面 Envoy 代理的关系：
1.6 本章小结
服务网格是云原生微服务治理的关键基础设施。Istio 作为当前最成熟的服务网格实现，通过控制平面 Istiod 与数据平面 Envoy 代理的协作，为 Kubernetes 集群提供了流量管理、安全通信、可观测性三大核心能力。理解服务网格的定义、发展脉络及其与 Kubernetes 的关系，是后续深入学习 Istio 控制面架构的基础。