sleuth 链路追踪

一：什么是链路追踪

 对于以前的单服务器项目而言，如果一个地方出了问题，很容易去找到。可是对于微服务架构项目来说，因为微服务太多，而且往往是一个微服务调用了很多其他的微服务，如果一个地方出错，就会导致其他的微服务均出现问题，这样时候去排错就很苦难很麻烦。

所以我们可以以日志的形式将每个操作执行的时间都记录下来，这样排除就会简单一些。分布式链路追踪（Distributed Tracing），就是将一次分布式请求还原成调用链路，进行日志记录，性能监控并将一次分布式请求的调用情况集中展示。比如各个服务节点上的耗时、请求具体到达哪台机器上IP、每个服务节点的请求状态200  500等等。

常用的链路追踪组件就是 zipkin，zipkin 由Twitter公司开源，开放源代码分布式的跟踪系统，用于收集服务的定时数据，以解决微 服务架构中的延迟问题，包括：数据的收集、存储、查找和展现《图形化》。该产品结合spring-cloud-sleuth 使用较为简单， 集成很方便， 但是功能较简单。

zipkin是链路追踪组件，sleuth可以记录每一条链路上的所有节点，以及这些节点所在的机器地址，和处理一个业务耗费的时间。

二：sleuth的使用

首先要引入sleuth依赖，因为想将所有微服务的操作业务时间都记录显示，所以可以将sleuth依赖引入到父工程中，或者 common 公共项目中

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>

引入依赖之后，重启所有的微服务，观察控制台们就会发现所有的操作都会被记录下时间，前面的值是Traceid。后面的值是SpanId

Trace (一条完整链路--包含很多span(微服务接口))

由一组Trace Id（贯穿整个链路）相同的Span串联形成一个树状结构。为了实现请求跟踪，当请求到达分布式系统的入口端点时，只需要服务跟踪框架为该请求创建一个唯一的标识（即TraceId），同时在分布式系统内部流转的时候，框架始终保持传递该唯一值，直到整个请求的返回。那么我们就可以使用该唯一标识将所有的请求串联起来，形成一条完整的请求链路。

Span 

代表了一组基本的工作单元。为了统计各处理单元的延迟，当请求到达各个服务组件的时候，也通过一个唯一标识（SpanId）来标记它的开始、具体过程和结束。通过SpanId的开始和结束时间戳，就能统计该span的调用时间，除此之外，我们还可以获取如事件的名称。请求信息等元数据。