为什么要服务追踪？我们在开发中经常会碰到这样的问题，我们调用别人的服务A耗时很多，这个时候我就去联系服务A的负责人让他帮排查下问题所在，但是服务A的负责人也很头疼，说他的服务也调用了别人的服务B、C、D等等，那这个时候排查就非常麻烦了，所以我们需要进行服务追踪~

1.Spring Cloud Sleuth

1.1pom.xml

        <!--包含sleuth和zipkin-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-zipkin</artifactId>
        </dependency>

1.2yaml配置文件

spring:
  zipkin:
    base-url: http://zipkin:9411/
    sender:
      type: web
  sleuth:
    sampler:
      probability: 1

  这里多讲一个就是sampler.probability，是因为在发生服务调用的时候，sleuth会通过采样的方式来获取服务调用时间的，sleuth默认是10%的抽样统计，为什么只有10%，假设说每个请求调用都进行采样的，会耗费系统的性能，所以默认10%，但是我们这里为了方便观察，将采样率写成了100%

1.3启动zipkin Server

  这里建议大家使用docker来启动zipkin Server非常快速

2.分布式追踪系统

2.1核心步骤

2.1.1数据采集

  数据采集过程中，由于各个系统的API不兼容，导致如果我们希望切换追踪系统，往往会有很大的改动，因此我们引入了OpenTracing规范，以解决不同分布式追踪系统API不兼容的问题。OpenTracing的优势在于提供了平台无关、厂商无关的API，使得开发人员便于切换追踪系统。OpenTracing来自于大名鼎鼎的CNCF，现有的ZIPKIN、TRACER、JAEGER、GRPC等等都跟进OpenTracing。OpenTracing数据模型中重要的概念就是trace--调用链，是通过归属此调用链的span来定义的。span和trace都是谷歌的开源项目。这里面还有一个专业术语叫Annotation，Annotation是用来即时记录一个事件的，一些核心注解用来定义一个请求的开始和结束，可以理解成span生命周期中重要时刻的数据快照，比如一般包含发生时刻、事件类型等信息。事件类型一共有四种:
1.cs：客户端发起请求的时间
2.cr：客户端收到处理完请求的时间
3.ss：服务端处理完逻辑的时间
4.sr：服务端收到调用端请求的时间
所以客户端调用时间=cr-cs，服务端处理时间=sr-ss

2.1.2数据存储

2.1.3查询展示

3.Zipkin

  ZipKin是twitter的开源项目，其架构图如下

zipkin架构图

ZipKin中的关键东西就是Collector、Storage、API、UI，Collection就是收集调用新，Storage存储这些调用信息，默认是放在内存中的，如果怕重启丢失可以放到数据库中，API是暴露给外部访问采集统计信息的，UI是为了方便展示数据采样相信的模块。下图是zipkinUI的一个截图：

image.png

3.1zipkin中的几个关键概念

3.1.1traceId

  全局的跟踪Id，是跟踪的入口点，根据需求来决定在哪里生成traceId，比如我们常见的一个Http请求，入口是web应用，结束点就是请求的返回点。

3.1.2spanId

  下一层的请求跟踪Id，一个traceId可以包含一个以上的spanId。

3.1.3parentId

  上一次请求跟踪Id，用来将前后请求串联起来。