4. 链路拓扑基础：服务网格中的拓扑结构、节点与边的定义、拓扑数据的存储方式

在服务网格（Service Mesh）架构中，链路拓扑是理解微服务间通信路径、依赖关系以及流量行为的基础。与传统的网络拓扑不同，服务网格的拓扑更侧重于 逻辑服务 与 代理（Sidecar） 之间的交互关系。本章将深入解析拓扑中的节点与边定义，并介绍拓扑数据的存储机制。

4.1 服务网格拓扑的核心结构

服务网格的拓扑结构通常呈现为 逻辑分层 与 数据平面 的组合。最典型的模型是 Sidecar 代理模型，其中每个服务实例旁边都伴生一个 Envoy 或类似代理。拓扑结构可以抽象为以下三层：

• 基础设施层：包含 Kubernetes 节点、Pod、Service 等底层资源。
• 数据平面层：由所有 Sidecar 代理组成，负责拦截、转发和观测流量。
• 控制平面层：负责下发配置、证书和策略，如 Istiod、Consul Server。

4.2 节点与边的精确定义

在链路拓扑中，节点（Node） 和 边（Edge） 是构成图谱的基本单元。它们的定义直接决定了拓扑图的粒度和可观测性。

4.2.1 节点的类型

4.2.2 边的语义

边代表节点之间的 通信关系 或 依赖关系。在服务网格中，边通常携带丰富的元数据：

• 协议：HTTP、gRPC、TCP。
• 流量方向：请求（Request）与响应（Response）。
• 指标：请求速率、错误率、延迟（P50/P95/P99）。
• 安全属性：是否启用 mTLS、是否通过授权策略。

{
  "source": "productpage-v1",
  "target": "reviews.default.svc.cluster.local",
  "protocol": "HTTP",
  "direction": "outbound",
  "metrics": {
    "rps": 150,
    "error_rate": 0.02,
    "p99_latency_ms": 450
  },
  "tls": "mutual"
}

4.3 拓扑数据的存储方式

拓扑数据需要被持久化，以便进行历史回溯、变更分析和可视化展示。根据使用场景的不同，存储方式主要分为以下三类：

4.3.1 图数据库存储模型

图数据库是存储拓扑数据的理想选择。以下是一个简化的拓扑数据模型：

// 节点定义
(:Workload {name: "productpage-v1", namespace: "default", labels: ["app:productpage"]})
(:Service {name: "reviews", namespace: "default", port: 9080})

// 边定义
(workload)-[:CALLS {
  protocol: "HTTP",
  direction: "outbound",
  last_seen: "2025-03-15T10:30:00Z"
}]->(service)

4.4 拓扑数据的采集与更新机制

拓扑数据不是静态的，它随着服务的扩缩容、滚动更新、流量切换而动态变化。典型的采集流程如下：

1. 数据平面上报：Sidecar 代理通过 Access Log 或 Metrics 接口上报连接信息。
2. 控制平面聚合：控制平面组件（如 Istio Pilot）收集所有代理的发现信息，构建全局服务依赖图。
3. 持久化存储：将聚合后的拓扑数据写入图数据库或时序数据库。
4. 增量更新：仅当服务关系发生变化时（如新版本上线、端点移除），才更新拓扑图，避免全量重算。

4.5 拓扑数据在 ConfigMap 可视化中的角色

在本课程的核心场景中，拓扑数据是 ConfigMap 变更影响分析 的基础。当用户修改 ConfigMap 并触发 Sidecar 配置重载时，拓扑图能够直观地展示：

• 哪些工作负载的 流量路径 发生了变化。
• 变更是否引入了 环路 或 断连。
• 受影响的 租户范围 有多大。