前言

Github：https://github.com/HealerJean

博客：http://blog.healerjean.com

1、为什么需要链路追踪

随着业务的发展，系统规模也会越来越大，各微服务间的调用关系也越来越错综复杂。通常一个客户端发起的请求在后端系统中会经过多个不同的微服务调用来协同产生最后的请求结果，在复杂的微服务架构系统中，几乎每一个前端请求都会形成一条复杂的分布式服务调用链路，在每条链路中任何一个依赖服务出现延迟过高或错误的时候都会引起请求最后的失败。

这时候，对于每一个请求，全链路调用的跟踪就变得越来越重要，通过实现对请求调用的跟踪可以帮助我们快速发现错误根烟以及监控分析每条链路上的性能瓶颈。

2、sleuth与Zipkin关系

spring cloud提供了spring-cloud-sleuth-zipkin来方便集成zipkin实现（指的是Zipkin Client，而不是Zipkin服务器），该jar包可以通过spring-cloud-starter-zipkin依赖来引入。

3、打印 traceId 意义

分布式环境下，微服务之间的调用错综复杂，如果突然爆出一个错误，虽然有日志记录，但到底是哪个服务出了问题呢？是前端传的参数错误，还是系统X或系统Y提供的接口导致？在这种情况下，错误排查起来就非常费劲。

为了追踪一个请求完整的流转过程，可以给每次请求分配一个唯一的 traceId，当请求调用其他服务时，通过传递这个 traceId。在输出日志时，将这个 traceId 打印到日志文件中，再使用日志分析工具（ELK）从日志文件中搜索，使用 traceId 就可以分析一个请求完整的调用过程，若更进一步，还可以做性能分析。

4、相关术语

4.1、Span

Span 是一个基本的 工作单元，用于描述一次 RPC 调用，Span 通过一个 64 位的 spanId 作为 唯一标识。

Zipkin 中的 Span 还有其他数据信息，比如 摘要、时间戳事件、关键值注释 (tags) 以及 进度 ID (通常是 IP 地址)。Span 在不断的启动和停止，同时记录了 时间信息，一个 Span 创建后，必须在未来的某个时刻停止它。

4.2、Trace

一系列 Span 组成的一个 树状结构。例如，如果你正在跑一个大型 分布式系统，可能需要创建一个 Trace。