zipkin是Twitter基于google的分布式监控系统Dapper（论文）的开发源实现，zipkin用于跟踪分布式服务之间的应用数据链路，分析处理延时，帮助我们改进系统的性能和定位故障。
zipkin架构
Instrumented client和Instrumented server是分布式系统中的服务，通过装备库采集跟踪信息，装备库再调用Transport，把跟踪信息发送给zipkin。
装备库
针对不同语言，不同RPC框架，有不同的装备库实现，目前已有实现列表见此，其中Brave是zipkin官方提供的Java的装备库。
一个装备库的实现需要考虑如下情况：
- 实现语言，和需要装备的服务的语言一致
- zipkin需要的核心数据结构信息记录，包括tracerid,spanid的生成，延迟时间的计算，事件记录，tag记录等
- 服务之间跟踪信息的传递，称为植入，不同RPC接口植入的方式不一样，例如HTTP接口采用B3协议植入
植入的信息包括：Trace Id、Span Id、Parent Id、Sampled、Flags - 采样，减少跟踪导致的系统负荷
- 报告给zipkin，调用Transport将跟踪信息传给zipkin
Transport
Transport是zipkin对外提供的接口，目前有HTTP、Kafka、Scribe三种。
- HTTP：采用json格式，接口定义见https://github.com/openzipkin/zipkin-api
- Kafka：分布式发布订阅消息系统
- Scribe：Facebook的日志收集系统https://github.com/facebook/scribe
核心数据结构
v2版本：
- traceId：64位或128位，全局唯一，
- parentId：父spanid，64位，根span的parentId为空
- id：spanid，64位，tranceId内唯一
- name：方法名
- serviceName：服务名
- timestamp：自1970-1-1 00:00:00 UTC的微秒
- duration：开始span到结束span的时间，单位微秒
- annotations：记录事件，value有一些预定义的值，例如客户端发送(cs)，客户端接收(cr)，服务端接收(sr)，服务端发送(ss)等
- tags：记录附加数据
一个Span就是记录[remoteEndpoint.serviceName]服务的[Span.name]方法的执行过程，其中的annotation记录了中间的一些事件发生时间，通过这些时间可以得到[Span.name]方法的网络传输时间，服务端执行时间，客户端响应时间等信息，从而对其进行诊断优化。多个Span通过parentId构成一个树形结构，根Span的parentId为空，描述了一次trace（tranceId标识）中多个服务之间的调用过程。
示例说明
https://github.com/zhongpan/zipkin-ice
假设service1.fun1中调用service2.fun2和service3.fun3，service2.fun2中调用service4.fun4。本次跟踪各个服务中会创建如上的span1~span7，span1为根span。span2和span4为一次RPC的客户端和服务端行为，可以共享spanid，span4不用新生成spanid，span2和span4在zipkin中会合并为1个span，span3/span5以及span6/span7类似。最终，在zipkin界面展示的树形结构为：