3. 东西向流量定义：东西向流量 vs 南北向流量、服务间调用链、典型拓扑（Kubernetes Pod-to-Pod）
在服务网格与云原生架构中，流量方向是理解网络路径、延迟来源与治理边界的基础。本章从流量分类、调用链模型与典型拓扑三个维度，建立东西向流量的完整定义。
3.1 东西向流量 vs 南北向流量
东西向流量（East-West Traffic）指数据中心或集群内部服务之间的通信流量，通常不经过外部负载均衡器或互联网网关。南北向流量（North-South Traffic）则指外部客户端（用户、API 调用方、外部系统）进入集群或从集群出去的流量。
| 对比维度 | 东西向流量 | 南北向流量 |
|---|---|---|
| 通信方向 | 服务 ↔ 服务（内部） | 外部 ↔ 服务（边界） |
| 典型协议 | HTTP/2、gRPC、TCP、Kafka 协议 | HTTP/1.1、HTTPS、WebSocket |
| 网关角色 | Sidecar Proxy（Envoy / MOSN） | Ingress Gateway / API Gateway |
| 延迟敏感度 | 极高（微秒级抖动影响业务） | 较高（受公网与 TLS 握手影响） |
| 治理重点 | 负载均衡、重试、超时、熔断、mTLS | 认证、限流、WAF、路由 |
| 可观测性关注点 | 调用链、延迟分布、拓扑依赖 | 请求率、错误率、响应时间（RED） |
诊断提示： 在延迟诊断交付前，东西向流量路径上的每个 Sidecar 都会引入 1–3ms 的额外延迟（取决于协议与 CPU 争用）。验收时需区分“网格引入延迟”与“业务代码延迟”，避免将 Sidecar 开销误判为服务性能问题。
3.2 服务间调用链
东西向流量的核心载体是服务间调用链（Service-to-Service Call Chain）。在 Kubernetes + Istio 环境中，一次典型的调用链包含以下参与者：
- 源 Pod：发起请求的工作负载实例。
- 源 Sidecar Proxy：拦截出站流量，执行路由、负载均衡、mTLS 加密与遥测数据生成。
- 目标 Sidecar Proxy：接收入站流量，执行鉴权、速率限制与遥测数据生成。
- 目标 Pod：处理请求并返回响应。
- 控制面组件（如 Istiod）：下发 xDS 配置，不参与数据路径但影响首次连接延迟。
调用链的延迟构成可分解为：
总延迟 = 源 Pod 处理时间
+ 源 Sidecar 入站/出站处理时间
+ 网络传输时间（CNI + 节点间网络）
+ 目标 Sidecar 入站/出站处理时间
+ 目标 Pod 处理时间
常见误区： 部分团队在验收时只测量 Pod IP 之间的 ping 延迟，忽略了 Sidecar 的协议处理开销。对于 HTTP/2 或 gRPC 流，Sidecar 的 Header 解析与流控逻辑可能贡献 30%–50% 的端到端延迟。必须使用分布式追踪（如 Jaeger / Zipkin）逐跳分解。
3.3 典型拓扑：Kubernetes Pod-to-Pod
在 Kubernetes 集群中，东西向流量的最小单元是 Pod-to-Pod 通信。无论是否启用服务网格，流量路径都遵循以下拓扑结构：
3.4 东西向流量路径清单化验收要点
在交付前验收中，东西向流量路径需逐项确认以下清单项：
- Pod 网络可达性：确认源 Pod 与目标 Pod 之间三层网络连通，无防火墙或网络策略阻断。
- Sidecar 注入验证：确认源与目标 Pod 均包含 Sidecar 容器，且 iptables 规则正确拦截流量（端口 15001/15006）。
- mTLS 握手延迟：测量首次连接时 TLS 握手耗时，确认在预期范围内（通常 < 10ms）。
- 调用链完整性：通过分布式追踪确认每个请求都经过源 Sidecar → 网络 → 目标 Sidecar 的完整路径。
- 延迟基线：记录无网格时的 Pod-to-Pod 延迟作为基线，对比启用网格后的增量。
验收交付物示例： 在验收报告中，东西向流量部分应包含一张拓扑图（如上图）、一张延迟对比表（无网格 vs 有网格）、以及至少 3 条典型调用链的 Trace ID 与 Span 耗时明细。