当线上大模型接口变慢，第一反应往往是「是不是推理服务扛不住了」。但在分布式系统里，慢的根因可能藏在任意一跳：网关排队、业务侧提示词拼接、向量库检索慢、缓存未命中导致回源、或者是某个被忽视的外部模型服务超时。SkyWalking 的拓扑图（Topology）把你所有被追踪的服务及其调用关系自动画成一张网，并在每个节点、每条边上标注实时指标。它是性能排查的「全局地图」，能让你在 30 秒内锁定瓶颈大致在哪个节点，再去下钻 Trace 详情（见第 10 篇）。本文讲透拓扑图怎么读、怎么用。

1. 拓扑图是什么：从 Trace 自动生成依赖网
2. 读懂节点与边上的关键指标
3. 实战：定位大模型服务的瓶颈节点
4. 依赖分析与故障传播
5. 最佳实践与常见误读

1. 拓扑图是什么：从 Trace 自动生成依赖网

拓扑图不需要你手工画、也不需要配 XML。SkyWalking 的 OAP 在消费 Trace 数据时，会提取「服务 A 调用了服务 B」这种关系，自动聚合成全局服务拓扑。每一条被追踪的跨进程调用都会成为图上的一条「边」，每个服务成为一个「节点」。

在大模型应用里，典型的拓扑长这样（自上而下或按调用方向）：

用户(USER) -> API 网关 -> Java 业务服务 -> 推理服务 -> 向量数据库
                                  |-> 缓存 Redis
                                  |-> 外部模型服务(OpenAI 等)
 

这里有两个特殊节点值得注意：

• **USER（用户）**：所有入向流量的虚拟起点，代表真实用户请求。
• **未插桩节点**：如果某个服务没挂探针（比如 Python 推理服务忘了挂 `sw-python`），它不会以真实服务名出现，而是退化成一个灰色的 `Unknown` 节点，或干脆体现在业务服务「出向调用了一个未知依赖」。这是排查时的强信号——链路里缺了一块。

拓扑图是动态刷新的，默认时间窗可切换为最近 15 分钟、30 分钟、1 小时等。它和链路追踪的关系可以一句话概括：**Trace 是「一条请求」的微观路径，拓扑图是「所有请求」的宏观关系**。两者配合，先拓扑定位节点，再 Trace 下钻细节。

2. 读懂节点与边上的关键指标

拓扑图不是好看的连线，它的价值在指标。每个节点和每条边都带着一组实时指标，重点看四个：

指标	含义	瓶颈信号
---	---	---
CPM（每分钟调用数）	吞吐量	流量突增常伴随延迟上升
响应时间（avg / p50 / p99）	该节点或该跳的耗时	p99 远高于 avg 说明存在长尾
SLA（成功率）	成功请求占比	低于 99% 通常已影响业务
Apdex	用户体验满意度（0~1）	低于 0.85 用户明显感知卡顿

边的指标尤其关键：它代表「从上游到下游这一跳」的耗时与成功率。当你发现整体接口慢，但业务服务自身节点很快，而「业务服务 -> 推理服务」这条边很慢，那么瓶颈就明确在推理服务这一侧，无需再猜。

在 SkyWalking UI 里，节点颜色本身就是告警：绿色正常、黄色有压力、红色异常或高延迟。鼠标悬停能看到概览，点击节点进入该服务的指标仪表盘，再点击顶部的「Trace」即可看到该服务的慢调用列表。

3. 实战：定位大模型服务的瓶颈节点

假设你收到告警：对话接口 P99 从 1.2s 涨到 4s。排查步骤：

**第一步，打开全局拓扑图，看整体颜色。** 如果「推理服务」节点变红，初步怀疑 GPU 推理瓶颈；如果只是「向量数据库」变黄，可能是 RAG 检索慢。

**第二步，沿着入向边逐级看耗时。** 从 USER 出发，逐跳比较响应时间。常见分布：

• `USER -> 网关` 慢：网关过载或限流配置过严。
• `网关 -> 业务服务` 慢：业务线程池打满、GC 停顿。
• `业务服务 -> 推理服务` 慢：GPU 显存不足、批处理排队、KV Cache 命中率低。
• `业务服务 -> 向量数据库` 慢：向量索引未优化、查询维度高、数据量大。

**第三步，点击嫌疑节点，下钻指标。** 在节点仪表盘里看 CPM、响应时间百分位、SLA 曲线，确认是「持续慢」还是「毛刺」。持续慢多为容量/配置问题，毛刺多为 GC、锁竞争或外部抖动。

**第四步，用 GraphQL 接口把拓扑数据拉出来做自动化巡检。** SkyWalking 提供 GraphQL API，可以定时查询拓扑并识别异常节点：

curl -X POST 'http://oap:12800/graphql' \
  -H 'Content-Type: application/json' \
  -d '{
    "query": "query { topology(duration: {start: \"20240101-1000\", end: \"20240101-1030\", step: MINUTE}) { nodes { name type apdex } calls { source dest callType } } }"
  }'
 

把返回数据接入你自己的监控看板，当某个节点的 `apdex` 低于阈值或 `calls` 中某跳响应时间超标时自动告警，就能在用户投诉前发现瓶颈。

4. 依赖分析与故障传播

拓扑图最大的威力是「看清依赖方向」，从而判断故障会怎么传播。大模型应用的依赖有两类风险：

• **强依赖 vs 弱依赖**：推理服务是强依赖，它挂了对话直接失败；缓存 Redis 通常是弱依赖（未命中可回源），它慢不应导致接口失败，除非代码把它写成了强依赖。在拓扑上，若发现「缓存慢」却「整体失败率上升」，就要检查是否错误地把弱依赖当强依赖用了。
• **扇出与级联**：业务服务一次对话可能并行调用向量库、缓存、外部模型三个下游。任意一个变慢都会拖慢整体（取最慢者）。拓扑图能直观看到这种「一对多」扇出，帮你识别单点瓶颈。

故障传播的经典模式是「雪崩链」：推理服务变慢 -> 业务服务线程被占满 -> 网关排队 -> USER 侧大面积超时。在拓扑图上，你会看到红色从推理节点沿边向上游逐层蔓延。此时正确做法不是去重启上游，而是先在推理服务侧限流/扩容，切断传播源。

依赖分析还能发现「隐形调用」：如果拓扑突然出现一个你不知道的外部节点（如某个第三方模型 API），说明代码里引入了新依赖，可能是它导致了延迟或成本异常。

5. 最佳实践与常见误读

用好拓扑图，有几条经验：

• **先拓扑后 Trace**：别一上来就翻 Trace 列表，先用拓扑图 30 秒定位节点，再下钻，效率提升一个数量级。
• **关注边而非只看节点**：整体慢往往是某一跳边慢，节点自身可能很健康。
• **区分持续与毛刺**：持续慢查容量，毛刺查 GC/外部抖动。
• **补齐未插桩节点**：看到 `Unknown` 立刻给对应服务挂探针，否则拓扑有「黑洞」，排障会漏判。
• **结合采样看趋势**：开启采样（见第 08 篇）后，拓扑聚合指标基于采样数据，绝对数值会有偏差，但相对趋势和排名依然可靠，定位瓶颈足够。

常见误读：

误读	真相
---	---
节点红 = 这个服务代码有 bug	也可能是下游慢把它拖红，要看入向边
拓扑延迟就是用户感知延迟	拓扑是各跳之和，但用户感知还含建连、排队等
没画出来的调用就不存在	未插桩的依赖不会显示，要用 `Unknown` 反推
Apdex 低一定是要优化	需结合 CPM，低流量下 Apdex 抖动不具代表性

6. 拓扑的三个层级：服务 / 实例 / 端点

SkyWalking 的拓扑不是只有「服务级」一种粒度，它提供三个层级，排查时切换着看，信息量完全不同：

• **服务拓扑（Service Topology）**：节点是服务，最常用，一眼看清网关、业务、推理、向量库之间的依赖与整体瓶颈（本文前面用的就是这一层）。
• **实例拓扑（Instance Topology）**：节点是服务的具体实例（如每个 Pod、每个 GPU 节点）。当某个推理节点变红、其他正常时，服务拓扑看不出问题，必须切到实例拓扑才能定位「是某一台 GPU 机器显存打满、KV Cache 命中率低，还是网卡故障」。
• **端点拓扑（Endpoint Topology）**：节点是具体接口（如 `/api/chat`、`/v1/chat/completions`、`/health`）。它能告诉你到底是核心对话接口慢，还是某个调试接口拖累了整体，避免把「健康检查的慢」误判成「对话慢」。

大模型场景下，实例拓扑尤其有用：推理服务通常多副本部署，流量不均或单卡故障是常态。在服务拓扑里推理服务只是「整体偏红」，切到实例拓扑往往能看到「9 个绿、1 个红」，那个红的实例就是根因所在，直接摘流或重启即可。

7. 百分位指标与告警联动

拓扑图上的「响应时间」默认聚合的是平均值，但平均值会掩盖长尾——而大模型推理恰恰以长尾著称（首 token 延迟偶尔飙到几秒）。所以看拓扑时务必切换到百分位视图（p50 / p90 / p99），p99 才是用户体验的真实下界。

SkyWalking 的告警可以基于拓扑聚合指标自动触发。在 `alarm-settings.yml` 里配置规则，让瓶颈在拓扑图变红之前就主动通知你：

rules:
  service_resp_time_rule:
    metrics-name: service_resp_time
    threshold: 2000
    op: ">"
    period: 10
    count: 3
    message: 服务 {name} 平均响应超过 2s
  service_p99_rule:
    metrics-name: service_resp_time_percentile
    threshold: 3000
    op: ">"
    period: 10
    count: 2
    message: 服务 {name} P99 超过 3s，疑似长尾
  service_sla_rule:
    metrics-name: service_sla
    threshold: 99
    op: "<"
    period: 10
    count: 2
    message: 服务 {name} 成功率低于 99%
 

把这些规则接到钉钉 / 飞书 / 企业微信 webhook，运维就能在拓扑图刚泛黄时就收到提醒，而不是等用户投诉。告警指标和拓扑图用的是同一份聚合数据，二者天然一致。

8. 端到端案例：一次对话变慢的排查实录

把前面的方法串成一个真实案例。某天上午，对话接口 P99 从 1.5s 涨到 4s，开始有用户投诉。

1. **看服务拓扑**：整体泛黄，推理服务节点变红。初步怀疑推理侧。
2. **切实例拓扑**：发现 10 个推理 Pod 里只有 1 个变红，p99 高达 6s，其余约 2s。确认是单实例问题，不是整体容量不足。
3. **看该实例指标**：CPM 与其余实例相近，但响应时间百分位陡增，SLA 掉到 97%。结合该 Pod 所在 GPU 节点的监控，发现显存占用 98%、KV Cache 命中率骤降——是该卡上另一个任务抢占了显存。
4. **下钻 Trace**：打开变红实例的慢 Trace，确认耗时集中在 `POST /v1/chat/completions` 这个 Exit Span，且 peer 指向那个异常 Pod。
5. **处置与验证**：把异常 Pod 摘流重启，10 分钟后实例拓扑全部转绿，对话 P99 回到 1.5s。

整个过程从「收到投诉」到「定位到具体 Pod」只用了几分钟，靠的就是拓扑图先缩小范围、再下钻验证的打法。如果一开始就去翻日志，可能在 10 个 Pod 的海量日志里迷失方向。

9. 拓扑图在容量规划中的用法

拓扑图不只是故障时的「急诊地图」，也是日常容量规划的依据。两个常用姿势：

• **看 CPM 趋势预判扩容**。在节点仪表盘里拉长时间窗（如 7 天），观察 CPM 曲线是否在稳步抬升。若推理服务 CPM 每周涨 20% 且 p99 同步抬升，说明容量快到顶，应提前扩容而不是等告警。拓扑图的时间窗切换让「趋势」一目了然。
• **看实例拓扑识别热点**。即使整体 CPM 不高，实例拓扑里若某个 Pod 的 CPM 或响应时间明显高于兄弟节点，往往是流量倾斜或该实例资源受限（CPU 限速、NUMA、显存碎片）。这种「不均」在平均值里看不见，只有实例级拓扑能暴露。

端点拓扑则用于识别「哪个接口是流量大户」。大模型应用里 `/v1/chat/completions` 通常是绝对主力，优化资源时应优先保障它；而 `/metrics`、`/health` 等探针接口流量虽高却不该占用推理 GPU，应放到独立端口或降低采样。

10. 常见拓扑异常模式与处置

把高频的拓扑「脸色」对应的根因整理成表，遇到直接对照：

拓扑表现	可能根因	处置方向
---	---	---
全链泛红、从推理向上蔓延	推理侧雪崩，级联拖垮上游	先限流/扩容推理，切断传播源
单点红（某一实例）	该实例资源异常或流量倾斜	摘流重启，检查该节点资源
扇出红（一对多全慢）	多个下游同时慢，或本服务线程池满	看各下游边，分别优化
上游红、下游全绿	上游自身处理慢（GC/锁/序列化）	下钻 Trace 看 self 耗时，做 Profile
出现 Unknown 灰节点	存在未插桩依赖	给该服务挂探针
节点黄但不红	有压力但未超 SLA	观察趋势，暂不紧急处理

这套模式表配合第 8 节的端到端案例，能让你在告警触达后的第一时间就形成「假设—验证」的排查路径，而不是盲目翻日志。

总结：拓扑图是性能排查的「作战地图」。先在大图上锁定变红或变黄的节点与边，再带着明确目标去下钻 Trace 详情，就能把平均排障时间从「翻半小时日志」压缩到「几分钟定位」。下一篇我们深入 Trace 详情与性能剖析（Profile），把瓶颈钉到具体方法。