1、概述

Zipkin 是一个开源的分布式追踪系统。在微服务架构下，它用于帮助收集排查潜在问题的时序数据。它同时管理数据收集和数据查询。Zipkin 的设计基于 Google Dagger 论文。

2、架构

追踪器驻留在你的应用程序里，并且记录发生操作的时间和元数据。他们经常装配在库上，所以对用户来说是透明的。举个例子，一个装配过的 Web 服务器，会在接收请求和发送响应进行记录。收集的追踪数据叫做 Span（跨度）。

生产环境中的装配器应该是安全并且低负载的。为此，带内（in-band）只传输 ID，并且告诉接收器仍有一个追踪在处理。完成的跨度在带外（out-of-band）汇报给 Zipkin，类似于应用程序异步汇报指标一样。

举个例子，当追踪一个操作的时候，该操作对外发送了一个 HTTP 请求，那么，为了传输 ID 就会添加一些额外的头部信息。头部信息并不是用于发送像是操作明这样的详细信息的。

装配应用中用于向 Zipkin 发送数据的组件叫做 Reporter。Reporter 通过 Transport 发送追踪数据到 Zipkin 的 Collector，Collector 持久化数据到 Storage 中。之后，API 从 Storage 中查询数据提供给 UI。

下面的图表描述了整个流程：

2.1 Transport

装配库发送的跨度必须由装配的服务传输到 Collector。 有三种主要的传输类型：HTTP、Scribe 和 Kafka。更多信息查看跨度接收器。

共有四个组件构成了 Zipkin：

1）collector

2）storage

3）search

4）web UI

2.2 Zipkin Collector

一旦追踪数据抵达 Zipkin Collector 守护进程，Zipkin Collector 为了查询，会对其进行校验、存储和索引。

2.3 Storage

Zipkin 最初是构建在将数据存储在 Cassandra 中，因为 Cassandra 易跨站，支持灵活的 schema，并且在 Twitter 内部被大规模使用。然而，我们将这个组件做成了可插拔式的。在 Cassandra 之外，我们原生支持 ElasticSearch 和 MySQL。可作为第三方扩展提供给其它后端。

2.3 Zipkin 查询服务

一旦数据被存储索引，我们就需要一种方式提取它。查询守护进程提供了一个简单的 JSON API 查询和获取追踪数据。API 的主要消费者就是 Web UI。

2.3 Web UI

我们创建了一个用户图形界面为追踪数据提供了一个漂亮的视图。Web UI 提供了基于服务、时间和标记（annotation）查看追踪数据的方法。注意：UI 没有内置的身份认证功能。

3、ZipKin安装与启动

下面通过三种方式分别来介绍zipkin的安装与启动

2.1 Docker

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

2.2 Java

1. wget -O zipkin.jar 'https://search.maven.org/remote_content?g=io.zipkin.java&a=zipkin-server&v=LATEST&c=exec'
2. java -jar zipkin.jar

2.3 源码方式

1. # get the latest source
2. git clone https://github.com/openzipkin/zipkin
3. cd zipkin
4. # Build the server and also make its dependencies
5. ./mvnw -DskipTests--also-make -pl zipkin-server clean install
6. # Run the server
7. java -jar ./zipkin-server/target/zipkin-server-*exec.jar

4、Sleuth入门

4.1 简介

Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案，并且兼容支持了 zipkin，你只需要在pom文件中引入相应的依赖即可。

4.2 相关概念

Spring Cloud Sleuth 为Spring Cloud提供了分布式根据的解决方案。它大量借用了Google Dapper的设计。先来了解一下Sleuth中的术语和相关概念。Spring Cloud Sleuth采用的是Google的开源项目Dapper的专业术语。1）Span：基本工作单元，例如，在一个新建的span中发送一个RPC等同于发送一个回应请求给RPC，span通过一个64位ID唯一标识，trace以另一个64位ID表示，span还有其他数据信息，比如摘要、时间戳事件、关键值注释(tags)、span的ID、以及进度ID(通常是IP地址) span在不断地启动和停止，同时记录了时间信息，当你创建了一个span，你必须在未来的某个时刻停止它。

2）Trace：一系列spans组成的一个树状结构，例如，如果你正在跑一个分布式大数据工程，你可能需要创建一个trace。3）Annotation：用来及时记录一个事件的存在，一些核心annotations用来定义一个请求的开始和结束

3.1、cs - Client Sent -客户端发起一个请求，这个annotion描述了这个span的开始

3.2、sr - Server Received -服务端获得请求并准备开始处理它，如果将其sr减去cs时间戳便可得到网络延迟

3.3、ss - Server Sent -注解表明请求处理的完成(当请求返回客户端)，如果ss减去sr时间戳便可得到服务端需要的处理请求时间

3.4、cr - Client Received -表明span的结束，客户端成功接收到服务端的回复，如果cr减去cs时间戳便可得到客户端从服务端获取回复的所有所需时间

4.3链路追踪Sleuth入门（1） 配置依赖修改微服务工程引入Sleuth依赖

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-sleuth</artifactId>

</dependency>

（2） 修改配置文件修改application.yml添加日志级别logging:

level:

root: INFO

org.springframework.web.servlet.DispatcherServlet: DEBUG

org.springframework.cloud.sleuth: DEBUG

每个微服务都需要添加如上的配置。启动微服务，调用之后，我们可以在控制台观察到sleuth的日志输出。

其中 ff8ff8b803a3b558 是TraceId，后面跟着的是SpanId，依次调用有一个全局的TraceId，将调用链路串起来。仔细分析每个微服务的日志，不难看出请求的具体过程。

查看日志文件并不是一个很好的方法，当微服务越来越多日志文件也会越来越多，通过Zipkin可以将日志聚合，并进行可视化展示和全文检索。

4.4、Zipkin+Sleuth整合

通过查看日志分析微服务的调用链路并不是一个很直观的方案，结合zipkin可以很直观地显示微服务之间的调用关系。（1）客户端添加依赖客户端指的是需要被追踪的微服务<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-zipkin</artifactId>

</dependency>

（2）修改客户端配置文件zipkin:

base-url: http://127.0.0.1:9411/ #zipkin server的请求地址

sender:

type: web #请求方式,默认以http的方式向zipkin server发送追踪数据

sleuth:

sampler:

probability: 1.0 #采样的百分比

指定了zipkin server的地址，下面指定需采样的百分比，默认为0.1，即10%，这里配置1，是记录全部的sleuth信息，是为了收集到更多的数据（仅供测试用）。在分布式系统中，过于频繁的采样会影响系统性能，所以这里配置需要采用一个合适的值。（3） 测试以此启动每个微服务，启动Zipkin Service。通过浏览器发送一次微服务请求。打开 Zipkin Service控制台，我们可以根据条件追踪每次请求调用过程

单击该trace可以看到请求的细节