一、前言

我们在使用微服务的时候，往往涉及到各个微服务之间的调用，肯定会存在深度的调用链路，如果出现BUG或者异常，就会让问题定位和处理效率非常低。有了Sleuth ，就可以帮助我们记录、跟踪应用程序中的请求和操作。通常与 Zipkin 配合使用，从而提供更全面的可视化应用程序跟踪和分析功能。

就像ElasticSearch和Kibana一样！

复杂的链路调用如下图所示:

在继续往下看的同时，需要你具备Springboot整合Nacos构建一个聚合项目的能力。

当然如果不想自己来，小编也给大家准备好了。大家可以下载运行一下，开始下面的实战！

防止Github访问不了，这里把代码提交到了Gitee。

cloud-sleuth-zipkin-demo代码下载地址：https://gitee.com/wang-zhenjun/cloud-sleuth-zipkin-demo

二、Spring Cloud Sleuth 介绍

1、简介

Spring Cloud Sleuth 是 Spring Cloud 生态系统的一部分，它是一个分布式追踪解决方案，用于监视微服务架构中的请求流程，并帮助开发者跟踪请求在不同微服务之间的传播路径。

Sleuth主要用于解决微服务架构中的分布式系统跟踪和调试问题。

官网文档：https://docs.spring.io/spring-cloud-sleuth/docs/2.2.8.RELEASE/reference/html/。

2、核心概念

我们可以看一下官网的图片：

简单名词介绍：

?

cs：「客户端发送」，客户已提出请求。该注释指示跨度的开始。sr：「服务器已接收」，服务器端收到请求并开始处理。从此时间戳中减去cs时间戳即可得出网络延迟。ss：「服务器发送」，在请求处理完成时（当响应发送回客户端时）进行注释。从这个时间戳中减去sr时间戳就可以得出服务器端处理请求所需的时间。cr：「客户端已收到」，表示跨度的结束。客户端已成功收到服务器端的响应。从此时间戳中减去cs时间戳即可得出客户端从服务器接收响应所需的整个时间。

?

详细信息可以看官网介绍，总结一下：

「官网的图，每一个代表一个组件，他们之间进行调用，画的少了Trace Id，加上就好了。」

每个组件都会生成一个 Trace Id（全局唯一），还会有 Span Id、Parent Id 三部分组成。链路上的所有组件组成一个完整的 Trace。

「注意：」

「头链路Parent Id = null，其余的都指向上一个组件的Span Id，从而形成链路。」

「一次链路调用所有的组件Trace Id都是一样的。」

「这里说的组件就是一个个的微服务！」

三、 Zipkin介绍和搭建

1、定义

Zipkin 是一个分布式追踪系统。它有助于收集解决服务架构中的延迟问题所需的计时数据。功能包括该数据的收集和查找。

Zipkin官网地址：https://zipkin.io/。

2、核心概念

尽管Sleuth 和 Zipkin有些术语和概念中有相似之处，但它们是两个不同的工具，各自有自己的实现和用途。

「Spring Cloud Sleuth 用于生成和传播跟踪信息，而 Zipkin 用于收集、存储、查询和可视化这些信息。它们可以协同工作，但也可以独立使用。」

3、docker搭建

官方有三种方式搭建，推荐使用：「如果您熟悉 Docker，这是首选的启动方法。」

Docker Zipkin项目能够构建 docker 镜像、提供脚本和docker-compose.yml 用于启动预构建镜像的脚本。

https://github.com/openzipkin/docker-zipkin/blob/master/docker-compose.yml。

最快的启动方式是直接运行最新的镜像：

docker run -d -p 9411:9411 openzipkin/zipkin