在微服务框架中，一个由客户端发起的请求在后端系统中会经过多个不同的的服务节点调用来协同产生最后的请求结果，每一个前段请求都会形成一条复杂的分布式服务调用链路，链路中的任何一环出现高延时或错误都会引起整个请求最后的失败。

愿意了解源码的朋友直接企鹅求求：二一四七七七五六三三

Spring Cloud Sleuth提供了一套完整的服务跟踪的解决方案。Spring Cloud Sleuth借用了Google

Dapper的术语。

Span:工作的基本单位。例如，发送RPC是一个新的跨度，就像发送响应到RPC一样。Span是由一个唯一的64位ID来标识的，而另一个64位ID用于跟踪。span还具有其他数据，如描述、时间戳事件、键值标注(标记)、导致它们的span的ID和进程ID(通常是IP地址)。

可以启动和停止跨度，并跟踪其时间信息。 创建跨度后，必须在将来的某个时刻停止它。

启动跟踪的初始范围称为根跨度。 该范围的ID值等于跟踪ID。

Trace：一组span形成树状结构。 例如，如果运行分布式大数据存储，则可能由PUT请求形成跟踪。

注解：用于及时记录事件的存在。 使用Brave工具，我们不再需要为Zipkin设置特殊事件，以了解客户端和服务器是谁，请求开始的位置以及结束位置。

cs：客户已发送。 客户提出了请求。 此注释表示跨度的开始。

sr：Server Received：服务器端获得请求并开始处理它。 从此时间戳中减去cs时间戳会显示网络延迟。

ss：服务器已发送。 在完成请求处理时（当响应被发送回客户端时）注释。

从此时间戳中减去sr时间戳会显示服务器端处理请求所需的时间。

cr：客户收到了。 表示跨度的结束。 客户端已成功收到服务器端的响应。

从此时间戳中减去cs时间戳会显示客户端从服务器接收响应所需的全部时间。

下图显示了Span和Trace在系统中的外观以及Zipkin注解：

此注释表示当前跨度的Trace Id设置为X，Span Id设置为D.此外，还发生了Client Sent事件。

Trace Id = X Span Id = D Client Sent 下图显示了跨度的父子关系：