1、鍊路追蹤介紹
在大型系統的微服務化建構中，一個系統被拆分成了許多子產品。這些子產品負責不同的功能，組合成系統，最終可以提供豐富的功能。在這種架構中，一次請求往往需要涉及到多個服務。網際網路應用建構在不同的軟體子產品集上，這些軟體子產品，有可能是由不同的團隊開發、可能使用不同的程式設計語言來實作、有可能布在了幾千台伺服器，橫跨多個不同的資料中心。
2、為什麼需要鍊路追蹤?
微服務架構是通過業務來劃分服務的，使用 REST 調用。對外暴露的一個接口，可能需要很多個服務協同才能完成這個接口功能，如果鍊路上任何一個服務出現問題或者網絡逾時，都會形成導緻接口調用失敗。随着業務的不斷擴張，服務之間互相調用會越來越複雜。
2.1、那該如何解決呢？
分布式鍊路追蹤（Distributed Tracing），就是将一次分布式請求還原成調用鍊路，進行日志記錄，性能監控并将一次分布式請求的調用情況集中展示。比如各個服務節點上的耗時、請求具體到達哪台機器上、每個服務節點的請求狀态等等。
2.2、常見的鍊路追蹤技術有下面這些：
(1)cat 由大衆點評開源，基于Java開發的實時應用監控平台，包括實時應用監控，業務監控 。 內建 方案是通過代碼埋點的方式來實作監控，比如： 攔截器，過濾器等。 對代碼的侵入性很大，內建成本較高。風險較大。
(2)zipkin 由Twitter公司開源，開放源代碼分布式的跟蹤系統，用于收集服務的定時資料，以解決微 服務架構中的延遲問題，包括：資料的收集、存儲、查找和展現《圖形化》。該産品結合spring-cloud-sleuth 使用較為簡單， 內建很友善， 但是功能較簡單。
(3)pinpoint Pinpoint是南韓人開源的基于位元組碼注入的調用鍊分析，以及應用監控分析工具。特點 是支援多種插件，UI功能強大，接入端無代碼侵入。
(4)SkyWalking是本土開源的基于位元組碼注入的調用鍊分析，以及應用監控分析工具。特點是支援多 種插件，UI功能較強，接入端無代碼侵入。目前已加入Apache孵化器。
Sleuth （日志記錄每一條鍊路上的所有節點，以及這些節點所在的機器，和耗時。）
(5)log4j SpringCloud 提供的分布式系統中鍊路追蹤解決方案。
注意：SpringCloud alibaba技術棧中并沒有提供自己的鍊路追蹤技術的，我們可以采用Sleuth + Zipkin來做鍊路追蹤解決方案。
3、Sleuth
3.1、Sleuth介紹
SpringCloud Sleuth主要功能就是在分布式系統中提供追蹤解決方案。它大量借用了Google Dapper的設計， 先來了解一下Sleuth中的術語和相關概念。
3.2、相關術語
(1)Trace (一條完整鍊路–包含很多span(微服務接口))
由一組Trace Id（貫穿整個鍊路）相同的Span串聯形成一個樹狀結構。為了實作請求跟蹤，當請求到達分布式系統的入口端點時，隻需要服務跟蹤架構為該請求建立一個唯一的辨別（即TraceId），同時在分布式系統内部流轉的時候，架構始終保持傳遞該唯一值，直到整個請求的傳回。那麼我們就可以使用該唯一辨別将所有的請求串聯起來，形成一條完整的請求鍊路。
(2)Span
代表了一組基本的工作單元。為了統計各處理單元的延遲，當請求到達各個服務元件的時候，也通過一個唯一辨別（SpanId）來标記它的開始、具體過程和結束。通過SpanId的開始和結束時間戳，就能統計該span的調用時間，除此之外，我們還可以擷取如事件的名稱。請求資訊等中繼資料。
(3)Annotation
用它記錄一段時間内的事件，内部使用的重要注釋：
cs（Client Send）用戶端送出請求，開始一個請求的生命
sr（Server Received）服務端接受到請求開始進行處理， sr－cs = 網絡延遲（服務調用的時間）
ss（Server Send）服務端處理完畢準備發送到用戶端，ss - sr = 伺服器上的請求處理時間
cr（Client Reveived）用戶端接受到服務端的響應，請求結束。 cr - sr = 請求的總時間
3.3、Sleuth入門
接下來通過我之前的項目案例整合Sleuth，完成入門案例的編寫。
在pom.xml檔案添加Sleuth依賴
啟動微服務，調用之後，我們可以在控制台觀察到sleuth的日志輸出
其中shop-getway中的 f2d0f9e1ad17ecda是TraceId， shop-product中的ad5e994c06101a23是SpanId，依次調用有一個全局的TraceId，将調用鍊路串起來。仔細分析每個微服務的日志，不難看出請求的具體過程。
檢視日志檔案并不是一個很好的方法，當微服務越來越多日志檔案也會越來越多，通過Zipkin可以将日志聚合，并進行可視化展示和全文檢索。
4、Zipkin
4.1、ZipKin介紹
Zipkin 是 Twitter 的一個開源項目，它基于Google Dapper實作，它緻力于收集服務的定時資料，以解決微服務架構中的延遲問題，包括資料的收集、存儲展現、查找和我們可以使用它來收集各個伺服器上請求鍊路的跟蹤資料，并通過它提供的REST API接口來輔助我們查詢跟蹤資料以實作對分布式系統的監控程式，進而及時地發現系統中出現的延遲升高問題并找出系統性能瓶頸的根源,除了面向開發的 API 接口之外，它也提供了友善的UI元件來幫助我們直覺的搜尋跟蹤資訊和分析請求鍊路明細，比如：可以查詢某段時間内各使用者請求的處理時間等。
Zipkin 提供了可插拔資料存儲方式：In-Memory、MySql、Cassandra 以及 Elasticsearch。
上圖展示了 Zipkin 的基礎架構，它主要由 4 個核心元件構成：
(1)Collector：收集器元件，它主要用于處理從外部系統發送過來的跟蹤資訊，将這些資訊轉換為Zipkin 内部處理的 Span 格式，以支援後續的存儲、分析、展示等功能。
(2)Storage：存儲元件，它主要對處理收集器接收到的跟蹤資訊，預設會将這些資訊存儲在記憶體中，我們也可以修改此存儲政策，通過使用其他存儲元件将跟蹤資訊存儲到資料庫中。
(3)RESTful API：API 元件，它主要用來提供外部通路接口。比如給用戶端展示跟蹤資訊，或是外接系統通路以實作監控等。
(4)Web UI：UI 元件，基于 API 元件實作的上層應用。通過 UI 元件使用者可以友善而有直覺地查詢和分析跟蹤資訊。
Zipkin分為兩端，一個是 Zipkin 服務端，一個是 Zipkin 用戶端，用戶端也就是微服務的應用。用戶端會配置服務端的 URL 位址，一旦發生服務間的調用的時候，會被配置在微服務裡面的 Sleuth 的監聽器監聽，并生成相應的 Trace 和 Span 資訊發送給服務端。
4.2、ZipKin服務端安裝
1、下載下傳ZipKin的jar包
官網下載下傳: https://zipkin.io/pages/quickstart.html
2、進入cmd黑視窗—通過指令行，輸入下面的指令啟動ZipKin Server
到剛才下載下傳的jar檔案目錄：
執行下面指令：
出現如下界面：
3、通過浏覽器通路 http://localhost:9411通路。
ZipKin用戶端和Sleuth的內建非常簡單，隻需要在微服務中添加其依賴和配置即可。
1、在每個微服務上添加依賴
2、添加配置
3、通路微服務
這是我自己的通路路徑，你們在通路的時候換成自己的通路路徑
4、通路zipkin的UI界面，觀察效果
5、點選其中一條記錄，可觀察一次通路的詳細線路
4.4、ZipKin資料持久化
Zipkin Server預設會将追蹤資料資訊儲存到記憶體，但這種方式不适合生産環境。Zipkin支援将追蹤資料持久化到mysql資料庫或elasticsearch中。
4.4.1、使用mysql實作資料持久化
1、建立mysql資料環境（建立資料庫及表）
View Code
2、關閉zipkin服務，重新打開cmd黑視窗輸入以下資料來啟動在啟動ZipKin Server的時候,指定資料儲存的mysql的資訊。
根據自己的資訊更改以下對應資料資訊
MYSQL_HOST：本機IP
MYSQL_TCP_PORT：端口号
MYSQL_DB：資料庫名
MYSQL_USER：使用者名
MYSQL_PASS：密碼
啟動之後就實作了資料持久化（将鍊路追蹤資訊存放到mysql資料庫中），重新啟動後再次打開通路zipkin的UI界面，鍊路資訊将不會消失。