Spring Cloud构建微服务架构：分布式服务跟踪

通过上一篇《分布式服务跟踪（入门）》的例子，我们已经通过Spring Cloud Sleuth往微服务应用中添加了实现分布式跟踪具备的基本要素。下面通过本文来详细说说实现分布式服务跟踪的一些要点。

分布式系统中的服务跟踪在理论上并不复杂，它主要包括下面两个关键点：

为了实现请求跟踪，当请求发送到分布式系统的入口端点时，只需要服务跟踪框架为该请求创建一个唯一的跟踪标识，同时在分布式系统内部流转的时候，框架始终保持传递该唯一标识，直到返回给请求方为止，这个唯一标识就是前文中提到的 。通过 的记录，我们就能将所有请求过程日志关联起来。

为了统计各处理单元的时间延迟，当请求达到各个服务组件时，或是处理逻辑到达某个状态时，也通过一个唯一标识来标记它的开始、具体过程以及结束，该标识就是我们前文中提到的Span ID，对于每个Span来说，它必须有开始和结束两个节点，通过记录开始Span和结束Span的时间戳，就能统计出该Span的时间延迟，除了时间戳记录之外，它还可以包含一些其他元数据，比如：事件名称、请求信息等。

在快速入门示例中，我们轻松实现了日志级别的跟踪信息接入，这完全归功于 组件的实现。在Spring Boot应用中，通过在工程中引入 依赖之后， 它会自动的为当前应用构建起各通信通道的跟踪机制，比如：

通过诸如RabbitMQ、Kafka（或者其他任何Spring Cloud Stream绑定器实现的消息中间件）传递的请求

通过Zuul代理传递的请求

通过 发起的请求

在快速入门示例中，由于 对 发起的请求是通过 实现的，所以 组件会对该请求进行处理，在发送到 之前sleuth会为在该请求的Header中增加实现跟踪需要的重要信息，主要有下面这几个（更多关于头信息的定义我们可以通过查看 的源码获取）：

X-B3-TraceId：一条请求链路（Trace）的唯一标识，必须值

X-B3-SpanId：一个工作单元（Span）的唯一标识，必须值

X-B3-ParentSpanId:：标识当前工作单元所属的上一个工作单元，Root Span（请求链路的第一个工作单元）的该值为空

X-B3-Sampled：是否被抽样输出的标志，1表示需要被输出，0表示不需要被输出

X-Span-Name：工作单元的名称

我们可以通过对 的实现做一些修改来输出这些头部信息，具体如下：

通过上面的改造，我们再运行快速入门的示例内容，并发起对 的接口访问，我们可以得到如下输出内容。其中在 的控制台中，输出了当前正在处理的 和 信息。

为了更直观的观察跟踪信息，我们还可以在 中增加下面的配置：

通过将Spring MVC的请求分发日志级别调整为 级别，我们可以看到更多跟踪信息：

完整示例：

读者可以根据喜好选择下面的两个仓库中查看 和 两个项目：

Github：https://github.com/dyc87112/SpringCloud-Learning/

Gitee：https://gitee.com/didispace/SpringCloud-Learning/

如果您对这些感兴趣，欢迎star、follow、收藏、转发给予支持！

本文内容部分节选自我的《Spring Cloud微服务实战》，但对依赖的Spring Boot和Spring Cloud版本做了升级。

更多内容，请点击《Spring Cloud微服务架构汇总》