微服務(wù)追蹤系統(tǒng)

上文我們學(xué)習(xí)了一下分布式調(diào)用鏈追蹤系統(tǒng)的原理和實踐，有些讀者對其中的實現(xiàn)原理提出了一些疑問，所以有了這篇專門寫給小白看的微服務(wù)追蹤系統(tǒng)，相信大家看完對其原理會有更透徹的理解，這里感謝公號「碼農(nóng)翻身」劉欣老師的指導(dǎo)！

前言

在微服務(wù)架構(gòu)中，一次請求往往涉及到多個模塊，多個中間件，多臺機器的相互協(xié)作才能完成。這一系列調(diào)用請求中，有些是串行的，有些是并行的，那么如何確定這個請求背后調(diào)用了哪些服務(wù)，哪些模塊，哪些節(jié)點及調(diào)用的先后順序？如何定位每個模塊的性能問題？本文將為你揭曉答案。

微服務(wù)架構(gòu)

這是一個稍微復(fù)雜的例子

如果有用戶反饋某個頁面很慢，我們知道這個頁面的請求調(diào)用鏈是 A -----> ?C -----> ?B -----> ?D，此時如何定位可能是哪個模塊引起的問題呢？?

更進一步，如果每個服務(wù) Service A,B,C,D 都部署在好幾臺機器上。怎么知道某個請求調(diào)用了服務(wù)的具體哪臺機器呢？

可以明顯看到，由于無法準確定位每個請求經(jīng)過的確切路徑，在微服務(wù)這種架構(gòu)下有以下幾個痛點：

1. 排查問題難度大，周期長

2. 特定場景難復(fù)現(xiàn)

3.系統(tǒng)性能瓶頸分析較難

有沒有一種辦法可以準確地產(chǎn)生完整的調(diào)用鏈，并且用可視化的方式呈現(xiàn)出來呢？

這就需要一個分布式調(diào)用鏈追蹤系統(tǒng)。

分布式調(diào)用鏈追蹤系統(tǒng):設(shè)計

想想看，如果要我們自己實現(xiàn)一個這樣的分布式追蹤系統(tǒng)，該怎么去設(shè)計？

首先，我們必須得區(qū)分每個調(diào)用鏈（起個時髦的名稱叫?Trace），得給它分配一個全局唯一的 ID （稱為?TraceID），并且在調(diào)用鏈上的每次調(diào)用都帶上這個 ID，這樣每個子調(diào)用都被關(guān)聯(lián)起來了。

其次，我們得記錄所有調(diào)用的先后次序和父子關(guān)系。

假設(shè)有以上這樣的調(diào)用鏈，如果我們只記錄了這四個調(diào)用：

A---->B

B---->C

A---->D

D---->E

D---->F

雖然我們知道它屬于一個調(diào)用（TraceID 相同），還是無法畫出完整的調(diào)用拓撲圖。

所以必須得記錄父子關(guān)系：

A---->B 是 B---->C 的父調(diào)用

A---->D 是 D---->E 的父調(diào)用

A---->D 還是 D---->F 的父調(diào)用

如何記錄呢？需要給每個調(diào)用分配一個ID (稱為 SpanID)，并且把這個 ID 傳遞給子調(diào)用， 子調(diào)用根據(jù) Parent Span ID 生成自己的 SpanID：

用表格展示是這樣：

這樣根據(jù) id 間的關(guān)系就很容易據(jù)此畫出調(diào)用鏈了（即可視化視圖）

魔法師Agent

前面說得挺容易，但是在分布式的環(huán)境下，如何才能正確地生成 TraceID, ParentSpanID, SpanID 呢？

微服務(wù)是來實現(xiàn)業(yè)務(wù)的，肯定不能來干這個監(jiān)控和跟蹤的活兒，那樣對微服務(wù)的侵入性就太強了。

所以必須得有一個獨立的組件，在不干擾微服務(wù)的情況下，監(jiān)控微服務(wù)之間的調(diào)用，把這些 ID 生成， 這個獨立的組件就是 Agent。

Agent 要想施展魔法，需要安裝在每個服務(wù)所在的機器上：

這個魔法師遵循的規(guī)則也非常簡單，以上圖中服務(wù) A 上的 Agent 為例：

1. 當 Agent 監(jiān)控到有人在調(diào)用服務(wù) A，但是沒有 ParentSpanID， 它就知道，這是一次全新的調(diào)用，應(yīng)該創(chuàng)建新的 TraceID。

2. 當Agent監(jiān)控到?A 調(diào)用了 B 時, 它就可以生成 SpanID = 1，并且把這個 ID 當作 ParentSpanID 傳遞給 B。這樣當 B 調(diào)用 C 的時候， B 的 Agent 就能生成此次調(diào)用的 SpanID 為 1.1 ?

3. 當 Agent 監(jiān)控到 A 調(diào)用 D 的時候，可以生成 SpanID = 2， 并且把這個 ID 當作 ParentSpanID 傳遞給 D

D 在調(diào)用 E 和 F 的時候，就能分別生成 SpanID 2.1 和 2.2

你也許注意到了一個問題：微服務(wù)都是跨進程調(diào)用的，怎么可能把 TraceID , ParentSpanID 在服務(wù)之間傳來傳去呢？

這就需要 Agent 來施展“魔法”了，Agent 需要理解微服務(wù)之間的傳輸協(xié)議，然后把 TraceID，ParentSpanID 悄悄地“藏”到某個地方，傳遞給下一個服務(wù)。

例如 HTTP 協(xié)議中定義了 Header 與 Body，Header 一般放請求的長度，請求 IP等非業(yè)務(wù)的信息。業(yè)務(wù)數(shù)據(jù)一般放在 Body 中。于是 Agent 就可以把 TraceID，ParentSpanID 悄悄地“藏到”? Header 中，這樣既不會對 Body 中的業(yè)務(wù)數(shù)據(jù)造成影響，又可以把跟蹤所需的數(shù)據(jù)傳遞給下一個服務(wù)了。

你的腦海中可能已經(jīng)想到 Agent 的實現(xiàn)原理了，這個 Agent 可以這么來實現(xiàn)：

指定微服務(wù)中的“RPC 調(diào)用的公用程序”（例如 Dubbo 中的 MonitorFilter.invoke方法）， 然后在運行時，通過動態(tài)修改字節(jié)碼的方式來增強它：

當服務(wù) A 調(diào)用服務(wù) B 時， Agent 就可以做點兒手腳，修改 header 了：

數(shù)據(jù)收集

Agent 雖然監(jiān)控、生成了足夠多的數(shù)據(jù)，但是單個 Agent 無法獲得全局視圖，我們需要一個全局的收集器來把 Agent 的數(shù)據(jù)收集上來，這樣才能生成全局的調(diào)用鏈。

數(shù)據(jù)收集器獲得了全局的數(shù)據(jù)以后，就可以畫出漂亮的調(diào)用鏈的圖了，例如這個：

小結(jié)

經(jīng)過一番探索，一個分布式調(diào)用鏈系統(tǒng)的核心組件和實現(xiàn)原理浮出水面，當然，其中還有很多細節(jié)需要處理，例如采樣的頻率，全局唯一 ID 的生成算法，UI界面等等。市面上有不少開源的分布式跟蹤系統(tǒng)，如 SkyWalking、Zipkin、Pinpoint 等等，感興趣的可以繼續(xù)深入研究。