一、背景介紹

1、Zipkin是什麽

Zipkin分布式跟蹤系統；它可以幫助收集時間數據，解決在microservice架構下的延遲問題；它管理這些數據的收集和查找；Zipkin的設計是基於谷歌的Google Dapper論文。
每個應用程序向Zipkin報告定時數據，Zipkin UI呈現了一個依賴圖表來展示多少跟蹤請求經過了每個應用程序；如果想解決延遲問題，可以過濾或者排序所有的跟蹤請求，並且可以查看每個跟蹤請求占總跟蹤時間的百分比。

2、為什麽使用Zipkin

隨著業務越來越復雜，系統也隨之進行各種拆分，特別是隨著微服務架構和容器技術的興起，看似簡單的一個應用，後臺可能有幾十個甚至幾百個服務在支撐；一個前端的請求可能需要多次的服務調用最後才能完成；當請求變慢或者不可用時，我們無法得知是哪個後臺服務引起的，這時就需要解決如何快速定位服務故障點，Zipkin分布式跟蹤系統就能很好的解決這樣的問題。

3、Zipkin下載和啟動

官方提供了三種方式來啟動，這裏使用第二種方式來啟動;

curl -sSL https://zipkin.io/quickstart.sh | bash -s
java -jar zipkin.jar

訪問localhost:9411

詳細參考：https://zipkin.io/pages/quick...

二、Zipkin架構

跟蹤器(Tracer)位於你的應用程序中，並記錄發生的操作的時間和元數據,提供了相應的類庫，對用戶的使用來說是透明的，收集的跟蹤數據稱為Span;
將數據發送到Zipkin的儀器化應用程序中的組件稱為Reporter,Reporter通過幾種傳輸方式之一將追蹤數據發送到Zipkin收集器(collector)，

1.Trace

Zipkin使用Trace結構表示對一次請求的跟蹤，一次請求可能由後臺的若幹服務負責處理，每個服務的處理是一個Span，Span之間有依賴關系，Trace就是樹結構的Span集合；

2.Span

每個服務的處理跟蹤是一個Span，可以理解為一個基本的工作單元，包含了一些描述信息：id，parentId，name，timestamp，duration，annotations等，例如：

{
      "traceId": "bd7a977555f6b982",
      
 
"name": "get-traces",
      "id": "ebf33e1a81dc6f71",
      "parentId": "bd7a977555f6b982",
      "timestamp": 1458702548478000,
      "duration": 354374,
      "annotations": [
        {
          "endpoint": {
            "serviceName": "zipkin-query",
            "ipv4": "192.168.1.2",
            "port": 9411
          },
          "timestamp": 1458702548786000,
          "value": "cs"
        }
      ],
      "binaryAnnotations": [
        {
          "key": "lc",
          "value": "JDBCSpanStore",
          "endpoint": {
            "serviceName": "zipkin-query",
            "ipv4": "192.168.1.2",
            "port": 9411
          }
        }
      ]
}

traceId：標記一次請求的跟蹤，相關的Spans都有相同的traceId；
id：span id；
name：span的名稱，一般是接口方法的名稱；
parentId：可選的id，當前Span的父Span id，通過parentId來保證Span之間的依賴關系，如果沒有parentId，表示當前Span為根Span；
timestamp：Span創建時的時間戳，使用的單位是微秒（而不是毫秒），所有時間戳都有錯誤，包括主機之間的時鐘偏差以及時間服務重新設置時鐘的可能性，
出於這個原因，Span應盡可能記錄其duration；
duration：持續時間使用的單位是微秒（而不是毫秒）；
annotations：註釋用於及時記錄事件；有一組核心註釋用於定義RPC請求的開始和結束；

cs:Client Send，客戶端發起請求；
sr:Server Receive，服務器接受請求，開始處理；
ss:Server Send，服務器完成處理，給客戶端應答；
cr:Client Receive，客戶端接受應答從服務器；

binaryAnnotations：二進制註釋，旨在提供有關RPC的額外信息。

3.Transport

收集的Spans必須從被追蹤的服務運輸到Zipkin collector，有三個主要的傳輸方式：HTTP, Kafka和Scribe；

4.Components

有4個組件組成Zipkin：collector，storage，search，web UI

• collector：一旦跟蹤數據到達Zipkin collector守護進程，它將被驗證，存儲和索引，以供Zipkin收集器查找；
• storage：Zipkin最初數據存儲在Cassandra上，因為Cassandra是可擴展的，具有靈活的模式，並在Twitter中大量使用；但是這個組件可插入，除了Cassandra之外，還支持ElasticSearch和MySQL；
• search：一旦數據被存儲和索引，我們需要一種方法來提取它。查詢守護進程提供了一個簡單的JSON API來查找和檢索跟蹤，主要給Web UI使用；
• web UI：創建了一個GUI，為查看痕跡提供了一個很好的界面；Web UI提供了一種基於服務，時間和註釋查看跟蹤的方法。

三、Spring-boot中集成Zipkin示例

調用鏈系列一、Zipkin搭建、Spring-boot集承