3. 服务网格基础：Istio架构、数据平面与控制平面原理

在深入服务网格治理回滚护栏的移植适配之前，必须透彻理解 Istio 的核心架构。Istio 是当前最成熟的服务网格实现，其设计哲学将基础设施的关注点（流量管理、安全、可观测性）从业务容器中剥离，下沉为独立的系统层。本章将拆解 Istio 的两大平面：数据平面（Data Plane）与控制平面（Control Plane），并阐明它们如何协同工作。

3.1 整体架构概览

Istio 架构遵循经典的 Sidecar 代理模式。业务容器（如 Nginx、Spring Boot 应用）与 Envoy 代理容器共同部署在同一个 Pod 中。所有进出 Pod 的网络流量都被透明地劫持到 Envoy 代理上，由代理执行路由、负载均衡、熔断、遥测采集等策略。控制平面则负责统一管理所有代理的配置下发与状态收集。

3.2 数据平面：Envoy Sidecar 代理

数据平面由一组智能代理（Envoy）组成，这些代理以 Sidecar 模式部署，与每个服务实例共存。Envoy 是 Istio 数据平面的默认实现，它是一个高性能的 L4/L7 代理，由 C++ 编写，具备极低的资源消耗和极高的吞吐能力。

3.2.1 Envoy 的核心能力

3.2.2 数据平面工作流程

1. 流量劫持： Pod 启动时，Init 容器配置 iptables 规则，将所有流量重定向到 Envoy 的 15001 端口。
2. 策略执行： Envoy 根据从控制平面获取的配置（路由表、集群、监听器），对请求进行匹配和转发。
3. 遥测上报： Envoy 将请求的元数据（来源、目标、响应码、耗时）上报给控制平面或监控后端。
4. 动态更新： Envoy 通过 xDS 协议监听控制平面的配置变更，实现热更新，无需重启 Pod。

3.3 控制平面：Istiod 核心组件

控制平面负责统一管理数据平面。在 Istio 1.5 版本之后，控制平面组件（Pilot、Citadel、Galley）被合并为一个单体进程——Istiod。这种合并简化了部署和运维，但逻辑上仍然可以拆分为三个核心功能模块。

3.3.1 Istiod 三大模块

3.3.2 控制平面工作流程

1. 配置输入： 用户通过 kubectl apply 提交 Istio CRD（如 VirtualService、DestinationRule）。
2. 配置验证： Galley 模块校验 CRD 的语法和语义正确性，拒绝无效配置。
3. 配置翻译： Pilot 将高级别的 CRD 翻译为 Envoy 能理解的 xDS 协议格式（Listener、Cluster、Route）。
4. 配置下发： Pilot 通过 ADS 将配置推送到所有相关的 Envoy 代理。
5. 证书管理： Citadel 为每个服务身份签发短期证书，并通过 SDS 下发给 Envoy，用于 mTLS 通信。

3.4 控制平面与数据平面的交互：xDS 协议

xDS 是 Istio 控制平面与数据平面通信的核心协议族。Envoy 通过 xDS 接口从控制平面动态获取配置，实现无需重启的热更新。xDS 协议族包含多个子协议：

• LDS（Listener Discovery Service）： 配置 Envoy 监听哪些端口，以及如何处理入站流量。
• RDS（Route Discovery Service）： 配置路由规则，决定请求转发到哪个集群。
• CDS（Cluster Discovery Service）： 配置上游服务集群的端点列表和负载均衡策略。
• EDS（Endpoint Discovery Service）： 动态发现集群中的具体端点（Pod IP）。
• SDS（Secret Discovery Service）： 动态下发 TLS 证书和密钥。

3.5 架构设计对回滚护栏的影响

理解 Istio 的架构设计，对于设计回滚护栏方案至关重要。以下是几个关键设计点及其对回滚的影响：