分布式調用鍊跟蹤系統：Zipkin

官網、GitHub

英語

Tracer，跟蹤器

概念

範疇：分布式調用鍊跟蹤系統，或分布式鍊路調用監控系統。

Trace、Span

Zipkin 以 Trace 結構表示對一次請求的追蹤，又把每個 Trace 拆分為若幹個有依賴關系的 Span。

Span 模型

在微服務架構中，一次使用者請求可能會由背景若幹個服務負責處理，那麼每個處理請求的服務就可以了解為一個 Span（可以包括 API 服務，緩存服務，資料庫服務以及報表服務等）。當然這個服務也可能繼續請求其他的服務，是以 Span 是一個樹形結構，以展現服務之間的調用關系。

參考

Zipkin快速開始

• 開源
• 輕量級
• 跟蹤資料存儲友善

前言

Zipkin是什麼

Zipkin 幫助收集時間資料，解決在微服務架構下的延遲問題；它管理這些資料的收集和查找；Zipkin的設計是基于谷歌的Google Dapper論文。

每個應用程式向 Zipkin 報告定時資料，Zipkin UI呈現了一個依賴圖表來展示多少跟蹤請求經過了每個應用程式；如果想解決延遲問題，可以過濾或者排序所有的跟蹤請求，并且可以檢視每個跟蹤請求占總跟蹤時間的百分比。

為什麼使用Zipkin

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

Zipkin下載下傳和啟動

快速啟動：

參考官網 Quickstart

下載下傳 zipkin.jar，然後直接使用-jar指令運作，要求jdk8以上版本。

基于Undertow WEB伺服器，提供對外端口：9411，可以打開浏覽器通路http://ip:9411。

Zipkin架構

跟蹤器(Tracer)位于你的應用程式中，并記錄發生的操作的時間和中繼資料,提供了相應的類庫，對使用者的使用來說是透明的，收集的跟蹤資料稱為Span;

将資料發送到Zipkin的儀器化應用程式中的元件稱為Reporter，Reporter通過幾種傳輸方式之一将追蹤資料發送到Zipkin收集器(collector)，

然後将跟蹤資料進行存儲(storage)，由API查詢存儲以向UI提供資料。

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": ,
      "duration": ,
      "annotations": [
        {
          "endpoint": {
            "serviceName": "zipkin-query",
            "ipv4": "192.168.1.2",
            "port": 
          },
          "timestamp": ,
          "value": "cs"
        }
      ],
      "binaryAnnotations": [
        {
          "key": "lc",
          "value": "JDBCSpanStore",
          "endpoint": {
            "serviceName": "zipkin-query",
            "ipv4": "192.168.1.2",
            "port": 
          }
        }
      ]
}
           

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請求的開始和結束；

1）、cs:Client Send，用戶端發起請求；

2）、sr:Server Receive，伺服器接受請求，開始處理；

3）、ss:Server Send，伺服器完成處理，給用戶端應答；

4）、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提供了一種基于服務，時間和注釋檢視跟蹤的方法。