（接觸了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公司開發。
項目GitHub：https://github.com/openzipkin/zipkin
Zipkin項目功能齊全，項目提供了鏈路追蹤（trace）、數據上報（collector）、數據存儲（server storage）、數據展示（server ui）等封裝模塊。
1、鏈路追蹤（request trace）：即Zipkin client，用於對用戶的調用進行追蹤，Zipkin提供了java、go、js等各種主流語言的追蹤庫：開箱即用，以少量代碼且很少的業務代碼侵入代價實現追蹤。brave是zipkin提供的java下的trace library，其提供了針對rpc、http、kafka、mysql、jmx等很多調用類型的追蹤（參閱：https://github.com/openzipkin/brave），從中收集到調用耗時等信息。
2、數據上報（collector/transport）：即Zipkin server接收Zipkin client所收集信息的方式，Zipkin支持HTTP Rest API、Kafka、rabbitmq等形式來接收數據（參閱：https://github.com/openzipkin/zipkin/tree/master/zipkin-collector），默認為HTTP形式。
3、數據存儲（server storage）：即Zipkin server對client上傳來的數據的存儲形式，Zipkin提供了In-Memory、MySQL、Cassandra、Elasticsearch等形式（參閱：https://github.com/openzipkin/zipkin/tree/master/zipkin-storage）。默認為In-Memory形式。
4、數據展示（server ui）：通過Zipkin server ui展示收集到的調用鏈信息。
5、... ...
可以預見，萬變不離其宗，Zipkin client主要就是各種語言下的library、而一個Zipkin server則是對Collector、Storage、UI等的整合。
更多參考資料：分布式服務跟蹤及Spring Cloud的實現