分布式服務追蹤與調用鏈系統產生的背景
在為服務中，如果服務與服務之間的依賴關系非常復雜，如果某個服務出現了一些問題，很難追查到原因，特別是服務與服務之間調用的時候。
在微服務系統中，隨着業務的發展，系統會變得越來越大，那么各個服務之間的調用關系也就變得越來越復雜。一個 HTTP 請求會調用多個不同的微服務來處理返回最后的結果，在這個調用過程中，可能會因為某個服務出現網絡延遲過高或發送錯誤導致請求失敗，這個時候，對請求調用的監控就顯得尤為重要了。Spring Cloud Sleuth 提供了分布式服務鏈路監控的解決方案
服務與服務之間調用關系 鏈路指的：一串聯多個服務組成一個流程 調用鏈關系
SpringCloud Zipkin 與Sleuth
Zipkin 是一個開放源代碼分布式的跟蹤系統，由Twitter公司開源，它致力於收集服務的定時數據，以解決微服務架構中的延遲問題，包括數據的收集、存儲、查找和展現。 每個服務向zipkin報告計時數據，例如用戶每次請求服務的處理時間等，可方便的監測系統中存在的瓶頸。 zipkin會根據調用關系通過Zipkin UI生成依賴關系圖。
Spring Cloud Sleuth為服務之間調用提供鏈路追蹤。通過Sleuth可以很清楚的了解到一個服務請求經過了哪些服務，每個服務處理花費了多長。從而讓我們可以很方便的理清各微服務間的調用關系。此外Sleuth可以幫助我們：
耗時分析: 通過Sleuth可以很方便的了解到每個采樣請求的耗時，從而分析出哪些服務調用比較耗時;
可視化錯誤: 對於程序未捕捉的異常，可以通過集成Zipkin服務界面上看到; 鏈路優化: 對於調用比較頻繁的服務，可以針對這些服務實施一些優化措施。
Spring Cloud Sleuth可以結合Zipkin，將信息發送到Zipkin，利用Zipkin的存儲來存儲信息，利用Zipkin Ui來展示數據。
搭建Zipkin服務追蹤系統
在 Spring Boot 2.0 版本之后，官方已不推薦自己搭建定制了，而是直接提供了編譯好的 jar 包。
注意：zipkin官網已經提供定制了，使用官方jar運行即可。
啟動方式:
默認端口號啟動zipkin服務
java –jar zipkin.jar 默認端口號; 9411
訪問地址:http://127.0.0.1:9411/zipkin/
指定端口號啟動8080啟動zipkin服務
java -jar zipkin.jar --server.port=8080
訪問地址:http://192.168.18.220:8080
指定訪問rabbitmq 啟動
java -jar zipkin.jar --zipkin.collector.rabbitmq.addresses=127.0.0.1
搭建Zipkin集成RabbitMQ異步傳輸
1、啟動RabbitMQ
2、啟動Zipkin（自動會創建一個Zipkin 隊列）
3、啟動ZipkinClient以隊列形式異步傳輸
服務跟蹤原理
為了實現請求跟蹤，當請求發送到分布式系統的入口端點時， 只需要服務跟蹤框架為該請求創建一個唯的跟蹤標識， 同時在分布式系統內部流轉的時候，框架始終保持傳遞該唯一標識， 直到返回給請求方為止，這個唯一標識就是前 文中提到的Trace ID。通過Trace ID的記錄，我們就能將所有請求過程的日志關聯起來。 為了統計各處理單元的時間延遲，當請求到達各個服務組件時，或是處理邏輯到達某個狀態時，也通過一個唯一 標識來標記它的開始、 具體過程以及結束，該標識就是前文中提到的Span ID。對於每個Span來說，它必須有開始和結束兩個節點，通過記錄開始Span和結束Span的時間戳，就能統計出該Span的時間延遲，除了時間戳記錄之外，它還可以包含一些其他元數據， 比如事件名稱、請求信息等
TranceId作用是整個微服務調用鏈過程中保證唯一。
Spanid記錄每次一請求。
在微服務中，TranceId與Spanid會放在請求頭中進行傳遞。Trancdid 每次請求都是一樣的，而Spanid 每請求一次就會重新生成一個。一個TranceId由多個Spanid組合起來，獲取到整個微服務調用依賴關系。
SpringCloud2.x新知識介紹
官網：https://zipkin.io/pages/quickstart.html