2. 服务网格基础架构回顾：Sidecar代理模式、控制面与数据面、Istio/Envoy核心组件
在交付东西向流量延迟诊断清单之前，必须统一团队对服务网格基础架构的认知基线。本章从Sidecar代理模式、控制面与数据面分离架构以及Istio/Envoy核心组件三个维度，建立后续延迟路径分析所需的通用语言。
2.1 Sidecar代理模式：流量拦截与透明转发
Sidecar代理是服务网格的数据面执行单元。每个业务容器旁部署一个代理容器，所有入站（Inbound）和出站（Outbound）流量均被透明劫持至该代理，实现流量治理逻辑与业务代码的完全解耦。
| 维度 | 传统SDK模式 | Sidecar代理模式 |
|---|---|---|
| 侵入性 | 业务代码需引入SDK、配置重试/超时 | 零侵入，业务容器无感知 |
| 升级成本 | 每个服务重新编译、部署 | 仅升级Sidecar，业务容器不变 |
| 多语言支持 | 每种语言需维护独立SDK | 统一代理，语言无关 |
| 故障隔离 | SDK崩溃可能导致业务进程异常 | 代理崩溃不影响业务进程（仅流量中断） |
延迟诊断视角： Sidecar代理是东西向流量的必经路径点。每次RPC调用至少经过客户端Sidecar（出站）和服务端Sidecar（入站），这两个跳点是延迟累加的核心环节，必须在验收清单中明确标注。
2.2 控制面与数据面分离架构
服务网格将流量管理能力抽象为两个平面：数据面负责处理实际业务流量，控制面负责下发配置与策略。这种分离架构使得流量治理可以集中管控，同时保持数据面的高性能转发。
关键理解： 控制面不参与任何业务数据包转发。即使控制面完全宕机，数据面仍能依据最后一次有效配置继续转发流量，但无法动态调整路由规则。在延迟诊断中，控制面故障不会直接导致延迟增加，但会阻止延迟优化策略的生效。
2.3 Istio/Envoy核心组件
Istio是目前最成熟的服务网格实现，Envoy是其默认数据面代理。理解两者的核心组件及其职责，是定位延迟瓶颈的前提。
2.3.1 Istio控制面组件
| 组件 | 核心职责 | 与延迟诊断的关联 |
|---|---|---|
| Pilot | 服务发现、流量管理规则转换、xDS协议下发 | 路由规则错误可能导致流量绕行或超时 |
| Citadel | 证书签发与管理、mTLS密钥轮换 | 证书过期或握手失败增加连接建立延迟 |
| Galley | 配置验证、分发与状态管理 | 配置推送延迟导致Sidecar规则不一致 |
| Ingress/Egress Gateway | 南北向流量入口/出口管理 | 东西向流量一般不经过Gateway，但需确认 |
2.3.2 Envoy数据面核心概念
Envoy作为Sidecar代理，其内部架构直接影响延迟路径。以下是与延迟诊断最相关的四个概念：
- Listener（监听器）：绑定端口并接收流量。每个Sidecar至少有一个Inbound Listener（如15006）和一个Outbound Listener（如15001）。
- Cluster（集群）：定义上游服务实例集合，包含负载均衡策略、连接池、健康检查等配置。
- Endpoint（端点）：集群中的具体服务实例IP:Port，Envoy通过EDS（Endpoint Discovery Service）动态获取。
- Filter（过滤器）：处理流量的插件链，包括HTTP连接管理器（HCM）、TCP代理、RBAC、限流等。
常见误区： 很多团队在延迟分析时只关注业务代码耗时，忽略了Sidecar内部Filter链的处理开销。例如，HTTP连接管理器（HCM）中的请求头解析、RBAC过滤器的权限校验、限流过滤器的令牌桶检查，都会在每次请求中增加微秒到毫秒级的延迟。这些必须在验收清单中单独测量。
2.4 核心组件交互流程
一次完整的东西向RPC调用，在服务网格中的路径如下：
- 客户端业务容器发起HTTP/gRPC请求到本地localhost（被iptables规则透明劫持）。
- 客户端Sidecar（Envoy）的Outbound Listener（15001）接收请求，经过Filter Chain处理后，根据路由规则选择目标Cluster。
- Envoy通过EDS获取目标服务的可用Endpoint列表，执行负载均衡算法选择一个实例。
- 请求通过TCP连接（或已存在的连接池连接）发送到服务端Pod的IP:Port。
- 服务端Sidecar（Envoy）的Inbound Listener（15006）接收请求，经过Filter Chain处理后，将请求转发给本地服务B的业务容器。
- 服务B处理完成后，响应沿原路径返回。
验收清单要点： 在上述6步中，第2步（客户端Filter处理）、第3步（负载均衡与连接池）、第5步（服务端Filter处理）是延迟累加最密集的区域。交付前的清单化验收必须包含每个Envoy的listener统计、cluster统计和filter统计的基线值。