2. 流量治理核心概念

在 Service Mesh 中，所有治理能力都建立在一组基础概念之上：流量从哪里来、到哪里去，谁负责转发，谁负责决策，以及应用如何在不改代码的前提下被“接管”。理解这四个问题，就理解了 Istio、Linkerd 等主流服务网格的运行骨架。

一、东西向流量与南北向流量

按流量的发起位置与目标位置划分，网格内流量通常分为两类：

• 南北向流量（North-South）：从集群外部进入集群，或从集群内部流向外部。典型入口是 Ingress Gateway，出口是 Egress Gateway。它承载的是用户请求、第三方 API 调用、外部数据库访问等。
• 东西向流量（East-West）：集群内部服务之间的调用，例如订单服务调用库存服务、库存服务调用支付服务。它是服务网格治理的主战场，也是 mTLS、重试、熔断、流量镜像等能力最常作用的对象。

两者的治理目标不同：南北向更关注入口安全、限流、TLS 终止与路由规则；东西向更关注服务间身份认证、负载均衡、故障注入与可观测性。在 Istio 中，南北向通常由 Gateway + VirtualService 描述，东西向则由 VirtualService + DestinationRule 描述。

二、数据平面与控制平面

Service Mesh 采用“控制与转发分离”的架构：

• 数据平面（Data Plane）：由每个 Pod 中的 Sidecar 代理（如 Envoy）组成，负责实际转发、加密、限流、重试、上报指标。它不决定“该不该转发”，只执行下发的规则。
• 控制平面（Control Plane）：如 Istiod，负责服务发现、配置分发、证书签发、策略校验。它把用户写的 YAML 翻译成 Envoy 能理解的 xDS 配置，推送给数据平面。

一个关键判断：数据平面决定性能与延迟，控制平面决定配置生效速度与一致性。当出现“规则已改但流量行为未变”时，优先检查控制平面是否成功推送、Sidecar 是否收到新配置，而不是先怀疑业务代码。

三、Sidecar 模式

Sidecar 是与业务容器同 Pod 部署的辅助容器，共享网络命名空间。它的核心价值是：业务容器无感知地获得治理能力。业务仍然监听自己的端口，Sidecar 通过 iptables 规则把进出流量重定向到 Envoy 的监听端口。

以 Istio 默认注入为例，Sidecar 会占用两个端口：15001 用于出站流量劫持，15006 用于入站流量劫持，15090 暴露 Prometheus 指标。业务容器完全不知道这些端口的存在。

四、透明拦截与流量劫持原理

“透明”意味着应用不需要修改代码、不需要指定代理地址。实现依赖 Linux 的 iptables 与 netfilter：

1. Pod 启动时，init 容器 istio-init 写入 iptables 规则。
2. 出站流量在 OUTPUT 链被重定向到 15001，Envoy 根据目标地址选择上游集群。
3. 入站流量在 PREROUTING 链被重定向到 15006，Envoy 完成 mTLS 终止、鉴权后再转发给业务容器。
4. Envoy 通过 xDS 从控制平面获取集群、监听器、路由、端点信息。

下面这张图展示了从外部请求进入，到东西向调用完成的全链路结构，以及控制平面与数据平面的配置下发关系。

五、一次请求的完整链路

假设外部用户访问订单服务，订单服务再调用库存服务，链路如下：

1. 用户请求到达 Ingress Gateway，Gateway 完成 TLS 终止与路由匹配。
2. Gateway 将请求转发到订单服务 Pod 的 15006 端口，Envoy 完成入站鉴权后交给业务容器 :8080。
3. 订单服务发起对库存服务的调用，出站流量被 15001 劫持，Envoy 根据 DestinationRule 选择实例并建立 mTLS 连接。
4. 库存服务 Sidecar 在 15006 完成对端身份校验，再转发给业务容器 :9090。
5. 两侧 Envoy 分别上报指标与访问日志，控制平面持续下发最新配置。

掌握这四个概念后，后续的 VirtualService 路由、DestinationRule 负载均衡、PeerAuthentication 双向 TLS 等配置，本质上都是在控制平面写入规则，再由数据平面执行。理解“谁决策、谁执行、流量怎么走”，是排查网格问题的第一性原理。