1. 服务网格基础概念
1.1 什么是服务网格
服务网格（Service Mesh）是云原生架构中用于处理服务间通信的基础设施层。它将原本嵌入在应用代码中的流量管理、服务发现、负载均衡、熔断、重试、可观测性等能力抽离出来，下沉到独立的代理进程中，使开发者可以专注于业务逻辑。
核心思想：将网络通信的复杂性从应用容器中剥离，交给 Sidecar 代理统一处理。
服务网格通常由两个平面组成：
| 平面 | 职责 | 典型组件 |
|---|---|---|
| 数据平面（Data Plane） | 拦截并处理所有进出服务的网络流量，执行路由、负载均衡、健康检查、TLS 终止、指标采集等 | Envoy、Linkerd-proxy、MOSN |
| 控制平面（Control Plane） | 下发配置、管理证书、聚合遥测数据、提供 API 供运维人员声明式管理网格行为 | Istiod（Istio）、Conduit-controller、Kuma CP |
1.2 Sidecar 代理模式
Sidecar 是服务网格的部署单元。每个服务实例旁边都会部署一个独立的代理容器（Sidecar），该代理拦截该实例的所有入站和出站流量。
关键特征：Sidecar 与业务容器共享同一个 Pod（Kubernetes 场景），共享网络命名空间，但进程隔离。业务容器完全感知不到 Sidecar 的存在。
Sidecar 代理模式带来的优势：
- 零侵入：无需修改业务代码即可获得流量管理、安全、可观测能力。
- 统一治理：所有流量策略在 Sidecar 层集中配置，避免各语言 SDK 碎片化。
- 故障隔离：Sidecar 崩溃不影响业务进程，业务进程崩溃 Sidecar 仍可上报指标。
- 渐进式采纳：可以按命名空间、工作负载粒度逐步接入网格。
1.3 Istio 与 Envoy 的关系
在服务网格生态中，Istio 和 Envoy 是最具代表性的组合。两者分工明确：
| 组件 | 角色 | 所属平面 | 核心职责 |
|---|---|---|---|
| Envoy | 高性能数据平面代理 | 数据平面 | 流量拦截、L4/L7 路由、负载均衡、TLS 终止、熔断、重试、指标与日志生成 |
| Istiod | 统一控制平面组件 | 控制平面 | 将 Pilot、Citadel、Galley 整合为一个进程；下发 xDS 配置、管理证书、验证策略 |
| Istioctl / K8s CRD | 运维接口 | 控制平面（用户侧） | 声明式定义 VirtualService、DestinationRule、PeerAuthentication 等资源 |
Istio 与 Envoy 的协作流程：
- 运维人员通过
kubectl apply创建 Istio CRD 资源（如 VirtualService）。 - Istiod 监听 API Server，将 CRD 转换为 Envoy 可理解的 xDS 协议配置（LDS、RDS、CDS、EDS 等）。
- Istiod 通过 gRPC 流式推送 xDS 配置给每个 Pod 中的 Envoy Sidecar。
- Envoy 根据最新配置动态更新路由、监听器、集群，无需重启。
- Envoy 实时采集流量指标、访问日志、链路追踪数据，上报给 Prometheus / 日志系统 / Jaeger。
常见误解：Istio 不是 Envoy 的替代品，而是 Envoy 的编排者。Envoy 本身是一个独立的代理，Istio 利用 Envoy 的 xDS API 对其进行集中管理。没有 Istio，Envoy 依然可以独立运行（如作为边缘代理）；没有 Envoy，Istio 的数据平面能力将不复存在。
1.4 为什么选择 Envoy 作为 Istio 的数据平面
Envoy 并非 Istio 唯一可选的数据平面代理，但它是 Istio 的默认且最成熟的实现。Envoy 被选中的关键原因：
- 原生 xDS 支持：Envoy 是 xDS 协议的发明者和最早实现者，Istiod 可以直接使用标准 xDS API 进行配置下发。
- 高性能 C++ 实现：相比纯 Go 或 Java 代理，Envoy 在吞吐量和延迟方面表现更优，适合大规模生产环境。
- 丰富的 L7 过滤链：Envoy 内置 HTTP/1.1、HTTP/2、gRPC、TCP、MongoDB、Redis 等多种协议解析器，无需额外插件。
- 可观测性原生集成：Envoy 原生生成结构化访问日志、分布式追踪（Zipkin/Jaeger）、Prometheus 指标，无需 sidecar 额外采集器。
- 热重载与动态配置：Envoy 支持通过 xDS 动态更新监听器、路由、集群，无需重启进程，适合频繁变更的微服务环境。