博客一：Zipkin + Sleuth 入门详解：一篇搞懂微服务链路追踪
前言
在单体项目中，排查一个接口通常比较简单：
用户请求
↓
Controller
↓
Service
↓
Mapper
↓
MySQL
所有代码基本都运行在一个应用中。
线上出了问题，我们查一个应用的日志，往往就能找到原因。
但是到了微服务以后，一次请求可能变成：
Browser
↓
Gateway
↓
Order Service
↓
User Service
↓
Inventory Service
↓
Payment Service
↓
第三方支付平台
现在用户投诉：
为什么创建订单用了 8 秒？
问题就麻烦了。
到底是：
Gateway 慢？
Order 慢？
Inventory 慢？
Payment 慢？
MySQL 慢？
第三方接口慢？
如果没有链路追踪，你可能需要登录四五台机器，一个日志文件一个日志文件地查。
于是出现：
Distributed Tracing
也就是：
分布式链路追踪。
而 Zipkin 就是一套非常经典的分布式链路追踪系统。Zipkin 的应用侧 Tracer 会记录 Span，并把完成后的 Span 异步报告给 Zipkin；Zipkin 本身包含 Collector、Storage、Query 和 Web UI 等部分。(Zipkin )
一、什么是链路追踪？
假设用户创建订单：
POST /api/orders
请求经过：
Gateway
↓
Order
↓
Inventory
↓
Payment
链路系统会把它记录成：
Trace: 8f92abc...
Gateway 20ms
└── Order 120ms
├── Inventory 50ms
└── Payment 6200ms
这时候一眼就知道：
Payment
=
6200ms
问题大概率在支付链路。
这就是链路追踪最大的价值：
把一次跨多个服务的请求重新串成一条完整调用链。
二、必须先理解 Trace
链路追踪中最重要的概念：
Trace
一个 Trace 可以理解为：
一次完整请求的生命周期。
例如用户创建订单：
TraceId =
af27c910...
请求经过 Gateway：
Gateway
TraceId=af27c910
继续进入 Order：
Order
TraceId=af27c910
调用库存：
Inventory
TraceId=af27c910
调用支付：
Payment
TraceId=af27c910
虽然这是四个不同应用：
Gateway
Order
Inventory
Payment
但是：
TraceId
一样。
所以我们知道：
它们属于同一次用户请求。
你可以把 TraceId 理解成：
一次分布式请求的身份证号码。
三、什么是 Span？
一个 Trace 又由很多：
Span
组成。
例如：
Trace
│
├── Span：Gateway
│
├── Span：Order
│
├── Span：Inventory
│
└── Span：Payment
甚至 Order Service 内部还可能继续拆：
Order Span
│
├── Controller
├── SQL
├── Redis
└── HTTP Client
所以：
Trace
=
完整请求
而：
Span
=
请求中的一个操作片段
例如：
TraceId = ABC
SpanId = 001
Gateway
SpanId = 002
Order
SpanId = 003
Payment
四、Parent Span 又是什么？
Span 之间存在父子关系。
比如：
Gateway
↓
Order
↓
Payment
可以表示为：
Span Gateway
│
└── Span Order
│
└── Span Payment
这样链路系统才能知道：
谁调用了谁
而不是只知道：
三个服务都执行过
五、Zipkin 是干什么的？
Zipkin 主要负责：
收集、存储、查询和展示链路数据。
例如：
Gateway ───────┐
Order ─────────┤
Inventory ─────┼──→ Zipkin
Payment ───────┘
↓
Storage
↓
Zipkin UI
进入 Zipkin 页面以后，可以按：
Service
TraceId
时间
耗时
Tag
查询调用链。
Zipkin 官方提供 Docker 快速启动方式：
docker run -d -p 9411:9411 openzipkin/zipkin
启动后默认可以通过 9411 端口访问 UI。(Zipkin )
六、那 Sleuth 又是什么？
这个地方特别容易混。
以前 Spring Cloud 项目中非常经典的是：
Spring Cloud Sleuth
+
Zipkin
但是它们职责不同。
Sleuth 主要负责：
生成 TraceId
生成 SpanId
传播 Trace Context
自动埋点
日志关联
Zipkin 负责：
接收 Span
存储 Span
查询 Trace
可视化展示
可以理解成：
Sleuth 负责给每次请求装 GPS。
Zipkin 负责把 GPS 轨迹保存下来并画出来。
七、为什么现在又经常看到 Micrometer Tracing？
这是学习老教程时必须知道的变化。
以前：
Spring Cloud Sleuth
负责 Spring 世界里的链路追踪。
后来 Spring 将这部分能力迁移到了：
Micrometer Tracing
官方文档明确说明，Spring Cloud Sleuth 的相关能力已经迁移到 Micrometer Tracing，新项目应理解 Micrometer Tracing，而不是继续把 Sleuth 当作当前主线方案。(Home )
所以你可以这样记：
老 Spring Cloud 项目
↓
Sleuth
+
Zipkin
而现代 Spring：
Spring Boot
↓
Micrometer Tracing
↓
Brave / OpenTelemetry
↓
Zipkin
Micrometer Tracing 当前支持 Brave 和 OpenTelemetry 两类主要 Tracer 实现。(Micrometer Docs )
所以以后看到老项目：
Sleuth + Zipkin
不要奇怪。
看到新项目：
Micrometer Tracing + Zipkin
也不要认为是另一套完全不同的思想。
解决的问题还是同一个：分布式链路追踪。
八、完整架构到底是什么样？
现代方式可以理解成：
User Request
↓
Gateway
│
Tracer
↓
Order
│
Tracer
↓
Payment
│
│ Span
↓
Zipkin
↓
Storage
↓
Zipkin UI
真正的业务请求：
Order
↓
Payment
不会经过 Zipkin。
Zipkin 只是额外接收：
Tracing Data
Zipkin 官方架构也强调，Trace ID 会随业务请求传播，而完成的 Span 则异步报告给 Zipkin，避免链路系统故障直接阻塞业务请求。(Zipkin )
所以：
Zipkin
≠
Gateway
也不是：
Zipkin
≠
RPC Proxy
九、Spring Boot 怎么接入 Zipkin？
首先启动 Zipkin：
docker run -d -p 9411:9411 openzipkin/zipkin
然后访问：
localhost:9411
就能看到 Zipkin UI。(Zipkin )
十、现代 Spring 项目接入
如果使用现代 Spring Boot，核心思想是：
Spring Boot
+
Micrometer Tracing
+
Brave / OpenTelemetry
+
Zipkin Reporter
例如常见组合：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-tracing-bridge-brave</artifactId>
</dependency>
<dependency>
<groupId>io.zipkin.reporter2</groupId>
<artifactId>zipkin-reporter-brave</artifactId>
</dependency>
具体依赖组合会随 Spring Boot 大版本变化，新的 Spring Boot 版本也提供了更直接的 Zipkin Starter；Micrometer 官方目前仍支持直接向 Zipkin Report Span。(Micrometer Docs )
十一、采样率是什么？
链路追踪不是一定要记录：
100%
请求。
比如系统：
100000 QPS
如果所有请求全部保存完整 Trace：
100000 个 Trace / 秒
存储压力会非常大。
所以链路系统存在：
Sampling
采样
例如：
10%
意味着大概：
100 个请求
↓
采集 10 个
本地学习可以配置：
management:
tracing:
sampling:
probability: 1.0
代表：
100% 采样
但生产环境应根据流量和存储成本决定比例，而不是机械使用 100%。Spring Boot 当前默认采样比例为 0.1。(Home )
十二、TraceId 为什么应该进入日志？
假设用户投诉：
订单 202609080001 支付失败。
日志可能分散在：
Gateway Log
Order Log
Payment Log
Inventory Log
如果所有日志都带：
traceId=abc123
我们直接：
grep abc123
就能找到整个请求相关日志。
例如：
Order:
traceId=abc123
create order success
Payment：
traceId=abc123
payment timeout
于是马上知道：
同一个请求
Spring Boot 的 Micrometer Tracing 可以把 TraceId、SpanId 和日志 MDC 关联起来。(Home )
十三、实际请求怎么传播 TraceId？
假设：
Order
↓ HTTP
Payment
Order 发请求的时候会携带类似：
trace context headers
Payment 收到以后：
读取 Trace Context
↓
继续当前 Trace
↓
创建自己的 Span
于是：
Order
TraceId=ABC
Payment
TraceId=ABC
但：
SpanId
不同。
这就完成：
Context Propagation
上下文传播。
十四、什么时候特别适合使用 Zipkin？
场景一：微服务调用比较多
例如：
Gateway
↓
Order
↓
Inventory
↓
Payment
↓
MQ
出现性能问题时需要知道具体慢在哪里。
非常适合。
场景二：团队正在学习分布式追踪
Zipkin：
概念清晰
部署简单
UI 简单
Trace 模型直观
非常适合作为第一套链路追踪系统学习。
场景三：只需要链路追踪
你的需求只是：
谁调用谁？
哪里慢？
哪里异常？
一次请求经历了什么？
并不需要一个非常完整的 APM 平台。
Zipkin非常适合。
场景四：已有 Micrometer / Brave / OpenTelemetry
如果项目已经存在：
Micrometer
Brave
OpenTelemetry
将 Trace 上报到 Zipkin非常自然。
十五、什么时候 Zipkin 可能不够？
如果你除了 Trace，还希望统一看到：
服务拓扑
JVM
CPU
GC
数据库
慢 SQL
Metrics
Logs
Profiling
Alert
那么 Zipkin 就不是最完整的选择。
这时候：
SkyWalking
会更加适合。
十六、单体项目需要 Zipkin 吗？
可以使用，但一般价值没有微服务那么明显。
例如单体：
Browser
↓
Spring Boot
↓
MySQL
只有一个应用。
通常：
日志
+
Metrics
+
APM
就已经比较容易定位问题。
但是如果单体大量调用：
Redis
MQ
第三方支付
第三方短信
数据库
HTTP API
链路追踪依然有价值。
所以不是：
单体不能用
而是：
系统调用越分散，链路追踪的价值越大。
十七、Zipkin 最大价值是什么？
一句话：
把原来散落在多个服务里的调用重新拼成一条完整请求链。
没有 Zipkin：
日志 A
日志 B
日志 C
日志 D
你自己猜关系。
有 Zipkin：
Trace ABC
Gateway
└─ Order
├─ Inventory
└─ Payment
关系一目了然。
十八、Zipkin 的局限
Zipkin非常适合：
Distributed Tracing
但它不是万能监控平台。
不要期待它完全代替：
Prometheus
Grafana
ELK
SkyWalking
日志平台
告警平台
链路追踪只是：
Observability
可观测性的一部分。
通常可观测性三大核心信号是：
Metrics
Logs
Traces
Zipkin主要专注：
Traces
十九、面试怎么回答？
如果面试官问：
Zipkin 和 Sleuth 是干什么的？
可以回答：
Spring Cloud Sleuth 是早期 Spring Cloud 中用于分布式链路追踪的组件，负责生成 TraceId、SpanId，并在服务调用之间传播链路上下文；Zipkin 则主要负责接收、存储、查询和展示 Trace 数据。现代 Spring 项目中 Sleuth 的核心能力已经迁移到 Micrometer Tracing，可以通过 Brave 或 OpenTelemetry 等 Tracer 将 Span 上报给 Zipkin。
二十、一句话总结
Sleuth / Micrometer Tracing
=
负责埋点和传播
Zipkin
=
负责收集和展示
最终：
User
↓
Gateway
↓
Order
↓
Payment
↓
Database
↓ Trace Data
Zipkin
所以 Zipkin 最简单的大白话就是：
它是一台“分布式请求行车记录仪”，告诉你一次请求去过哪里、每一站花了多久、最终哪里出了问题。
博客二：SkyWalking 入门详解：链路追踪、APM、服务拓扑与性能监控
前言
理解了 Zipkin 以后，再看 SkyWalking 就容易很多。
Zipkin 最核心的是：
Trace
而 SkyWalking 想解决的问题更大：
我不只想看一次请求经过了什么服务，我还想知道整个分布式系统现在到底健不健康。
例如：
哪个服务 QPS 最高？
哪个接口最慢？
哪些请求报错？
哪个 SQL 最慢？
服务之间是什么调用关系？
JVM 状态怎么样？
哪里出现性能瓶颈？
Trace、Metrics、Logs 能不能关联起来？
这时候就出现：
Apache SkyWalking
Apache SkyWalking 当前定位已经是完整的云原生可观测性平台，将分布式追踪、Metrics、Logs、Profiling 和告警等能力放到同一个平台中。(Apache SkyWalking )
一、什么是 SkyWalking？
一句话：
SkyWalking 是一套 APM 和可观测性平台。
APM：
Application Performance Monitoring
应用性能监控。
它主要帮助我们解决：
系统慢不慢？
哪里慢？
为什么慢？
谁调用谁？
哪里报错？
系统运行状态怎么样？
二、SkyWalking 能做什么？
核心能力可以理解成：
SkyWalking
│
├── Distributed Tracing
│
├── Metrics
│
├── Logs
│
├── Service Topology
│
├── Profiling
│
└── Alerting
官方当前把 Trace、Metrics、Logs、Profiling、Alarm 等都纳入同一可观测性平台。(Apache SkyWalking )
三、第一个能力：链路追踪
比如：
Gateway
↓
Order
↓
Inventory
↓
Payment
SkyWalking 可以显示：
Trace ABC
Gateway 20ms
└─ Order 200ms
├─ User 30ms
├─ Stock 50ms
└─ Payment 100ms
这部分和：
Zipkin
类似。
四、第二个能力：服务拓扑
这是 SkyWalking 非常直观的能力。
假设你的微服务很多：
Gateway
↓
Order
↓
Inventory
↓
Payment
还有：
Order → User
Order → Coupon
Payment → Bank
SkyWalking 可以根据实际调用数据形成服务依赖关系。
概念上：
User
↑
│
Gateway ─────→ Order ─────→ Inventory
│
├──────→ Coupon
│
↓
Payment
↓
Bank
你不用自己画架构图就能看到：
运行中的系统实际上是怎么调用的。
五、第三个能力：Metrics
Trace 回答：
这一次请求发生了什么？
Metrics 回答：
整个系统最近整体怎么样？
例如：
Order Service
QPS: 800
P95: 220ms
Error Rate: 0.5%
我们就知道：
当前流量
响应速度
失败情况
六、P95 是什么？
假设 100 个请求。
响应时间：
大多数：
100ms
少数：
500ms
几个：
3000ms
平均值有时候会欺骗人。
于是 APM 经常使用：
P95
P99
例如：
P95 = 500ms
可以粗略理解：
95% 的请求响应时间不超过大约 500ms。
比单纯平均值更能帮助我们观察尾部延迟。
七、第四个能力：Logs
SkyWalking 还可以把日志和 Trace 联系起来。
例如：
TraceId = ABC
找到：
Payment Service
再找到：
ERROR
第三方支付请求超时
这样：
Trace
+
Log
就可以关联分析。
SkyWalking 官方将日志和 Trace 上下文关联作为平台的重要能力之一。(Apache SkyWalking )
八、第五个能力：Profiling
这个能力解决更深入的问题：
我已经知道这个接口慢了，但是为什么慢？
例如：
/api/order/create
耗时：
5 秒
继续分析可能发现：
SQL
4.2 秒
或者：
某个 Java 方法
CPU 占用特别高
Profiling 就是在进一步帮助我们分析：
CPU
线程
方法调用
热点代码
等性能问题。
九、SkyWalking 的核心架构
Java 项目中最经典的结构：
Java Application
↓
SkyWalking Agent
↓
SkyWalking OAP
↓
Storage
↓
SkyWalking UI
这四层一定要搞明白。
十、Java Agent 是什么？
SkyWalking Java 项目最经典的接入方式：
Java Agent
也就是：
-javaagent
启动：
java \
-javaagent:/path/to/skywalking-agent.jar \
-jar order-service.jar
SkyWalking 官方 Java Agent 当前可以采集 Trace、Metrics、Logs/Event、Profiling 等信息，并通过插件支持大量 Java 框架和中间件。(Apache SkyWalking )
这也是 SkyWalking 特别舒服的地方：
很多情况下，不需要你在 Controller、Service 每个方法里面手写埋点代码。
十一、Agent 到底干什么？
比如你有：
@RestController
public class OrderController {
}
还有：
Feign
MySQL
Redis
Dubbo
HTTP Client
Agent 可以通过对应插件对这些框架进行自动 Instrumentation。
于是：
HTTP Request
↓
Controller
↓
Feign
↓
Remote Service
↓
JDBC
这些信息自动形成 Span。
可以把 Agent 想象成：
偷偷跟在 JVM 后面的观察员。
十二、什么是 OAP？
OAP：
Observability Analysis Platform
可以理解成：
SkyWalking 的大脑。
Agent 采集：
Trace
Metrics
Logs
然后发送给：
OAP
OAP 负责：
接收
分析
聚合
计算
告警
存储
典型：
Agent
↓
OAP
↓
BanyanDB / Elasticsearch
SkyWalking 当前官方默认体系支持 BanyanDB，同时也可以使用其他存储后端。(Apache SkyWalking )
十三、UI 又是什么？
SkyWalking UI 就是我们真正查看数据的地方。
可以看到：
Dashboard
Service
Endpoint
Topology
Trace
Log
Alarm
例如：
Order Service
点击进去：
QPS
响应时间
成功率
调用关系
Trace
整个运行情况一目了然。
十四、完整数据流
所以：
用户请求
↓
Order Service
│
│ Java Agent
↓
采集 Trace/Metrics
↓
OAP
↓
Storage
↓
UI
注意：
业务请求：
Order
↓
Payment
并不经过 OAP。
OAP 收到的是：
Observability Data
所以不要理解成：
Order
↓
OAP
↓
Payment
不是。
十五、如何快速运行 SkyWalking？
官方当前提供 Docker 快速启动方案，可以一次启动：
Storage
+
OAP
+
UI
官方快速启动文档也提供了包含 BanyanDB、OAP 和 UI 的 Docker Compose 方案；其中常见 OAP gRPC 端口为 11800、HTTP 为 12800。(Apache SkyWalking )
本地学习推荐直接按照官方 Docker Quick Start 使用，而不是第一次就自己手工搭整个生产集群。
十六、Java 服务如何接入？
下载 SkyWalking Java Agent 后，设置两个最重要的信息：
服务叫什么？
例如：
order-service
以及：
OAP 在哪里？
例如：
127.0.0.1:11800
然后：
java \
-javaagent:/opt/skywalking-agent/skywalking-agent.jar \
-Dskywalking.agent.service_name=order-service \
-Dskywalking.collector.backend_service=127.0.0.1:11800 \
-jar order-service.jar
Agent 官方文档要求配置服务名称和 OAP 地址，并将 -javaagent 参数放到应用启动参数中。(Apache SkyWalking )
十七、三个服务怎么办？
假设：
user-service
order-service
payment-service
分别：
User
↓
Agent
↓
OAP
Order
↓
Agent
↓
OAP
Payment
↓
Agent
↓
OAP
最后：
OAP
/ | \
/ | \
User Order Payment
SkyWalking 根据 Trace Context 就能把：
Order → Payment
重新关联起来。
十八、一个实际排错案例
现在用户投诉：
下单特别慢。
进入 SkyWalking。
看到：
Create Order
总耗时：
7200ms
打开 Trace：
Gateway 10ms
└─ Order 200ms
├─ User 50ms
├─ Inventory 100ms
└─ Payment 6800ms
于是：
Payment
明显有问题。
继续进去：
Payment
↓
Third Party HTTP
↓
6500ms
最终定位：
第三方支付 API 很慢。
从：
用户说“下单慢”
到：
第三方支付 API 慢
可能几分钟就完成。
这就是 APM 的真正价值。
十九、SkyWalking 特别适合什么场景？
场景一：中大型微服务
例如：
20
50
100+
个服务。
人工查日志已经非常痛苦。
SkyWalking 很有价值。
场景二：生产环境性能排查
经常遇到：
偶发慢请求
服务间超时
调用链异常
数据库慢
第三方接口慢
非常适合。
场景三：需要服务拓扑
系统经过几年开发以后：
谁调用谁
开发人员自己都快说不清了。
SkyWalking 可以通过实际流量生成调用关系。
场景四：希望统一 APM
如果不仅需要：
Trace
还需要：
Metrics
Logs
Profiling
Topology
Alarm
SkyWalking 比纯链路系统更加完整。
场景五：多语言系统
例如公司同时存在：
Java
Go
Python
Node.js
PHP
SkyWalking 当前提供多语言 Agent/Probe，并支持云原生和 eBPF 等观测方式。(Apache SkyWalking )
这种大型异构系统非常适合统一可观测性平台。
二十、单体项目可以用 SkyWalking 吗？
当然可以。
例如：
Spring Boot
↓
Redis
↓
MySQL
↓
第三方 API
SkyWalking 依然可以帮助观察：
接口耗时
JVM
SQL
第三方调用
Trace
但是如果：
3个人使用的后台
几十 QPS
系统特别简单
直接上：
完整 SkyWalking 集群
可能有点重。
所以：
可以用，不代表一定值得用。
二十一、什么时候没必要上 SkyWalking？
例如：
个人博客
非常简单 CRUD
低并发内部系统
只有一个非常小的服务
这时候：
日志
+
Actuator
+
简单 Metrics
可能已经足够。
架构不是组件越多越高级。
真正应该问：
现在排查线上问题是否已经困难到需要 APM？
二十二、SkyWalking 和 Zipkin 怎么选？
非常重要。
| 能力 | Zipkin | SkyWalking |
|---|---|---|
| Trace | 强 | 强 |
| Trace 学习 | 很适合 | 可以 |
| 部署复杂度 | 较低 | 较高 |
| 服务拓扑 | 基础 | 强 |
| Metrics | 非核心 | 强 |
| Logs | 非核心 | 支持 |
| Profiling | 非核心 | 支持 |
| Alarm | 非核心 | 支持 |
| APM | 相对轻量 | 完整 |
| 大型微服务观测 | 可以 | 更适合 |
简单说：
我主要想看 Trace
↓
Zipkin
如果：
我要一整套 APM
↓
SkyWalking
二十三、两者是不是一定不能一起用？
不是。
技术上完全可以共存，而且 SkyWalking 本身也支持多种遥测协议和 Zipkin 格式。(Apache SkyWalking )
但是正常项目不应该无脑：
Zipkin
+
SkyWalking
+
Jaeger
+
另外一套 Trace
全部重复采集。
否则：
Agent 开销
存储成本
维护成本
都会增加。
正常应该明确：
谁是主要 Trace Backend / Observability Platform。
二十四、SkyWalking 和 Sentinel 有什么区别？
这两个经常一起出现在 Spring Cloud Alibaba 架构图里。
Sentinel：
限流
熔断
降级
解决：
系统怎么自我保护？
SkyWalking：
Trace
Metrics
Topology
解决：
系统现在发生了什么？
可以记：
Sentinel
=
治理
SkyWalking
=
观察
比如 Payment Service 很慢。
SkyWalking：
Payment P95 = 5s
告诉你：
Payment 慢了。
Sentinel：
触发熔断
负责：
别继续把 Order 一起拖死。
这两个反而很适合一起存在。
二十五、和前面学过的所有组件串起来
现在你的微服务架构可以真正画完整了：
Internet
│
↓
WAF
│
↓
Gateway
│
Sentinel
│
┌───────────────┼───────────────┐
↓ ↓ ↓
User Order Payment
Service Service Service
↑ ↑ ↑
└───────────────┼───────────────┘
│
Nacos / Eureka
User / Order / Payment
│
│ Agent
↓
SkyWalking
↓
Trace / Metrics
Logs / Topology
分别：
WAF
→ 防攻击
Gateway
→ 请求入口
Nacos / Eureka
→ 服务注册发现
Sentinel
→ 限流熔断
SkyWalking
→ 可观测性、排障
这时候你之前学的东西就不再是几个孤零零的名词了。
二十六、什么时候我会选择 SkyWalking？
如果系统出现下面几个条件，我会认真考虑：
服务越来越多
线上问题难定位
经常需要跨服务查日志
性能问题越来越明显
需要服务拓扑
需要统一 Trace + Metrics + Logs
团队有运维能力维护 APM
反过来，如果：
一个简单 Spring Boot
+
几个 CRUD
+
10 个内部用户
没必要为了“技术栈完整”强行上。
二十七、面试怎么回答 SkyWalking？
可以回答：
Apache SkyWalking 是一套面向分布式、云原生系统的 APM 和可观测性平台。Java 应用常通过 Java Agent 进行无侵入或低侵入式数据采集，将 Trace、Metrics 等遥测数据发送到 OAP 后端，由 OAP 进行分析和聚合并写入存储，再通过 UI 展示服务拓扑、调用链、接口性能和异常等信息。它主要用于微服务链路追踪、性能分析、故障定位和生产环境监控。
二十八、一句话总结 SkyWalking
如果只允许说一句：
SkyWalking 就是微服务系统的“体检中心 + 行车记录仪 + 监控室”，既能看到一次请求发生了什么，也能看到整个系统长期运行得怎么样。
最后把两篇技术放在一起
你现在不要记成：
Zipkin
SkyWalking
都是链路追踪
所以一样
应该理解成：
Zipkin
↓
核心专注 Trace
↓
轻量、清晰
而：
SkyWalking
↓
Trace
+
Metrics
+
Logs
+
Topology
+
Profiling
+
Alerting
↓
完整 APM / Observability
如果是学习链路追踪原理：
推荐先学 Trace → Span → TraceId → Zipkin。
如果是真正理解生产微服务监控：
再学习 SkyWalking Agent → OAP → Storage → UI。
这样学习顺序非常顺：
为什么需要链路追踪
↓
Trace / Span
↓
Zipkin
↓
Micrometer Tracing
↓
SkyWalking
↓
APM / Observability
↓
Metrics + Logs + Traces
把这一条打通之后，你以后再碰到 OpenTelemetry、Jaeger、Prometheus、Grafana、ELK，就会发现它们其实都属于更大的“可观测性”知识体系。