Zipkin

1. 简介
Zipkin，是一款开源的分布式实时数据追踪系统。其主要功能是聚集来自各个异构系统的实时监控数据。

2. 架构
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界面
Instrumented client和server是分别使用了ZipKin Client的服务，Zipkin Client会根据配置将追踪数据发送到Zipkin Server中进行数据存储、分析和展示。
3.工作过程
当用户发起一次调用时，Zipkin 的客户端会在入口处为整条调用链路生成一个全局唯一的 trace id，并为这条链路中的每一次分布式调用生成一个 span id。span 与 span 之间可以有父子嵌套关系，代表分布式调用中的上下游关系。span 和 span 之间可以是兄弟关系，代表当前调用下的两次子调用。一个 trace 由一组 span 组成，可以看成是由 trace 为根节点，span 为若干个子节点的一棵树。
 Zipkin 会将 trace 相关的信息在调用链路上传递，并在每个调用边界结束时异步的把当前调用的耗时信息上报给 Zipkin Server。Zipkin Server 在收到 trace 信息后，将其存储起来。随后 Zipkin 的 Web UI 会通过 API 访问的方式从存储中将 trace 信息提取出来分析并展示。

4.核心数据结构
traceId：全局跟踪ID，用它来标记一次完整服务调用，所以和一次服务调用相关的span中的traceId都是相同的，Zipkin将具有相同traceId的span组装成跟踪树来直观的将调用链路图展现在我们面前。
id：span的id，理论上来说，span的id只要做到一个traceId下唯一就可以
parentId：父span的id，调用有层级关系，所以span作为调用节点的存储结构，也有层级关系，就像图3所示，跟踪链是采用跟踪树的形式来展现的，树的根节点就是调用调用的顶点，从开发者的角度来说，顶级span是从接入了Zipkin的应用中最先接触到服务调用的应用中采集的。所以，顶级span是没有parentId字段的
name：span的名称，主要用于在界面上展示，一般是接口方法名，name的作用是让人知道它是哪里采集的span，不然某个span耗时高我都不知道是哪个服务节点耗时高
timestamp：span创建时的时间戳，用来记录采集的时刻。
duration：持续时间，即span的创建到span完成最终的采集所经历的时间，除去span自己逻辑处理的时间，该时间段可以理解成对于该跟踪埋点来说服务调用的总耗时
annotations：基本标注列表，一个标注可以理解成span生命周期中重要时刻的数据快照，比如一个标注中一般包含发生时刻（timestamp）、事件类型（value）、端点（endpoint）等信息
事件类型
cs：客户端/消费者发起请求
cr：客户端/消费者接收到应答
sr：服务端/生产者接收到请求
ss：服务端/生产者发送应答
ps：这四种事件类型的统计都应该是Zipkin提供客户端来做的，因为这些事件和业务无关，这也是为什么跟踪数据的采集适合放到中间件或者公共库来做的原因。
binaryAnnotations：业务标注列表，如果某些跟踪埋点需要带上部分业务数据（比如url地址、返回码和异常信息等），可以将需要的数据以键值对的形式放入到这个字段中。
5.优点
扩展性：使用http和json这种轻量级协议，比起使用探针和Thrift传输协议。更易于
扩展和集成第三方接口。
兼容性：对spring cloud的支持更好。社区活跃度高，插件丰富。
性能：支持自定义采样策略。系统设计对性能优化的更好。