封面图是 凌晨 3点半起来更文的锁屏桌面。

从上周六 7 号到今天的 11 号，我都在医院，小孩因肺炎已经住院了，我白天和晚上的时间需要照顾娃，只能在娃睡觉的时候肝文了。对了，医院没有宽带和 WiFi，我用的手机开的热点~

这篇主要是理论 + 实战，如何把链路追踪 `Sleuth` + `Zipkin` 加到我的 Spring Cloud 《佳必过》开源项目上。

本篇知识点：

- 链路追踪基本原理

- 如何在项目中轻松加入链路追踪中间件

- 如何使用链路追踪排查问题。

`微服务`架构其实是一个`分布式`的架构，按照业务划分成了多个服务单元。

由于服务单元的`数量`是很多的，有可能几千个，而且业务也会更复杂，如果出现了错误和异常，很难去定位。

比如一个请求需要调用多个服务才能完成整个业务闭环，而内部服务的代码逻辑和业务逻辑比较复杂，假如某个服务出现了问题，是难以快速确定那个服务出问题的。

而如果我们加上了`分布式链路追踪`，去跟踪一个请求有哪些服务参与其中，参与的顺序是怎样的，这样我们就知道了每个请求的详细经过，即使出了问题也能快速定位。

链路追踪组件有 Twitter 的可视化链路追踪组件 `Zipkin`、Google 的 `Dapper`、阿里的 `Eagleeye` 等，而 Sleuth 是 Spring Cloud 的组件。本文主要讲解 Sleuth + Zipkin 结合使用来更好地实现链路追踪。

Spring Cloud Sleuth 借鉴了 Dapper 的术语。为什么能够进行整条链路的追踪？其实就是一个 Trace ID 将 一连串的 Span 信息连起来了。根据 Span 记录的信息再进行整合就可以获取整条链路的信息。

- 大白话：远程调用和 Span `一对一`。

- 基本的工作单元，每次发送一个远程调用服务就会产生一个 Span。

- Span 是一个 64 位的唯一 ID。

- 通过计算 Span 的开始和结束时间，就可以统计每个服务调用所花费的时间。

链路追踪系统定义了一些核心注解，用来定义一个请求的开始和结束，注意是微服务之间的请求，而不是浏览器或手机等设备。注解包括：

- `cs` - Client Sent：客户端发送一个请求，描述了这个请求调用的 `Span` 的开始时间。注意：这里的客户端指的是微服务的调用者，不是我们理解的浏览器或手机等客户端。

- `cs` - Server Received：服务端获得请求并准备开始处理它，如果将其 `sr` 减去 `cs` 时间戳，即可得到网络传输时间。

- `ss` - Server Sent：服务端发送响应，会记录请求处理完成的时间，`ss` 时间戳减去 sr 时间戳，即可得到服务器请求的时间。

- `cr` - Client Received：服务端接收响应，Span 的结束时间，如果 `cr` 的时间戳减去 `cs` 时间戳，即可得到一次微服务调用所消耗的时间，也就是一个 `Span` 的消耗的总时间。

假定三个微服务调用的链路如下图所示：`Service 1` 调用 `Service 2`，`Service 2` 调用 `Service 3` 和 Service 4。


那么链路追踪会在每个服务调用的时候加上 Trace ID 和 Span ID。如下图所示：


**大白话解释：**

- 大家注意上面的颜色，相同颜色的代表是同一个 Span ID，说明是链路追踪中的一个节点。

- 第一步：客户端调用 `Service 1`，生成一个 `Request`，`Trace ID` 和 `Span ID` 为空，那个时候请求还没有到 `Service 1`。

- 第二步：请求到达 `Service 1`，记录了 Trace ID = X，Span ID 等于 A。

- 第三步：`Service 1` 发送请求给 `Service 2`，Span ID 等于 B，被称作 Client Sent，即客户端发送一个请求。

- 第四步：请求到达 `Service 2`，Span ID 等于 B，Trace ID 不会改变，被称作 Server Received，即服务端获得请求并准备开始处理它。

- 第五步：`Service 2` 开始处理这个请求，处理完之后，Trace ID 不变，Span ID = C。

- 第六步：`Service 2` 开始发送这个请求给 `Service 3`，Trace ID 不变，Span ID = D，被称作 Client Sent，即客户端发送一个请求。

- 第七步：`Service 3` 接收到这个请求，Span ID = D，被称作 Server Received。

- 第八步：`Service 3` 开始处理这个请求，处理完之后，Span ID = E。

- 第九步：`Service 3` 开始发送响应给 `Service 2`，Span ID = D，被称作 Server Sent，即服务端发送响应。

- 第十步：`Service 3` 收到 `Service 2` 的响应，Span ID = D，被称作 Client Received，即客户端接收响应。

- 第十一步：`Service 2` 开始返回 响应给 `Service 1`，Span ID = B，和第三步的 Span ID 相同，被称作 Client Received，即客户端接收响应。

- 第十二步：`Service 1` 处理完响应，Span ID = A，和第二步的 Span ID 相同。

- 第十三步：`Service 1` 开始向客户端返回响应，Span ID = A、

- `Service 3` 向 Service 4 发送请求和 `Service 3` 类似，对应的 Span ID 是 F 和 G。可以参照上面前面的第六步到第十步。

**把以上的相同颜色的步骤简化为下面的链路追踪图：**


- 第一个节点：Span ID = A，Parent ID = null，`Service 1` 接收到请求。

- 第二个节点：Span ID = B，Parent ID= A，`Service 1` 发送请求到 `Service 2` 返回响应给 `Service 1` 的过程。

- 第三个节点：Span ID = C，Parent ID= B，`Service 2` 的 中间处理过程。

- 第四个节点：Span ID = D，Parent ID= C，`Service 2` 发送请求到 `Service 3` 返回响应给 `Service 2` 的过程。

- 第五个节点：Span ID = E，Parent ID= D，`Service 3` 的中间处理过程。

- 第六个节点：Span ID = F，Parent ID= C，`Service 3` 发送请求到 Service 4 返回响应给 `Service 3` 的过程。

- 第七个节点：Span ID = G，Parent ID= F，Service 4 的中间处理过程。

通过 Parent ID 即可找到父节点，整个链路就可以进行跟踪追溯了。

大家可以参照我的 GitHub 开源项目 PassJava（佳必过）。

因为我们使用的链路追踪组件 Sleuth 是 Spring Cloud 的组件，所以我们需要引入 Spring Cloud 依赖。

引入链路追踪组件 Sleuth 非常简单，在 pom.xml 文件中引入 Sleuth 依赖即可。

``` xml

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-sleuth</artifactId>

</dependency>

我们先不整合 zipkin 链路追踪可视化组件，而是通过日志的方式来查看链路追踪信息。

``` properties

文件路径：\PassJava-Platform\passjava-question\src\main\resources\application.properties

添加配置：

logging.level.org.springframework.cloud.openfeign=debug

logging.level.org.springframework.cloud.sleuth=debug

启动 passjava-gateway、passjava-question、renren 服务。如下图所示：


打开 Admin 后台，访问题目中心->题目配置页面，可以看到发送了下面的请求：

``` http

打开控制台，可以看到打印出了追踪日志。


说明：

- 当没有配置 Sleuth 链路追踪的时候，INFO 信息里面是 [passjava-question,,,]，后面跟着三个空字符串。

- 当配置了 Sleuth 链路追踪的时候，追踪到的信息是 [passjava-question,504a5360ca906016,e55ff064b3941956,false] ，第一个是 Trace ID，第二个是 Span ID。