zipkin分散式鏈路追蹤介紹

介紹

Zipkin是一款開源的分散式實時資料追蹤系統（Distributed Tracking System），基於 Google Dapper的論文設計而來，由 Twitter 公司開發貢獻。其主要功能是聚集來自各個異構系統的實時監控資料。

架構

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介面

ZipKin幾個概念

在追蹤日誌中，有三個最重要的概念: spanId、traceId、parentId

traceId：用來確定一個追蹤鏈的16字元長度的字串，在某個追蹤鏈中保持不變。

spanId：區域Id，在一個追蹤鏈中spanId可能存在多個，每個spanId用於表明在某個服務中的身份，也是16字元長度的字串。

parentId：在跨服務呼叫者的spanId會傳遞給被呼叫者，被呼叫者會將呼叫者的spanId作為自己的parentId，然後自己再生成spanId。

其他概念：

name：span的名稱，主要用於在介面上展示，一般是介面方法名，name的作用是讓人知道它是哪裡採集的span，不然某個span耗時高我都不知道是哪個服務節點耗時高

timestamp：span建立時的時間戳，用來記錄採集的時刻。

duration：持續時間，即span的建立到span完成最終的採集所經歷的時間，除去span自己邏輯處理的時間，該時間段可以理解成對於該跟蹤埋點來說服務呼叫的總耗時

annotations：基本標註列表，一個標註可以理解成span生命週期中重要時刻的資料快照，比如一個標註中一般包含發生時刻（timestamp）、事件型別（value）、端點（endpoint）等資訊

  事件型別
	  cs：客戶端/消費者發起請求
	  cr：客戶端/消費者接收到應答
	  sr：服務端/生產者接收到請求
	  ss：服務端/生產者傳送應答

binaryAnnotations：業務標註列表，如果某些跟蹤埋點需要帶上部分業務資料（比如url地址、返回碼和異常資訊等），可以將需要的資料以鍵值對的形式放入到這個欄位中。
複製程式碼

下圖是一個鏈路追蹤的案例:

1. 使用者請求 service1 的 /service1/test 介面。
2. service1 介面中需要呼叫 service2 的 /service2/test 介面。
3. service2 介面中需要順序呼叫 service3 的 /service3/test 介面和 service4 的 /service4/test 介面。