企业官网建设流程全解析

1. 为什么需要链路追踪
2. 可观测性三大支柱
3. 大模型调用的链路追踪特殊性
4. SkyWalking 在可观测体系中的定位
5. 全栈可观测性体系搭建路线
6. 小结与本阶段路线图

1. 为什么需要链路追踪

当系统从单体应用演进为微服务，再进一步叠加大模型（LLM）调用后，一次用户请求往往要穿越几十个服务节点，其中还可能包含一次动辄数秒、甚至数十秒的大模型推理调用。传统"看日志、查数据库"的排障方式，在这种长链路、异构调用面前几乎失效。链路追踪（Distributed Tracing）正是为了在分布式系统中还原一次请求完整路径而生的技术。

1.1 微服务架构下的"黑盒"困境

在单体时代，一次请求的处理逻辑集中在一个进程里，出现问题直接打堆栈即可定位。微服务化之后，请求被拆散到多个进程、甚至跨语言的服务中：

• 网关把请求转发给 `order-service`
• `order-service` 调用 `user-service` 和 `inventory-service`
• `inventory-service` 又依赖 `redis` 与 `mysql`

当 `order-service` 响应变慢，你很难只凭它自己的日志判断：是下游 `user-service` 慢了，还是数据库锁等待，还是自身线程池被打满？每个服务都只看到"自己这一段"，整条链路的全局视图是缺失的。

1.2 大模型调用带来的新复杂度

引入大模型后，问题被进一步放大：

• **耗时数量级跃升**：传统 RPC 调用通常在毫秒到几百毫秒，而大模型推理常在 1~30 秒，流式（streaming）响应更是以"分钟"计。
• **异构链路段**：一次问答可能涉及「应用网关 → 业务服务 → 向量数据库检索（RAG）→ 大模型网关 → 远端 LLM API」，每一段的技术栈和时延特征都不同。
• **成本维度**：除了时延，Token 消耗也是关键指标，需要把"花了多少钱"关联到具体调用链路。

1.3 一个真实的线上性能故障场景

某天凌晨告警：智能客服对话接口 P99 从 800ms 涨到 12s。值班同学翻遍日志，发现应用本身 CPU 正常、GC 正常。最终通过链路追踪平台看到：故障根因不在业务代码，而在 `vector-search-service` 的一次慢查询（向量索引未命中，退化成全表扫描），把 RAG 检索时延从 50ms 拉到了 9s，进而阻塞了整条对话链路。如果没有链路追踪，这个根因可能要花数小时才能定位。

这正是链路追踪的价值：**把"黑盒"变成"透明管道"，让每一毫秒的耗时都有归属。**

2. 可观测性三大支柱

业界公认的可观测性（Observability）由三大支柱构成：Metrics（指标）、Tracing（链路）、Logging（日志）。三者互补，缺一不可。

2.1 Metrics 指标

指标是聚合后的数值，回答"系统整体健康吗"。例如 QPS、错误率、P99 时延、JVM 堆内存使用率。指标的优势是开销低、适合长期存储与告警；劣势是**丢失了单次请求的细节**，无法告诉你"这一次慢请求到底卡在哪"。

2.2 Tracing 链路

链路追踪记录单次请求穿越所有服务的完整路径，由一个 `Trace` 和若干 `Span` 组成。它回答"这一次请求慢在哪里"。这是本系列的核心主题，SkyWalking 正是以 Tracing 为主、兼顾 Metrics 的平台。

2.3 Logging 日志

日志是离散的文本事件，回答"当时发生了什么"。结构化日志配合 TraceId 关联后，可以从某条慢链路直接跳转到对应的错误日志。

2.4 三者如何协同

三者并非替代关系，而是协同关系，关键是**通过统一的上下文（TraceId）打通**：

> 实践建议：用 Metrics 发现异常（告警），用 Tracing 定位瓶颈（下钻），用 Logging 确认根因（取证）。三者的桥接点是 TraceId。

3. 大模型调用的链路追踪特殊性

大模型链路和传统微服务链路有本质差异，直接套用传统埋点方案会"漏掉最贵、最慢的那一段"。

3.1 长耗时与流式响应

传统 Tracer 的 Span 通常在请求返回时结束。但大模型流式响应会先返回若干 token，再持续推送。如果不做特殊建模，整条链路会被统计为一个"超长 Span"，无法区分"首字时延（TTFT）"和"完整生成时延（TPOT）"。SkyWalking 的 Span 可以分阶段打点，把"等待首 token"和"流式输出"拆成不同区间。

3.2 多段调用链

一次 RAG 问答的典型链路如下（见图 figure_01_2）：

用户请求
└─> API Gateway
└─> Chat Service
├─> Vector DB (RAG 检索) ← 网络 + 向量计算
├─> Prompt 组装 (Local Span)
└─> LLM Gateway
└─> 远端大模型 API ← 最慢、最贵的一段

每一段都要被纳入同一个 Trace，否则排障时就会在"业务服务"和"大模型"之间出现断点。

3.3 Token 成本与链路关联

大模型调用会产生 Token 消耗与费用。最佳实践是在 Exit Span（向 LLM 发起调用的 Span）上挂载 Tag：

tags:
- llm.model: "gpt-4o"
- llm.token.prompt: 1280
- llm.token.completion: 540
- llm.cost.usd: 0.021
- llm.ttft.ms: 860 # 首字时延

这样就能在 SkyWalking 的拓扑图与追踪详情里，直接看到"哪次调用最贵、哪次调用最慢"。

4. SkyWalking 在可观测体系中的定位

4.1 为什么选 SkyWalking

对比主流方案：

对 Java 微服务 + 大模型场景，SkyWalking 的**无侵入 Agent 埋点**和**原生拓扑图**最具吸引力，无需改业务代码即可拿到全链路视图。

4.2 SkyWalking 能力矩阵

SkyWalking 提供的能力覆盖三大支柱中的两块（Tracing + Metrics），并可通过日志插件桥接 Logging：

• **拓扑自动发现**：从链路数据自动绘制服务依赖图。
• **分布式追踪**：还原每一次请求的完整 Span 树。
• **性能剖析（Profiling）**：线程级 CPU/栈火焰图，定位代码热点。
• **告警**：基于 OAL（Observability Analysis Language）定义规则。
• **可观测性分析语言 OAL**：用类 SQL 语法自定义指标。

5. 全栈可观测性体系搭建路线

5.1 技术选型建议

observability_stack:
tracing: skywalking # 分布式追踪 + 拓扑 + 性能剖析
metrics: prometheus+grafana # 指标采集与看板
logging: loki+elk # 日志，按 TraceId 关联
bridge:
- skywalking-log -> loki # 日志带 TraceId
- grafana -> skywalking # 看板跳转追踪

5.2 分阶段实施路线

1. **阶段一：接入 SkyWalking Agent**，先拿到拓扑与基础 Trace，零侵入。
2. **阶段二：补充大模型 Span 埋点**（手动埋点 + 自定义 Tag），覆盖 LLM 调用段。
3. **阶段三：打通日志与指标**，让 TraceId 贯穿 Metrics/Logging。
4. **阶段四：建立告警与性能剖析机制**，实现"异常自动下钻"。

6. 小结与本阶段路线图

本篇我们建立了全局认知：链路追踪是分布式系统中还原请求路径的核心手段；可观测性由 Metrics、Tracing、Logging 三大支柱构成；大模型调用因其"长耗时、多段、高成本"的特性，对链路追踪提出了新要求；而 SkyWalking 凭借无侵入 Agent 与原生拓扑，是 Java 微服务接入大模型场景下的优选。

接下来的路线图：

• 第 02 篇：剖析 SkyWalking 四大组件（Agent / OAP / Storage / UI）内部机制。
• 第 03 篇：深入 Java Agent 字节码增强原理。
• 第 04 篇：Spring Boot 接入 SkyWalking 实战。
• 第 05 篇：大模型链路的 Trace/Span 建模与 Tag 规范。

> 一句话总结：**可观测性不是"装个工具"，而是一套贯穿 Metrics、Tracing、Logging 的方法论；链路追踪是这套方法论里让"慢请求无所遁形"的那把钥匙。**