基於zipkin分佈式鏈路追蹤系統預研第一篇

　本文爲博主原創文章，未經博主容許不得轉載。　

　　分佈式服務追蹤系統起源於Google的論文「Dapper, a Large-Scale Distributed Systems Tracing Infrastructure」（譯文可參考此處），Twitter的zipkin是基於此論文上線較早的分佈式鏈路追蹤系統了，並且因爲開源快速被各社區所研究，也誕生了不少的版本。
在這裏也是對zipkin進行研究，先貼出Twitter zipkin結構圖。

結構比較簡單，大概流程爲：

1. Trace數據的收集至Scribe(Facebook開源的日誌傳輸通路)或Kafka(Apache分佈式消息系統)。
2. Scribe/Kafaka中的數據由控制器存入數據庫中。
3. 最後由UI和Query查詢展現。

　　這裏將提到一個日誌分析系統ELK，它是一個集合日誌收集、日誌分析查詢於一體。系統主要拆分爲：收集(logstash)、存儲(elasticsearch)、展現(kibana)三部分，目前被咱們用於作分佈式服務日誌系統。

---

　　在此想到盡然ELK已經幫咱們收集了分佈式服務的日誌並統一存儲，爲什麼鏈路追蹤系統不能直接用這些日誌作查詢展現呢？ 

　　因此今後角度出發，我對該方案結構進行構圖，但願可行。先貼出我畫的結構圖(醜了些，將就看吧)：

 

對此結構開始部署環境，環境部署在下次講到。

---

　　當前部門研發分佈式服務架構，討論到分佈式鏈路追蹤系統。因此在這對分佈式鏈路追蹤系統進行一個學習，並寫成筆記做爲一個學習的動力。 筆記中全部都爲我的看法，可能存在錯誤，望你們指出。