基於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已經幫我們收集了分布式服務的日志並統一存儲，為何鏈路追蹤系統不能直接用這些日志做查詢展示呢？ 

　　所以從此角度出發，我對該方案結構進行構圖，希望可行。先貼出我畫的結構圖(丑了些，將就看吧)：

 

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

---

　　當前部門研發分布式服務架構，討論到分布式鏈路追蹤系統。所以在這對分布式鏈路追蹤系統進行一個學習，並寫成筆記作為一個學習的動力。 筆記中所有都為個人見解，可能存在錯誤，望大家指出。