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界面展示的樹形結構為：
