在傳統的單應用架構下，介面的日誌監控還是非常簡單的，但是隨著分散式、微服務架構的興起，我們會面對更為複雜的服務互動關係；
也就是說，以往的系統，更多的是A系統呼叫B系統，而現在可能面對這A->B->C->D，而在這種情況下，如果沒有鏈路跟蹤的方案，那麼查詢和定位問題就會非常困難。
Google公司研發了Dapper分散式跟蹤系統，並發表了論文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》；
目前行業內大部分的分散式跟蹤方案都是基於這篇論文來實現的；這篇論文中提到了幾個比較重要的概念：
annotation-based，基於標註：在程式程式碼或中介軟體中，定義一個全域性的annotation，可以把這個看做是一個追蹤ID；在請求鏈路中，每一次遠端呼叫都要帶著這個ID（通常都是透過程式碼埋點實現）；
跟蹤樹和span：在跟蹤樹結構中，透過parentId和spanId可以有序地把所有的關係串聯起來，達到記錄業務流的作用；例如A->B->C和D；那麼：
A：parentId=null、spanId=1；
B：parentId=1、spanId=2；
C：parentId=2、spanId=3；
D：parentId=2、spanId=4；
zipkin：Twitter公司的zipkin是Google Dapper系統的開源實現，zipkin是嚴格按照Dapper論文來實現的；zipkin的功能包括資料的收集、儲存、查詢和展現，一應俱全；
Spring Cloud Sleuth：如果使用Spring全家桶的話，通常可以使用Sleuth來做服務之間呼叫提供鏈路追蹤；使用Sleuth的時候，也可以和zipkin做整合，將蒐集到的資訊傳送到zipkin，利用zipkin進行資料的儲存和展示；
在傳統的單應用架構下，介面的日誌監控還是非常簡單的，但是隨著分散式、微服務架構的興起，我們會面對更為複雜的服務互動關係；
也就是說，以往的系統，更多的是A系統呼叫B系統，而現在可能面對這A->B->C->D，而在這種情況下，如果沒有鏈路跟蹤的方案，那麼查詢和定位問題就會非常困難。
理論基礎Google公司研發了Dapper分散式跟蹤系統，並發表了論文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》；
目前行業內大部分的分散式跟蹤方案都是基於這篇論文來實現的；這篇論文中提到了幾個比較重要的概念：
annotation-based，基於標註：在程式程式碼或中介軟體中，定義一個全域性的annotation，可以把這個看做是一個追蹤ID；在請求鏈路中，每一次遠端呼叫都要帶著這個ID（通常都是透過程式碼埋點實現）；
跟蹤樹和span：在跟蹤樹結構中，透過parentId和spanId可以有序地把所有的關係串聯起來，達到記錄業務流的作用；例如A->B->C和D；那麼：
A：parentId=null、spanId=1；
B：parentId=1、spanId=2；
C：parentId=2、spanId=3；
D：parentId=2、spanId=4；
實現方案zipkin：Twitter公司的zipkin是Google Dapper系統的開源實現，zipkin是嚴格按照Dapper論文來實現的；zipkin的功能包括資料的收集、儲存、查詢和展現，一應俱全；
Spring Cloud Sleuth：如果使用Spring全家桶的話，通常可以使用Sleuth來做服務之間呼叫提供鏈路追蹤；使用Sleuth的時候，也可以和zipkin做整合，將蒐集到的資訊傳送到zipkin，利用zipkin進行資料的儲存和展示；