1. 服务网格基础
1.1 服务网格定义
服务网格（Service Mesh）是云原生时代用于处理服务间通信的基础设施层。它通过将通信逻辑从应用代码中剥离，下沉为独立的代理层，实现对微服务间流量、安全、可观测性的统一管控。其核心价值在于：开发者只需关注业务逻辑，网络通信的可靠性、安全性和可观测性由网格层透明提供。
关键特征：
- 透明代理：应用无感知，通信由 Sidecar 代理接管。
- 策略驱动：流量路由、访问控制、熔断限流等策略集中配置。
- 可观测性：自动生成延迟、错误率、链路追踪等遥测数据。
- 安全通信：mTLS 加密、证书轮换、身份认证内建支持。
1.2 Istio / Envoy 架构
Istio 是目前最主流的服务网格实现，其架构分为数据平面与控制平面。数据平面由 Envoy 代理组成，控制平面则负责策略下发与配置管理。
| 组件 | 角色 | 核心功能 |
|---|---|---|
| Envoy Proxy | 数据平面代理 | 拦截所有进出 Pod 的流量，执行路由、负载均衡、健康检查、指标采集。 |
| Pilot (istiod) | 控制平面核心 | 服务发现、流量管理规则下发、Envoy xDS 配置推送。 |
| Mixer (已弃用) | 策略与遥测 | Istio 1.5 后功能并入 Envoy 和 istiod，不再独立部署。 |
| Citadel (已并入 istiod) | 安全控制 | 证书签发、mTLS 密钥管理、身份认证。 |
| Galley (已并入 istiod) | 配置验证 | 校验 Istio 配置合法性，转换为内部模型。 |
架构演进说明： Istio 1.5 之后将 Pilot、Citadel、Galley 合并为单一的 istiod 组件，简化了部署与运维复杂度。Envoy 作为数据平面代理始终保持独立。
1.3 Sidecar 代理模式
Sidecar 模式是服务网格的核心部署形态：在每个微服务 Pod 中，额外注入一个 Envoy 代理容器，与业务容器共享网络命名空间。所有进出 Pod 的流量都被 iptables 规则透明地劫持到 Envoy 端口，实现无侵入式流量管控。
性能考量： Sidecar 代理会引入额外的网络跳数（通常增加 1-5ms 延迟），且消耗 CPU/内存资源。在生产环境中，Envoy 的线程模型、连接池大小、超时配置直接影响 API 延迟，是延迟诊断的重点关注对象。
Sidecar 代理工作流程
- 流量劫持：Pod 启动时，istio-init 容器配置 iptables 规则，将入站（Inbound）和出站（Outbound）流量重定向到 Envoy 的 15001/15006 端口。
- 策略执行：Envoy 根据从 istiod 获取的 xDS 配置（路由、集群、监听器、端点），执行负载均衡、熔断、重试、超时等策略。
- 遥测采集：Envoy 自动生成 TCP/HTTP 级别的指标（请求数、延迟分布、错误码），并上报链路追踪数据。
- 安全握手：若启用 mTLS，Envoy 在建立连接时与对端 Envoy 完成双向证书验证和加密协商。
1.4 数据平面与控制平面
服务网格的两层架构是其设计精髓：数据平面负责处理实际流量，控制平面负责管理数据平面的行为。两者通过标准化的 xDS 协议（Discovery Service APIs）进行配置同步。
| 维度 | 数据平面 (Data Plane) | 控制平面 (Control Plane) |
|---|---|---|
| 核心组件 | Envoy Proxy（每个 Pod 一个 Sidecar） | istiod（Pilot + Citadel + Galley） |
| 主要职责 | 流量转发、负载均衡、健康检查、指标采集、mTLS 加解密 | 服务发现、策略下发、证书管理、配置校验、API 暴露 |
| 性能敏感度 | 极高（直接影响请求延迟和吞吐） | 中等（配置变更频率低，但故障影响面大） |
| 故障影响 | 局部（单个 Envoy 故障仅影响所在 Pod） | 全局（istiod 故障导致新配置无法下发，但已有连接不受影响） |
| 配置来源 | 从控制平面拉取 xDS 配置 | 从 Kubernetes API Server 或 Mesh Config 获取 |
延迟诊断视角：
- 数据平面延迟：Envoy 的线程模型（worker 数）、连接池耗尽、TLS 握手开销、iptables 规则冲突是常见根因。
- 控制平面延迟：istiod 的 xDS 推送延迟、配置变更风暴、Envoy 与 istiod 之间的 gRPC 连接稳定性会影响策略生效速度。
- 多集群场景：跨集群通信时，控制平面需要同步服务发现信息，数据平面需要建立跨集群的 mTLS 隧道，延迟链路更长。
xDS 协议核心资源
Envoy 通过以下 xDS 接口从 istiod 获取配置，每个接口对应一种资源类型：
- LDS (Listener Discovery Service)：监听器配置，定义 Envoy 监听哪些端口、如何处理入站流量。
- RDS (Route Discovery Service)：路由配置，定义请求匹配规则、目标集群、重试/超时策略。
- CDS (Cluster Discovery Service)：集群配置，定义上游服务端点列表、负载均衡算法、连接池大小。
- EDS (Endpoint Discovery Service)：端点配置，动态更新集群中可用的 Pod IP 和端口。
- SDS (Secret Discovery Service)：密钥配置，分发 TLS 证书和私钥，用于 mTLS 通信。
最佳实践： 在延迟诊断时，优先检查 Envoy 的
/stats 端点，关注 cluster.upstream_rq_time、listener.downstream_cx_active、cluster.membership_healthy 等指标。这些指标直接反映数据平面的健康状态和延迟分布。