微服务架构是一个分布式架构，它按业务划分服务单元，一个分布式系统往往有很多个服务单元。由于服务单元数量众多，业务的复杂性，如果出现了错误和异常，很难去定位。主要体现在，一个请求可能需要调用很多个服务，而内部服务的调用复杂性，决定了问题难以定位。所以微服务架构中，必须实现分布式链路追踪，去跟进一个请求到底有哪些服务参与，参与的顺序又是怎样的，从而达到每个请求的步骤清晰可见，出了问题，很快定位。
基本术语
Span（跨度）：基本工作单元，发送一个远程调度任务 就会产生一个Span，Span是一个 64位ID唯一标识的，Trace是用另一个64位ID唯一标识的，Span还有其他数据信息，比如摘要、时间戳事件、Span的ID、以及进度ID。
Trace（跟踪）：一系列Span组成的一个树状结构。请求一个微服务系统的API接口，这个 API接口，需要调用多个微服务，调用每个微服务都会产生一个新的Span，所有由这个请求产生的 Span组成了这个Trace。
Annotation（标注）：用来及时记录一个事件的，一些核心注解用来定义一个请求的开始和结束 。这些注解包括以下：
cs - Client Sent -客户端发送一个请求，这个注解描述了这个Span的开始
sr - Server Received -服务端获得请求并准备开始处理它，如果将其sr减去cs时间戳便可得到网络传输的时间。
ss - Server Sent（服务端发送响应）–该注解表明请求处理的完成(当请求返回客户端)，如果ss的时间戳减去sr时间戳，就可以得到服务器请求的时间。
cr - Client Received（客户端接收响应）-此时Span的结束，如果cr的时间戳减去cs 时间戳便可以得到整个请求所消耗的时间
Sleuth配合ZIPKIN的使用
所有服务都加入以下依赖：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>使用docker安装zipkin：docker run -d -p 9411:9411 openzipkin/zipkin
所有微服务加入以下配置：
#服务追踪，url填自己的服务器地址
spring.zipkin.base-url=http://192.168.56.10:9411/
#关闭服务发现
spring.zipkin.discovery-client-enabled=false
spring.zipkin.sender.type=web
#配置采样器
spring.sleuth.sampler.probability=1启动服务，进行一系列业务操作，再进入配置中输入的url：http://192.168.56.10:9411/
Zipkin数据持久化
Zipkin默认是将监控数据存储在内存的，如果Zipkin挂掉或重启的话，那么监控数据就会丢
失。所以如果想要搭建生产可用的Zipkin，就需要实现监控数据的持久化。数据可以存到内存，mysql，elasticsearch和Cassandra中。
Zipkin支持的这几种存储方式中，内存显然是不适用于生产的。而使用 MySQL 的话，当数据量大时，查询较为缓慢，也不建议使用。Twitter官方使用的是Cassandra作为 Zipkin的存储数据库，但国内用Cassandra的公司较少，而且Cassandra相关文档也不多。
综上，故采用Elasticsearch是个比较好的选择。
使用docker进行配置（前提已经安装了Elasticsearch）：
docker run --env STORAGE_TYPE=elasticsearch --env ES_HOSTS=192.168.56.10:9200 openzipkin/zipkin-dependencies
附：使用 es 时 Zipkin Dependencies 支持的环境变量
