博客一：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，就会发现它们其实都属于更大的“可观测性”知识体系。