spring-cloud-sleuth整合zipkin

1、Sleuth（全链路追踪）

1.1、概要

Spring Cloud Sleuth提供了一套完整的服务跟踪的解决方案，并且支持集成了zipkin。

1.2、术语

1.2.1、Trace：

它是由一组有相同Trace ID的Span串联形成一个树状结构。为了实现请求跟踪，当请求到分布式系统的入口端点时，只需要服务跟踪框架为该请求创建一个唯一的跟踪标识（即前文提到的Trace ID），同时在分布式系统内部流转的时候，框架始终保持该传递的唯一标识，直到返回请求为止，我们通过它将所有请求过程中的日志关联起来；

1.2.2、Span：

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

1.2.3、Annotation：

它用于记录一段时间内的事件。

内部使用的最重要的注释是：

• cs - Client Sent - 客户端发送一个请求，这个注解描述了这个Span的开始。
• sr - Server Received - 服务端获得请求并准备开始处理它，其中（sr – cs） 时间戳便可得到网络传输的时间。
• ss - Server Sent （服务端发送响应）– 该注解表明请求处理的完成(当请求返回客户端)， （ss – sr）时间戳就可以得到服务器请求的时间。
• cr - Client Received （客户端接收响应）- 表明此时Span的结束，（cr – cs）时间戳便可以得到整个请求所消耗的时间。

1.3、追踪原理

为了实现请求跟踪，当请求发送到分布式系统的入口端点时，只需要服务跟踪框架为该请求创建一个唯一的跟踪标识，同时在分布式系统内部流转的时候，框架始终保持传递该唯一标识，直到返回给请求方为止，这个唯一标识就是前文中提到的Trace ID。通过Trace ID的记录，我们就能将所有请求过程日志关联起来。

为了统计各处理单元的时间延迟，当请求达到各个服务组件时，或是处理逻辑到达某个状态时，也通过一个唯一标识来标记它的开始、具体过程以及结束，该标识就是我们前文中提到的Span ID，对于每个Span来说，它必须有开始和结束两个节点，通过记录开始Span和结束Span的时间戳，就能统计出该Span的时间延迟，除了时间戳记录之外，它还可以包含一些其他元数据，比如：事件名称、请求信息等。

表示一条请求链路，一条链路通过TraceId作为唯一标识，Span标识发起的请求信息也具有唯一标识，叫做SpanId，各span通过parentId关联起来（后一个Span的parentId就是前一个Span的SpanId）。

2、spring-cloud-sleuth整合zipkin

2.1、docker 安裝服务

docker run -d -p 9411:9411 openzipkin/zipkin

2.2、代码实现

pom

<!--链路追踪-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zipkin</artifactId>
	<version>2.1.0.RELEASE</version>
</dependency>

yml

  spring:
  	application:
     name: gulimall-secondkill
   zipkin:
     base-url: http://192.168.56.10:9411
     sender:
       type: web
       # 取消nacos对zipkin的服务发现
     discovery-client-enabled: false
     #采样取值介于 0到1之间，1则表示全部收集
   sleuth:
     sampler:
       probability: 1

2.3、查询调用链路

可视化页面的地址：http://192.168.56.10:9411/zipkin

2.4、持久化es

Zipkin 默认是将监控数据存储在内存的，如果 Zipkin 挂掉或重启的话，那么监控数据就会丢 失。所以如果想要搭建生产可用的 Zipkin，就需要实现监控数据的持久化。而想要实现数据 持久化，自然就是得将数据存储至数据库。好在 Zipkin 支持将数据存储至：

• 内存（默认）
• MySQL
• Elasticsearch
• Cassandra

Zipkin 支持的这几种存储方式中，内存显然是不适用于生产的，这一点开始也说了。而使用 MySQL 的话，当数据量大时，查询较为缓慢，也不建议使用。Twitter 官方使用的是 Cassandra 作为 Zipkin 的存储数据库，但国内大规模用 Cassandra 的公司较少，而且 Cassandra 相关文 档也不多。 综上，故采用 Elasticsearch 是个比较好的选择，关于使用 Elasticsearch 作为 Zipkin 的存储数 据库的官方文档如下：

elasticsearch-storage： https://github.com/openzipkin/zipkin/tree/master/zipkin-server#elasticsearch-storage
zipkin-storage/elasticsearch https://github.com/openzipkin/zipkin/tree/master/zipkin-storage/elasticsearch

通过 docker 的方式启动

docker run --env STORAGE_TYPE=elasticsearch --env ES_HOSTS=192.168.56.10:9200 openzipkin/zipkin-dependencies

使用 es 时 Zipkin Dependencies 支持的环境变量