業界大部分的應用分布式追蹤的原理源自 Google 的一篇 Dapper 系統的論文。Dapper是谷歌內部使用的分布式鏈路追蹤系統，雖然沒有開源，但是Google在其2010年發布的一篇論文中對其進行了詳細的介紹。可以說，Dapper是鏈路追蹤領域的始祖，其提出的概念和理念一致影響着后來所有的分布式系統鏈路追蹤系統，包括阿里的鷹眼系統，大眾點評的cat系統，Twitter的Zipkin以及開源的Jaeger等等。
Dapper的分布式跟蹤
一. 為什么需要分布式調用跟蹤
隨着分布式服務架構的流行，特別是微服務等設計理念在系統中的應用，系統架構變得越來越分散，如下圖所示:
分布式服務拆分以后，系統變得日趨復雜，業務的調用鏈也越來越長，如何快速定位線上故障，就需要依賴分布式調用跟蹤技術。可以看到，隨着服務的拆分，系統的模塊變得越來越多，不同的模塊可能由不同的團隊維護，一個請求可能會涉及幾十個服務的協同處理， 牽扯到多個團隊的業務系統。
假設現在某次服務調用失敗，或者出現請求超時，需要定位具體是哪個服務引起的異常，哪個環節導致的超時，就需要去每個服務里查看日志，這樣的處理效率是非常低的。
另外，系統拆分以后，缺乏一個自上而下全局的調用 ID，如何有效地進行相關的數據分析工作呢？比如電商的活動轉化率、購買率、廣告系統的點擊鏈路等。如果沒有一個統一的調用 ID 來記錄，只依靠業務上的主鍵等是很難實現的，特別是對於一些大型網站系統，如淘寶、京東等，這些問題尤其突出。
二. 分布式鏈路調用跟蹤的業務場景
分布式調用跟蹤技術就是解決上面的業務問題，即通過調用鏈的方式，把一次請求調用過程完整的串聯起來，這樣就實現了對請求調用路徑的監控。
分布式調用鏈其實就是將一次分布式請求還原成調用鏈路，顯式的在后端查看一次分布式請求的調用情況，比如各個節點上的耗時、請求具體打到了哪台機器上、每個服務節點的請求狀態等。
一般來說，分布式調用跟蹤可以應用在以下的場景中。
1）故障快速定位：通過調用鏈跟蹤，一次請求的邏輯軌跡可以完整清晰地展示出來。在開發的過程中，可以在業務日志中添加調用鏈 ID，還可以通過調用鏈結合業務日志快速定位錯誤信息。
2）各個調用環節的性能分析：在調用鏈的各個環節分別添加調用時延，並分析系統的性能瓶頸，進行針對性的優化。
3）各個調用環節的可用性，持久層依賴等：通過分析各個環節的平均時延、QPS 等信息，可以找到系統的薄弱環節，對一些模塊做調整，比如數據冗余等。
4）數據分析等：調用鏈是一條完整的業務日志，可以得到用戶的行為路徑，並匯總分析。
其它分布式追蹤系統
1）Apache SkyWalking。
官網 http://skywalking.apache.org/
2）SpringCloud Sleuth，它集成了Zipkin、HTrace 鏈路追蹤工具，用服務鏈路追蹤來快速定位問題。
3）CAT。
4）淘寶鷹眼Tracing
5）新浪Watchman