介绍

Zipkin是一款开源的分布式实时数据追踪系统（Distributed Tracking System），基于 Google Dapper的论文设计而来，由 Twitter 公司开发贡献。其主要功能是聚集来自各个异构系统的实时监控数据。

架构

ZipKin可以分为两部分，一部分是zipkin server，用来作为数据的采集存储、数据分析与展示；zipkin client是zipkin基于不同的语言及框架封装的一些列客户端工具，这些工具完成了追踪数据的生成与上报功能，架构如下：

Zipkin Server主要包括四个模块： （1）Collector 接收或收集各应用传输的数据 （2）Storage 存储接受或收集过来的数据，当前支持Memory，MySQL，Cassandra，ElasticSearch等，默认存储在内存中。 （3）API（Query） 负责查询Storage中存储的数据，提供简单的JSON API获取数据，主要提供给web UI使用 （4）Web 提供简单的web界面

ZipKin几个概念

在追踪日志中，有三个最重要的概念: spanId、traceId、parentId

traceId：用来确定一个追踪链的16字符长度的字符串，在某个追踪链中保持不变。

spanId：区域Id，在一个追踪链中spanId可能存在多个，每个spanId用于表明在某个服务中的身份，也是16字符长度的字符串。

parentId：在跨服务调用者的spanId会传递给被调用者，被调用者会将调用者的spanId作为自己的parentId，然后自己再生成spanId。

其他概念：

name：span的名称，主要用于在界面上展示，一般是接口方法名，name的作用是让人知道它是哪里采集的span，不然某个span耗时高我都不知道是哪个服务节点耗时高timestamp：span创建时的时间戳，用来记录采集的时刻。duration：持续时间，即span的创建到span完成最终的采集所经历的时间，除去span自己逻辑处理的时间，该时间段可以理解成对于该跟踪埋点来说服务调用的总耗时annotations：基本标注列表，一个标注可以理解成span生命周期中重要时刻的数据快照，比如一个标注中一般包含发生时刻（timestamp）、事件类型（value）、端点（endpoint）等信息  事件类型	  cs：客户端/消费者发起请求	  cr：客户端/消费者接收到应答	  sr：服务端/生产者接收到请求	  ss：服务端/生产者发送应答binaryAnnotations：业务标注列表，如果某些跟踪埋点需要带上部分业务数据（比如url地址、返回码和异常信息等），可以将需要的数据以键值对的形式放入到这个字段中。复制代码

下图是一个链路追踪的案例:

1. 用户请求 service1 的 /service1/test 接口。
2. service1 接口中需要调用 service2 的 /service2/test 接口。
3. service2 接口中需要顺序调用 service3 的 /service3/test 接口和 service4 的 /service4/test 接口。