鏈路追蹤工具之Zipkin學習小記

（接觸了Zipkin，權將所瞭解或理解的記於此，以備忘）

分佈式追蹤系統

隨着業務發展，系統拆分多個微服務。此時對於一個前端請求可能須要調用多個後端端服務才能完成，當整個請求變慢或不可用時，咱們是沒法得知該請求是由某個或某些後端服務引發的。此時就須要有某種方式來定位到故障位，這就是分佈式系統調用跟蹤的誕生。

分佈式服務調用追蹤的理論基礎是Google 2010年發表的論文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》（譯文：Dapper，大規模分佈式系統的跟蹤系統）。爲了實現平臺無關、廠商無關的分佈式服務跟蹤，CNCF（Cloud Native Computing Foundation，雲原生計算基金會，一個廠商中立的基金會，致力於Github上的快速成長的開源技術的推廣，如Kubernetes、Prometheus、Envoy等）發佈了布式服務跟蹤標準 Open Tracing。基於該標準有不少具體實現，如Google的Dapper、Twitter的Zipkin，國內的有淘寶的鷹眼、京東的Hydra、大衆點評的CAT、新浪的Watchman等，其中使用的最普遍的是Twitter的Zipkin。

幾個概念

trace、span

 Trace 表示對一次請求的追蹤，又把每一個 Trace 拆分爲若干個有依賴關係的 Span（意爲持續時間？）。在微服務架構中，一次用戶請求可能會由後臺若干個服務負責處理，則每一個處理請求的服務就能夠理解爲一個 Span（可包括 API 服務，緩存服務，數據庫服務以等）。固然這個服務也可能繼續請求其餘的服務，所以 Span 是一個樹形結構，以體現服務之間的調用關係。

 

Zipkin - what

Zipkin是一個開源的分佈式追蹤系統，用於對服務間的調用鏈路進行監控追蹤。在微服務架構下，用戶的一個請求可能涉及到不少個後臺服務間的調用，Zipkin能夠追蹤(trace)調用鏈路、收集在各個微服務上所花的時間等信息、並上報到Zipkin服務器。

Zipkin是根據Google Dapper而設計的，由Twitter公司開發。

官網：https://zipkin.io/

項目GitHub：https://github.com/openzipkin/zipkin

 

Zipkin項目功能齊全，項目提供了鏈路追蹤（trace）、數據上報（collector）、數據存儲（server storage）、數據展現（server ui）等封裝模塊。

一、鏈路追蹤（request trace）：即Zipkin client，用於對用戶的調用進行追蹤，Zipkin提供了java、go、js等各類主流語言的追蹤庫：開箱即用，以少許代碼且不多的業務代碼侵入代價實現追蹤。brave是zipkin提供的java下的trace library，其提供了針對rpc、http、kafka、mysql、jmx等不少調用類型的追蹤（參閱：https://github.com/openzipkin/brave），從中收集到調用耗時等信息。

二、數據上報（collector/transport）：即Zipkin server接收Zipkin client所收集信息的方式，Zipkin支持HTTP Rest API、Kafka、rabbitmq等形式來接收數據（參閱：https://github.com/openzipkin/zipkin/tree/master/zipkin-collector），默認爲HTTP形式。

三、數據存儲（server storage）：即Zipkin server對client上傳來的數據的存儲形式，Zipkin提供了In-Memory、MySQL、Cassandra、Elasticsearch等形式（參閱：https://github.com/openzipkin/zipkin/tree/master/zipkin-storage）。默認爲In-Memory形式。

四、數據展現（server ui）：經過Zipkin server ui展現收集到的調用鏈信息。

五、... ...

 

能夠預見，萬變不離其宗，Zipkin client主要就是各類語言下的library、而一個Zipkin server則是對Collector、Storage、UI等的整合。

 

更多參考資料：分佈式服務跟蹤及Spring Cloud的實現