大家好，前五篇我们已经搭建了一个“稳定、安全、可管理”的完整微服务基础架构：通过Nacos实现服务注册与统一配置，通过OpenFeign实现服务间通信，通过Resilience4j实现熔断降级、杜绝服务雪崩，通过Spring Cloud Gateway实现统一入口、权限校验与流量控制。但实际开发中，还有一个核心痛点未解决——微服务调用链路长，一旦出现故障（比如接口超时、报错），我们无法快速定位是哪个服务、哪个环节出了问题，排查效率极低。今天就兑现预告，手把手教大家集成Sleuth+Zipkin（链路追踪组合），实现微服务调用链路的全程监控，快速定位故障节点，全程实操，新手跟着走就能掌握！
温馨提示：实操前请确认前提（避免踩坑）：① 已完成前五篇实操，Nacos服务端、gateway-service、user-service、order-service能正常启动、注册、通信，且各组件集成正常；② 版本保持一致：Spring Boot 2.6.13 + Spring Cloud Hoxton.SR12 + Nacos 2.0.7；③ 关闭之前启动的所有服务（Nacos除外），本篇将在原有服务基础上集成Sleuth+Zipkin，无需新建服务；④ 重点注意：Sleuth负责生成链路追踪数据，Zipkin负责展示追踪数据，两者必须配合使用，缺一不可。

一、先搞懂：链路追踪到底是什么？解决什么问题？

前五篇我们的微服务调用链路已经形成：前端 → Gateway（网关） → order-service（订单服务） → user-service（用户服务），这是一个简单的调用链路，但实际开发中，调用链路会更复杂（比如order-service还会调用pay-service、goods-service等）。此时一旦出现问题，就会陷入“排查困境”：

比如：前端访问下单接口（http://localhost:8080/gateway/order/create/1）报错，我们无法确定是Gateway转发失败、order-service处理异常，还是user-service调用超时；也无法知道每个环节的耗时，无法判断是哪个服务拖慢了整个链路。
而Sleuth+Zipkin组合，就是微服务的“故障排查神器”，核心作用是追踪微服务调用链路，记录每个环节的调用情况（是否成功、耗时多久、哪个服务调用哪个服务），并通过可视化界面展示，让我们能快速定位故障节点（比如“order-service调用user-service超时”“Gateway权限校验报错”），大幅提升故障排查效率。

核心组件分工（新手必记，避免混淆）
Sleuth和Zipkin是“搭档关系”，各自负责不同的工作，缺一不可：

  1. Spring Cloud Sleuth（链路追踪器）：嵌入到每个微服务中，负责生成调用链路的追踪数据（比如链路ID、跨度ID），标记每个服务的调用记录（哪个服务发起调用、哪个服务接收调用、调用耗时、是否成功），并将追踪数据发送给Zipkin；

  2. Zipkin（链路展示平台）：独立的服务，负责接收Sleuth发送的追踪数据，存储并通过可视化界面展示调用链路，支持按链路ID、服务名称、时间范围查询，直观展示每个环节的调用情况和故障信息。

关键概念（简单了解，实操无需深入）
新手无需死记硬背，只需理解核心含义，方便后续查看Zipkin界面：

  • 链路ID（Trace ID）：整个调用链路的唯一标识，比如前端发起一次请求，从Gateway到order-service再到user-service，整个过程共用一个Trace ID，通过Trace ID可以查询到完整的调用链路；

  • 跨度ID（Span ID）：每个服务的调用环节的唯一标识，比如“Gateway转发请求”“order-service调用user-service”“user-service处理请求”，每个环节都有一个独立的Span ID，用于标记单个服务的调用情况；

  • 耗时（Duration）：每个调用环节的耗时，比如Gateway转发请求耗时5ms，order-service调用user-service耗时100ms，通过耗时可以快速定位“耗时过长”的服务。

补充：为什么选择Sleuth+Zipkin？
市面上还有其他链路追踪组件（比如SkyWalking、Pinpoint），但Sleuth+Zipkin组合更适合新手入门，核心优势：① 原生适配Spring Cloud：和Nacos、Gateway、OpenFeign等组件无缝集成，配置简单，无需复杂改造；② 轻量级：集成成本低，不占用过多服务器资源；③ 可视化界面友好：Zipkin界面简洁，新手能快速上手查看链路和排查故障；④ 入门门槛低，适合微服务新手搭建基础链路追踪体系（后续进阶篇会讲解SkyWalking）。

二、实操核心：Sleuth+Zipkin集成与故障定位实操

本篇实操分为5个核心步骤，循序渐进，贴合前五篇的微服务场景：① 下载并启动Zipkin服务（独立平台）；② 给所有微服务集成Sleuth+Zipkin依赖（gateway、order、user）；③ 配置Sleuth+Zipkin（Nacos配置中心统一配置）；④ 测试调用链路，生成追踪数据；⑤ 通过Zipkin界面查看链路、定位故障，掌握核心排查技巧。

重点说明：Zipkin是独立服务，无需集成到现有微服务，直接下载启动即可；Sleuth需要嵌入到每个微服务中（gateway-service、order-service、user-service），用于生成和发送追踪数据。

三、第一步：下载并启动Zipkin服务（核心独立服务）

Zipkin是独立的Java服务，无需编译，直接下载Jar包启动即可，步骤简单，新手可快速上手：
3.1 下载Zipkin Jar包
推荐下载稳定版本（和当前Spring Cloud版本兼容），下载地址（复制到浏览器直接下载）：

https://repo1.maven.org/maven2/io/zipkin/zipkin-server/2.24.3/zipkin-server-2.24.3-exec.jar

说明：① 版本选择2.24.3，和Spring Boot 2.6.13、Spring Cloud Hoxton.SR12完美兼容，无需修改；② 下载后保存到电脑任意目录（比如D盘Zipkin目录），记住保存路径，后续启动需要用到。

3.2 启动Zipkin服务
Zipkin无需配置，直接通过命令行启动，步骤如下：

  1. 打开电脑“命令提示符”（CMD），进入Zipkin Jar包所在的目录（比如D盘Zipkin目录，输入命令：cd D:\Zipkin）；

  2. 输入启动命令（复制粘贴即可，无需修改）：

java -jar zipkin-server-2.24.3-exec.jar
  1. 启动成功后，命令行会显示“Started ZipkinServer in XXX seconds”，此时Zipkin服务已启动，默认端口为9411；
  2. 验证Zipkin启动成功：打开浏览器，访问Zipkin界面：http://localhost:9411，能看到Zipkin的查询界面，说明启动成功。

（常见问题：启动失败排查2点：① 电脑未安装Java环境，或Java环境配置错误（需JDK8及以上）；② Jar包下载不完整，重新下载即可；③ 端口9411被占用，关闭占用9411端口的服务，重新启动）

四、第二步：给所有微服务集成Sleuth+Zipkin依赖

我们需要给三个微服务（gateway-service、order-service、user-service）都添加Sleuth+Zipkin依赖，这样每个服务都能生成追踪数据并发送给Zipkin。三个服务的依赖完全一致，逐一添加即可，步骤如下：

4.1 给gateway-service添加依赖
打开gateway-service的pom.xml文件，添加以下依赖（放在标签内）：

<!-- Sleuth 链路追踪依赖，生成追踪数据 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>

<!-- Zipkin 客户端依赖，将Sleuth生成的追踪数据发送给Zipkin -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-sleuth-zipkin</artifactId>
</dependency>

4.2 给order-service添加依赖
打开order-service的pom.xml文件，添加和gateway-service完全一致的依赖（复制上面的依赖，粘贴到标签内即可），无需修改。

4.3 给user-service添加依赖

打开user-service的pom.xml文件，同样添加上述两个依赖，和前两个服务保持一致。

（易错点提醒：
① 漏给某个服务添加依赖，导致该服务无法生成追踪数据，链路不完整；
② 依赖版本不匹配，无需手动指定版本，Spring Cloud会自动匹配当前Hoxton.SR12版本对应的依赖版本；
③ 添加依赖后，务必点击IDEA右侧“Maven→刷新”，下载依赖，避免依赖未加载导致功能失效）

五、第三步：配置Sleuth+Zipkin（Nacos统一配置）

我们延续前五篇的统一配置规范，将Sleuth+Zipkin的配置放在Nacos配置中心，分别给三个微服务添加配置，实现追踪数据的生成和发送，步骤如下：
5.1 配置user-service的Sleuth+Zipkin（Nacos）

  1. 打开Nacos控制台（http://localhost:8848/nacos），进入“配置管理→配置列表”，找到user-service-dev.yml，点击“编辑”；

  2. 在原有配置末尾，添加以下Sleuth+Zipkin配置：

# Sleuth+Zipkin 配置
spring:
  sleuth:
    sampler:
      probability: 1.0  # 采样率，1.0表示采集所有请求（开发环境建议1.0，生产环境可设0.1，减少性能消耗）
  zipkin:
    base-url: http://localhost:9411  # Zipkin服务地址，和Zipkin启动地址一致
    sender:
      type: web  # 发送方式，web表示通过HTTP方式将追踪数据发送给Zipkin
  1. 点击“发布”，配置生效（无需重启服务，Nacos动态更新）。

5.2 配置order-service的Sleuth+Zipkin（Nacos）

  1. 找到order-service-dev.yml，点击“编辑”；

  2. 在原有配置末尾，添加和user-service完全一致的Sleuth+Zipkin配置（复制上面的配置，粘贴即可），无需修改；

  3. 点击“发布”，配置生效。

5.3 配置gateway-service的Sleuth+Zipkin（Nacos）

  1. 找到gateway-service-dev.yml，点击“编辑”；

  2. 在原有配置末尾，添加和上述两个服务完全一致的Sleuth+Zipkin配置，无需修改；

  3. 点击“发布”，配置生效。

配置说明（新手必记，避免踩坑）
4. spring.sleuth.sampler.probability：采样率，取值范围0.01.0，1.0表示采集所有请求，0.5表示采集50%的请求；开发环境建议设为1.0，方便查看所有链路；生产环境可设为0.10.5，减少追踪数据对服务性能的影响；

  1. spring.zipkin.base-url：Zipkin服务的地址，必须和Zipkin启动后的地址一致（http://localhost:9411），否则Sleuth无法将追踪数据发送给Zipkin，Zipkin界面看不到任何链路；

  2. spring.zipkin.sender.type：追踪数据的发送方式，web表示HTTP方式，是默认且最常用的方式，无需修改。

六、第四步：测试调用链路，生成追踪数据

配置完成后，我们启动所有服务，发起请求，生成调用链路，让Sleuth将追踪数据发送给Zipkin，步骤如下：

6.1 启动所有服务（按顺序启动，避免报错）
启动顺序（严格按此顺序，确保服务之间能正常通信）：

  1. 启动Nacos服务端（必须最先启动，确保其他服务能注册）；

  2. 启动Zipkin服务（确保能接收追踪数据）；

  3. 启动user-service（被调用服务，先启动）；

  4. 启动order-service（调用方服务）；

  5. 启动gateway-service（网关服务，最后启动）。

验证所有服务启动成功：Nacos控制台“服务列表”中，三个微服务（gateway-service、order-service、user-service）均为“健康”状态；Zipkin界面能正常访问。

6.2 发起请求，生成链路追踪数据
我们发起两次不同场景的请求，生成两条不同的调用链路，用于后续测试故障定位：

场景1：正常调用链路（所有服务正常，无故障）

  1. 打开Postman，创建GET请求，地址：http://localhost:8080/gateway/order/create/1；

  2. 在请求头中添加有效Token（Authorization: springcloud-token）；

  3. 发送请求，预期结果：请求成功，返回“订单创建成功+用户信息”；

  4. 重复发送2~3次请求，确保Sleuth生成足够的追踪数据，发送给Zipkin。

场景2：故障调用链路（模拟user-service故障，触发Resilience4j降级）

  1. 保持其他服务正常启动，关闭user-service（模拟用户服务故障）；

  2. 继续用Postman发送请求（地址和Token不变）；

  3. 预期结果：请求被降级，返回“订单创建成功+降级提示”；

  4. 发送1~2次请求，生成故障链路的追踪数据。

（补充说明：发送请求后，可查看各个服务的控制台日志，会发现日志中多了“[服务名称,traceId,spanId,采样标识]”的内容，这就是Sleuth生成的追踪标识，比如gateway-service的日志会显示“[gateway-service,abc123,def456,true]”，其中abc123是链路ID，def456是跨度ID）

七、第五步：通过Zipkin界面查看链路、定位故障（核心实操）

Zipkin的核心价值的是“可视化展示链路、快速定位故障”，我们分两个场景，教大家如何查看正常链路、排查故障链路，掌握核心排查技巧：
7.1 查看正常调用链路（场景1）

  1. 打开Zipkin界面（http://localhost:9411），默认进入“查询”页面，无需修改查询条件（默认查询最近10分钟的链路）；

  2. 点击页面右侧“Find Traces”（查询链路），会看到所有正常调用的链路记录（每条记录对应一次请求）；

  3. 点击任意一条链路记录（点击链路ID），进入链路详情页面，能看到完整的调用链路：

调用顺序：gateway-service → order-service → user-service；

每条链路环节会显示：服务名称、调用耗时、调用状态（SUCCESS，绿色表示成功）；

  1. 点击任意一个服务环节（比如order-service），能查看该环节的详细信息（调用方法、耗时、请求地址等），确认每个环节都正常。

核心收获：正常链路中，所有环节的状态都是SUCCESS，耗时合理，能清晰看到请求从网关到各个微服务的流转过程。

7.2 排查故障调用链路（场景2）
我们通过Zipkin，快速定位“user-service故障”的问题，步骤如下：

  1. 保持Zipkin界面打开，点击“Find Traces”，找到故障链路（可通过“服务名称”筛选，选择user-service）；

  2. 点击故障链路记录，进入详情页面，会发现：

  • gateway-service → order-service：调用状态为SUCCESS（绿色），说明网关转发正常，order-service接收请求正常；

  • order-service → user-service：调用状态为ERROR（红色），说明order-service调用user-service失败，耗时异常（可能显示超时）；

  1. 点击红色的“order-service → user-service”环节，查看详细故障信息，会显示故障原因（比如“Connection refused: connect”，表示无法连接到user-service，即user-service未启动）；

  2. 据此可快速定位故障：user-service未启动，导致order-service调用失败，触发降级；此时只需重启user-service，故障即可解决。

Zipkin核心排查技巧（新手必记）
5. 筛选链路：如果链路过多，可通过“Service Name”（服务名称）、“Span Name”（环节名称）、“时间范围”筛选，快速找到目标链路；

  1. 故障判断：红色ERROR表示该环节调用失败，绿色SUCCESS表示调用成功；

  2. 耗时分析：如果链路整体耗时过长，查看每个环节的耗时，耗时最长的环节就是“性能瓶颈”（比如user-service处理请求耗时500ms，可优化user-service的接口）；

  3. 链路ID排查：如果前端/控制台报错，可获取报错日志中的Trace ID（链路ID），在Zipkin中通过Trace ID查询，能快速找到完整的调用链路，定位故障。

八、实操总结与易错点复盘

本篇我们完成了Sleuth+Zipkin的核心实操，掌握了微服务链路追踪的实现方法和故障排查技巧，成功解决了“调用链路长、排查难”的痛点，核心收获如下：

  1. 核心流程：启动Zipkin服务 → 给所有微服务添加Sleuth+Zipkin依赖 → Nacos配置Sleuth+Zipkin → 发起请求生成追踪数据 → Zipkin查看链路、定位故障；

  2. 关键知识点：
    ① Sleuth负责生成追踪数据（链路ID、跨度ID），Zipkin负责展示和分析追踪数据；
    ② 所有微服务都必须集成Sleuth+Zipkin依赖，否则链路不完整；
    ③ 采样率和Zipkin地址是核心配置，配置错误会导致无法生成或查看链路；

  3. 核心价值：快速定位微服务调用链路中的故障节点和性能瓶颈，大幅提升故障排查效率，降低微服务维护成本。

新手必看易错点（重点避坑，结合前五篇补充）：

  1. 漏给某个微服务添加依赖：导致该服务无法生成追踪数据，链路断裂，比如漏给user-service添加依赖，Zipkin中看不到user-service的调用环节；

  2. Zipkin地址配置错误：spring.zipkin.base-url配置错误（比如少写端口、地址写错），导致Sleuth无法将追踪数据发送给Zipkin，Zipkin界面看不到任何链路；

  3. 采样率设为0.0：导致Sleuth不采集任何请求，Zipkin看不到链路，开发环境务必设为1.0；

  4. 服务启动顺序错误：未先启动Nacos和Zipkin，导致微服务启动失败，或无法发送追踪数据；

  5. Zipkin端口被占用：9411端口被其他服务占用，导致Zipkin启动失败，关闭占用端口的服务即可。

九、下一篇预告

前六篇我们已经完成了SpringCloud基础架构的全流程实操，搭建了一个“稳定、安全、可管理、可排查”的完整微服务集群：Nacos（注册+配置）、OpenFeign（通信）、Resilience4j（熔断降级）、Spring Cloud Gateway（统一网关）、Sleuth+Zipkin（链路追踪）。下一篇将讲解微服务的“进阶优化”——负载均衡（Ribbon）+ 服务降级进阶，教大家优化微服务调用性能，进一步提升集群稳定性，适配高并发场景！

如果这篇实操教程对你有帮助，欢迎点赞、收藏、关注，实操过程中遇到任何问题（比如Zipkin看不到链路、无法定位故障、Sleuth依赖报错），都可以在评论区留言，我会逐一回复，帮大家解决新手踩坑问题～

# spring cloud # 微服务 # spring
Logo
亚马逊云科技技术品牌专区

更多推荐

open-code-review Codex 插件教程：对话式调用评审技能指南

本文是一份面向新手的 **open-code-review Codex 插件教程**，教你在 Codex 中通过对话式方式调用 open-code-review 的 AI 代码评审技能。open-code-review 是阿里巴巴开源的 AI 代码评审工具，采用"确定性流水线 + LLM Agent"混合架构，内置多语言评审规则（NPE、线程安全、XSS、SQL 注入等），可在 Codex 里用一

avatar 亚马逊云科技技术品牌专区

OBS Studio 完整指南：免费开源录屏与直播软件从零上手

想做一场像模像样的直播，或者把屏幕内容录成教程视频，但一想到商用软件的订阅费就有些犹豫？其实你不需要花一分钱。OBS Studio 是一款免费开源的直播与录屏软件，支持 Windows、macOS 和 Linux，采集、混音、编码、推流、录制，一条流水线全包了。## 先搞清楚 OBS Studio 是什么OBS Studio 是一个"场景化"的采集合成工具：你把摄像头、窗口、浏览器、图片、

avatar 亚马逊云科技技术品牌专区

如何用MediaCrawler爬取小红书抖音数据？7大平台爬虫从安装到实战完整指南

MediaCrawler 是一个支持小红书、抖音、快手、B站、微博、百度贴吧、知乎的开源自媒体数据采集工具。它能按关键词、按帖子、按创作者主页三种方式抓取笔记/视频内容、评论甚至二级评论，并把结果存成 JSON、CSV、Excel 或数据库。适合做市场调研、竞品监控、内容选题的运营人员，以及想要现成爬虫框架而不想从零写 JS 逆向的开发者。## 从一次"手动抄数据"说起想象这个场景：你负责

avatar 亚马逊云科技技术品牌专区