本章概述

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

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

分布式鏈路追蹤

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

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

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

另外，在分布式與微服務(wù)場(chǎng)景下，我們需要解決如下問題：

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

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

在分布式鏈路追蹤中，可以統(tǒng)計(jì)調(diào)用每個(gè)微服務(wù)的耗時(shí)，請(qǐng)求會(huì)經(jīng)過哪些微服務(wù)的流轉(zhuǎn)，每個(gè)微服務(wù)的運(yùn)行狀況等信息。

核心原理

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

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

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

• 第一步：用戶端調(diào)用 Service 1，生成一個(gè) Request，Trace ID 和 Span ID 為空，那個(gè)時(shí)候請(qǐng)求還沒有到 Service 1。
• 第二步：請(qǐng)求到達(dá) Service 1，記錄了 Trace ID = X，Span ID 等于 A。
• 第三步：Service 1 發(fā)送請(qǐng)求給 Service 2，Span ID 等于 B，被稱作 Client Sent，即用戶端發(fā)送一個(gè)請(qǐng)求。
• 第四步：請(qǐng)求到達(dá) Service 2，Span ID 等于 B，Trace ID 不會(huì)改變，被稱作 Server Received，即服務(wù)端取得請(qǐng)求并準(zhǔn)備開始解決它。
• 第五步：Service 2 開始解決這個(gè)請(qǐng)求，解決完之后，Trace ID 不變，Span ID = C。
• 第六步：Service 2 開始發(fā)送這個(gè)請(qǐng)求給 Service 3，Trace ID 不變，Span ID = D，被稱作 Client Sent，即用戶端發(fā)送一個(gè)請(qǐng)求。
• 第七步：Service 3 接收到這個(gè)請(qǐng)求，Span ID = D，被稱作 Server Received。
• 第八步：Service 3 開始解決這個(gè)請(qǐng)求，解決完之后，Span ID = E。
• 第九步：Service 3 開始發(fā)送響應(yīng)給 Service 2，Span ID = D，被稱作 Server Sent，即服務(wù)端發(fā)送響應(yīng)。
• 第十步：Service 3 收到 Service 2 的響應(yīng)，Span ID = D，被稱作 Client Received，即用戶端接收響應(yīng)。
• 第十一步：Service 2 開始返回 響應(yīng)給 Service 1，Span ID = B，和第三步的 Span ID 相同，被稱作 Client Received，即用戶端接收響應(yīng)。
• 第十二步：Service 1 解決完響應(yīng)，Span ID = A，和第二步的 Span ID 相同。
• 第十三步：Service 1 開始向用戶端返回響應(yīng)，Span ID = A、
• Service 3 向 Service 4 發(fā)送請(qǐng)求和 Service 3 相似，對(duì)應(yīng)的 Span ID 是 F 和 G。可以參照上面前面的第六步到第十步。

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

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

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

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

解決方案

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