4. 网络拓扑概念：微服务架构下的东西向与南北向流量，拓扑发现与可视化
在生产窗口内执行 tc 回滚验证时，网络拓扑的精确理解是判断故障影响范围、选择回滚策略的前提。微服务架构下的流量模型与传统单体应用有本质区别，东西向与南北向流量的交织使得拓扑发现与可视化成为 SRE 必须掌握的核心能力。
4.1 南北向流量与东西向流量
在 Kubernetes 与微服务环境中，流量按方向分为两类，其故障隔离与回滚策略截然不同：
| 维度 | 南北向流量 (North-South) | 东西向流量 (East-West) |
|---|---|---|
| 定义 | 外部客户端进入集群，或集群向外部的流量 | 集群内部服务之间的调用流量 |
| 入口/出口 | Ingress / Gateway / LoadBalancer → Service → Pod | Pod → Service → Pod（或 Headless Service 直连） |
| 协议特征 | HTTP/HTTPS、gRPC、TLS 终止、域名路由 | HTTP、gRPC、TCP、UDP、内部 RPC（如 Dubbo、Thrift） |
| 回滚影响 | 直接影响外部用户，回滚需考虑会话保持与 DNS 缓存 | 影响内部链路，回滚需关注调用链断裂与级联超时 |
| 典型故障 | 502/503 网关超时、证书过期、路由规则错误 | 连接池耗尽、重试风暴、熔断误触发、DNS 解析延迟 |
SRE 实战提示： 在
tc 回滚场景中，南北向流量故障通常表现为入口网关的延迟飙升或错误码激增，而东西向流量故障往往先表现为内部调用超时与重试，随后才扩散到南北向。拓扑可视化必须能区分这两种流量路径，才能精准定位回滚目标。
4.2 微服务拓扑发现机制
拓扑发现是自动构建服务依赖关系的过程，在 Helm 交付与 tc 回滚中，依赖以下数据源：
- Service Mesh 控制面（如 Istio Pilot、Consul）： 通过 xDS 协议下发服务发现与路由规则，控制面天然持有全局服务拓扑。
- Kubernetes API Server： Service、EndpointSlice、Pod 的 Label/Selector 关系构成静态拓扑骨架。
- 可观测性数据： 分布式追踪（Jaeger/Zipkin）、指标（Prometheus）、日志（Loki）中的调用关系动态补全拓扑。
- 网络策略（NetworkPolicy）： 定义 Pod 间允许的流量规则，影响拓扑可达性。
关键原则： 拓扑发现必须同时覆盖静态声明（K8s 资源定义）与动态运行时（实际调用链），因为 Helm 部署后的
tc 规则变更可能使静态拓扑与运行时拓扑产生偏差，这正是回滚需要验证的核心差异。
4.3 拓扑可视化与回滚决策
可视化拓扑将抽象的服务依赖转化为可交互的图形，帮助 SRE 在窗口内快速判断回滚范围。以下是一个典型的微服务东西向与南北向流量拓扑 SVG 图：
4.4 拓扑可视化工具选型
在 Helm 交付与 tc 回滚场景中，拓扑可视化工具的选择直接影响排障效率：
| 工具 | 数据源 | 可视化能力 | 回滚场景适用性 |
|---|---|---|---|
| Kiali | Istio 控制面 + Prometheus | 服务图、健康状态、流量速率、版本标签 | ★★★★★ 原生支持版本对比与回滚影响分析 |
| Weave Scope | K8s API + 进程信息 | 实时拓扑、容器级别、进程级别 | ★★★★☆ 适合快速定位 Pod 级故障 |
| Grafana Node Graph | Prometheus / Tempo / Loki | 自定义拓扑、可嵌入 Dashboard | ★★★★☆ 灵活但需手动配置数据源 |
| Jaeger UI | 分布式追踪数据 | 调用链拓扑、延迟瀑布图 | ★★★☆☆ 适合深度追踪，不直接展示服务网格 |
回滚窗口内的拓扑陷阱： 可视化拓扑通常基于控制面数据（如 Istio 的 ServiceEntry）或历史指标，但
tc 规则变更可能造成数据面与控制面不一致。例如，tc 注入的延迟规则在拓扑图上不可见，但实际流量已受影响。SRE 必须结合实时指标与追踪数据交叉验证，不能仅依赖拓扑图做回滚决策。
4.5 拓扑发现与回滚的联动流程
在生产窗口内，拓扑发现与 tc 回滚验证的联动遵循以下步骤：
- 基线拓扑快照： 在 Helm 部署前，通过 Kiali 或 Grafana 导出当前服务拓扑快照，标注各服务的版本号与健康状态。
- 注入
tc规则： 在目标 Pod 上应用tc延迟/丢包规则，观察拓扑图中受影响的服务节点是否出现异常标记。 - 拓扑差异对比： 对比注入前后的拓扑图，识别新增的故障传播路径（如重试风暴导致的级联超时）。
- 回滚决策： 根据拓扑差异，确定回滚范围——是仅回滚单个 Pod 的
tc规则，还是需要回滚整个 Service 的版本。 - 回滚后拓扑验证： 回滚完成后，再次对比拓扑快照，确认故障路径已消除，东西向与南北向流量恢复正常。
自动化建议： 将拓扑快照与 Helm Release 版本号关联，存储在 GitOps 仓库中。当
tc 回滚触发时，自动拉取对应版本的拓扑基线，减少人工对比误差。