本章概述

隨著互聯(lián)網(wǎng)的不斷發(fā)展，企業(yè)的業(yè)務系統(tǒng)變得越來越復雜，原本單一的單體應用系統(tǒng)已經(jīng)無法滿足企業(yè)業(yè)務發(fā)展的需要。于是，很多企業(yè)開始了對項目的分布式與微服務改造，新項目也在開始的時候就會采用分布式與微服務的架構模式。

一個系統(tǒng)采用分布式與微服務架構后，會被拆分成許多服務模塊，這些服務模塊之間的調(diào)用關系錯綜復雜，對于客戶端請求的分析與處理就會顯得異常復雜。此時，就需要一種技術來解決這些問題，而這種技術就是分布式鏈路追蹤技術。

分布式鏈路追蹤

隨著互聯(lián)網(wǎng)業(yè)務快速擴展，企業(yè)的業(yè)務系統(tǒng)變得越來越復雜，不少企業(yè)開始向分布式、微服務方向發(fā)展，將原本的單體應用拆分成分布式、微服務。這也使得當客戶端請求系統(tǒng)的接口時，原本在同一個系統(tǒng)內(nèi)部的請求邏輯變成了需要在多個微服務之間流轉的請求。

單體架構中可以使用AOP在調(diào)用具體的業(yè)務邏輯前后分別打印一下時間即可計算出整體的調(diào)用時間，使用 AOP捕獲異常也可知道是哪里的調(diào)用導致的異常。

但是在分布式微服務場景下，使用AOP技術是無法追蹤到各個微服務的調(diào)用情況的，也就無法知道系統(tǒng)中處理一次請求的整體調(diào)用鏈路。

另外，在分布式與微服務場景下，我們需要解決如下問題：

• 如何快速發(fā)現(xiàn)并定位到分布式系統(tǒng)中的問題。
• 如何盡可能精確的判斷故障對系統(tǒng)的影響范圍與影響程度。
• 如何盡可能精確的梳理出服務之間的依賴關系，并判斷出服務之間的依賴關系是否合理。
• 如何盡可能精確的分析整個系統(tǒng)調(diào)用鏈路的性能與瓶頸點。
• 如何盡可能精確的分析系統(tǒng)的存儲瓶頸與容量規(guī)劃。
• 如何實時觀測系統(tǒng)的整體調(diào)用鏈路情況。

上述問題就是分布式鏈路追蹤技術要解決的問題。所謂的分布式鏈路追蹤，就是將對分布式系統(tǒng)的一次請求轉化成一個完整的調(diào)用鏈路。這個完整的調(diào)用鏈路從請求進入分布式系統(tǒng)的入口開始，直到整個請求返回為止。并在請求調(diào)用微服務的過程中，記錄相應的調(diào)用日志，監(jiān)控系統(tǒng)調(diào)用的性能，并且可以按照某種方式顯示請求調(diào)用的情況。

在分布式鏈路追蹤中，可以統(tǒng)計調(diào)用每個微服務的耗時，請求會經(jīng)過哪些微服務的流轉，每個微服務的運行狀況等信息。

核心原理

假定三個微服務調(diào)用的鏈路如下圖所示：Service 1 調(diào)用 Service 2，Service 2 調(diào)用 Service 3 和 Service 4。

那么鏈路追蹤會在每個服務調(diào)用的時候加上 Trace ID 和 Span ID。如下圖所示：

小伙伴注意上面的顏色，相同顏色的代表是同一個 Span ID，說明是鏈路追蹤中的一個節(jié)點。

• 第一步：用戶端調(diào)用 Service 1，生成一個 Request，Trace ID 和 Span ID 為空，那個時候請求還沒有到 Service 1。
• 第二步：請求到達 Service 1，記錄了 Trace ID = X，Span ID 等于 A。
• 第三步：Service 1 發(fā)送請求給 Service 2，Span ID 等于 B，被稱作 Client Sent，即用戶端發(fā)送一個請求。
• 第四步：請求到達 Service 2，Span ID 等于 B，Trace ID 不會改變，被稱作 Server Received，即服務端取得請求并準備開始解決它。
• 第五步：Service 2 開始解決這個請求，解決完之后，Trace ID 不變，Span ID = C。
• 第六步：Service 2 開始發(fā)送這個請求給 Service 3，Trace ID 不變，Span ID = D，被稱作 Client Sent，即用戶端發(fā)送一個請求。
• 第七步：Service 3 接收到這個請求，Span ID = D，被稱作 Server Received。
• 第八步：Service 3 開始解決這個請求，解決完之后，Span ID = E。
• 第九步：Service 3 開始發(fā)送響應給 Service 2，Span ID = D，被稱作 Server Sent，即服務端發(fā)送響應。
• 第十步：Service 3 收到 Service 2 的響應，Span ID = D，被稱作 Client Received，即用戶端接收響應。
• 第十一步：Service 2 開始返回 響應給 Service 1，Span ID = B，和第三步的 Span ID 相同，被稱作 Client Received，即用戶端接收響應。
• 第十二步：Service 1 解決完響應，Span ID = A，和第二步的 Span ID 相同。
• 第十三步：Service 1 開始向用戶端返回響應，Span ID = A、
• Service 3 向 Service 4 發(fā)送請求和 Service 3 相似，對應的 Span ID 是 F 和 G?？梢詤⒄丈厦媲懊娴牡诹降降谑健?/li>

把以上的相同顏色的步驟簡化為下面的鏈路追蹤圖：

• 第一個節(jié)點：Span ID = A，Parent ID = null，Service 1 接收到請求。
• 第二個節(jié)點：Span ID = B，Parent ID= A，Service 1 發(fā)送請求到 Service 2 返回響應給Service 1 的過程。
• 第三個節(jié)點：Span ID = C，Parent ID= B，Service 2 的 中間解決過程。
• 第四個節(jié)點：Span ID = D，Parent ID= C，Service 2 發(fā)送請求到 Service 3 返回響應給Service 2 的過程。
• 第五個節(jié)點：Span ID = E，Parent ID= D，Service 3 的中間解決過程。
• 第六個節(jié)點：Span ID = F，Parent ID= C，Service 3 發(fā)送請求到 Service 4 返回響應給 Service 3 的過程。
• 第七個節(jié)點：Span ID = G，Parent ID= F，Service 4 的中間解決過程。

通過 Parent ID 就可找到父節(jié)點，整個鏈路即可以進行跟蹤追溯了。

備注：核心原理部分內(nèi)容來源：cnblogs.com/jackson0714/p/sleuth_zipkin.html

解決方案

目前，行業(yè)內(nèi)比較成熟的分布式鏈路追蹤技術解決方案如下所示。