微服務架構

圖片

如果有用戶反饋某個頁面很慢，我們知道這個頁面的請求調用鏈是 A ----->  C ----->  B ----->  D(圖片有誤)，怎么來定位是由哪個服務引起的問題呢？ 

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

圖片

可以明顯看到，由于無法準確定位每個請求經過的確切路徑，在微服務這種架構下有以下幾個痛點：

1. 排查問題難度會比較大，解決問題的周期長

2. 特定場景很難再次復用

3.系統性能瓶頸分析同樣也不同意

這就需要一個分布式調用鏈追蹤系統。

圖片

分布式調用鏈追蹤系統:設計

如果要我們自己實現一個這樣的分布式追蹤系統，該怎么去設計？

首先，我們必須得區分每個調用鏈，得給它分配一個全局唯一的 TraceID，并且在調用鏈上的每次調用都帶上這個 ID，這樣每個調用都被關聯起來了。

圖片

然后，我們得記錄所有調用的先后次序和父子關系。

假設有以上這樣的調用鏈，如果我們只記錄了這四個調用：

A---->B

B---->C

A---->D

D---->E

D---->F

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

所以必須得記錄父子關系：

A---->B 是 B---->C 的父調用

A---->D 是 D---->E 的父調用

A---->D 還是 D---->F 的父調用

圖片

Agent

微服務是來實現業務的，肯定不能來干這個監控和跟蹤的活兒，那樣對微服務的侵入性就太強了。

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

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

圖片

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

當 Agent 監測到有人調用服務 A 時，沒有 ParentSpanID，它意識到這是一次全新的調用，于是創建新的 TraceID。

當 Agent 察覺到 A 調用了 B 時，生成 SpanID = 1，并將此 ID 作為 ParentSpanID 傳遞給 B。這樣，當 B 調用 C 時，B 的 Agent 就能生成此次調用的 SpanID 為 1.1。

當 Agent 察覺到 A 調用 D 時，生成 SpanID = 2，并將此 ID 作為 ParentSpanID 傳遞給 D。

4. 在 D 調用 E 和 F 時，分別生成 SpanID 2.1 和 2.2。

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

圖片

當服務 A 調用服務 B 時， Agent 就可以做點兒手腳，修改 header 了：

圖片

數據收集

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

結構如下圖：

圖片