作者：雲棲社群

原文：

摘要： 本文將從分散式系統呼叫的複雜現狀說起，具體分析呼叫鏈的三大使用場景，以及呼叫鏈的最佳實踐，簡述如何將呼叫鏈作為排查問題的核心，透過其可以將各類資料關聯在一起，提高問題排查能力。【最新快訊】EDAS上線方法追蹤新特性，打通應用診斷的"最後一公里"。

1. 分散式呼叫系統的現狀

當前，隨著網際網路架構的擴張，分散式系統變得日趨複雜，越來越多的元件開始走向分散式化，如微服務、訊息收發、分散式資料庫、分散式快取、分散式物件儲存、跨域呼叫，這些元件共同構成了繁雜的分散式網路。

如上圖右側所示，當應用A發出某個請求時，其背後可能有數十個甚至更多的服務被呼叫，可謂是“牽一髮而動全身”。 如果將分散式系統比作高速公路網，每個前端的請求就相當於高速上行駛的車輛，而處理請求的應用就是高速上的收費站，在收費站上將車輛通行資訊記錄成日誌，包括時間、車牌、站點、公路、價格等，如果將所有收費站上的日誌整合在一起，便可以透過唯一的車牌號確定該車的完整通行記錄；分散式呼叫系統跟蹤和監控就是類比這種思想，對每一次請求進行跟蹤，進而明確每個請求所經過的應用、耗時等資訊。

阿里巴巴的分散式呼叫跟蹤實現——鷹眼

阿里巴巴中分散式呼叫跟蹤是採用鷹眼（EagleEye）系統來實現的，鷹眼是基於日誌的分散式呼叫跟蹤系統，其關鍵核心在於呼叫鏈，為每個請求生成全域性唯一的ID（Traceld），透過它將不同系統的“孤立的”呼叫資訊關聯在一起，還原出更多有價值的資料。

上圖是一條來自生成環境的呼叫鏈，在應用名列可以看到請求中間過程所經過的一系列應用，可以看到最先經過Buy應用，後續呼叫delivery、tee、inventoryplatform等，形成呼叫樹（樹上的縮排表示巢狀關係），從呼叫樹上很容易看到前端請求的完整處理過程。

另外值得注意的一點，上圖是由白色背景和藍色背景組成。其中藍色背景表示呼叫鏈經過訊息之後，變成了非同步的訊息通道，其後續處理過程也都是非同步處理過程；白色背景處表示同步過程。一般而言，對於前端的使用者等待的時間是不包含藍色背景內的耗時，也就是隻包含了同步處理的時間。

在上圖所示的頁面中也清晰地展示了每塊應用處理請求得具體耗時，非常直觀地進行定位；此外，狀態資訊也是值得關注的一點，如上圖所示，如果在呼叫過程中發生錯誤，就會出現異常（圖中紅色區域所標註），透過點選狀態碼，使用者可以檢視錯誤的具體資訊。

鷹眼於2013年在阿里巴巴內部上線，目前支撐阿里集團泛電商、高德、優酷等業務，技術層面覆蓋前端閘道器接入層、遠端服務呼叫框架（RPC）、訊息佇列、資料庫、分散式快取、自定義元件（如支付、搜尋SDK、本地方法埋點等）；2016年在阿里雲的中介軟體雲產品EDAS釋出，對外提供服務；此外，鷹眼也支援專有云輸出。

2. 使用場景

下面來具體看一下呼叫鏈的具體使用場景。

定位異常、耗時問題

可以在業務異常日誌的錯誤資訊中找到Traceld（如圖中的TraceId=ac18287913742691251746923），之後在鷹眼系統中只需要輸入Traceld，就可以看到呼叫鏈中具體的情況，在呼叫鏈上更加直觀地定位到問題（如上圖所示），層層排查後確定問題的所在。

帶呼叫鏈下鑽的監控報表

對於分散式呼叫跟蹤系統而言，它並不僅僅提供了呼叫鏈這一功能，因為它對所有中介軟體的呼叫做埋點，所以中介軟體上的所有情況都可以監控的到。因此，在形成呼叫鏈的過程中也會形成一份詳細的呼叫監控報表，它與其他監控的不同之處在於：該監控報表是帶有上下鑽取功能的報表。因為呼叫鏈是詳細的底層統計，對上可以形成的報表維度是非常豐富的，在上圖所示的呼叫報表裡，不僅可以看到服務的情況，還可以下鑽到它所呼叫服務的情況；另外從監控報表上還可以進行呼叫鏈的下鑽，檢視清晰的呼叫鏈資訊。

鏈路分析

鏈路與呼叫鏈不同，鏈路是一個統計學的概念，而呼叫鏈是單體呼叫的過程。分析鏈路的價值主要體現在以下幾點：

1. 拓撲形態分析：分析來源、去向，識別不合理來源；
2. 依賴梳理：識別易故障點/效能瓶頸、強依賴等問題；
3. 容量估算：根據鏈路呼叫比例、峰值QPS評估容量；

下面來具體分析這四點。

A. 拓撲形態分析：分析來源、去向，識別不合理來源

上圖是全域性呼叫拓撲圖，可以明顯的看到不同的應用之間存在複雜的呼叫關係，也可以檢視某個應用和其他應用之間的呼叫關係以及呼叫的頻次；圖中紅點表示在呼叫過程中出現錯誤。 透過該拓撲圖，架構師可以清楚地觀察到系統上的呼叫情況，此外，點選全域性呼叫拓撲圖上的某個節點，可以下鑽到下圖所示的單應用鏈路拓撲圖。

在以某應用為中心的單應用鏈路拓撲圖，可以檢視該應用在呼叫鏈上下游的應用之間的具體呼叫關係。

B. 依賴梳理和容量估算

鏈路分析除了進行拓撲形態分析之外，還能進行依賴梳理：識別易故障點、效能瓶頸、強依賴等問題；也可以根據鏈路呼叫比例、峰值QPS 評估容量。

上圖是一份單鏈路報表，單鏈路報表是指同一HTTP入口的呼叫鏈疊加形成、包含所有依賴情況的呼叫關係。上圖左側模糊部分是一棵呼叫樹，它表現了應用之間的依賴關係，與呼叫鏈不同的是，這種依賴關係是統計學意義上的依賴，因此在該報表上包含了QPS和統計QPS統計型別的資料。在進行容量預估時，可以很容易分析上游應用對下游造成的壓力。

在該報表上，還可以進行依賴梳理方面的工作，根據出錯率確定易故障點；此外，那些存在強依賴、錯誤阻塞的地方都是潛在故障點；最後，還可以根據耗時比例進行相關的效能最佳化。

3.最佳實踐

呼叫鏈作為排查問題的核心，透過其可以將各類資料關聯在一起，提高問題排查能力。下面來看一下呼叫鏈的最佳實踐——全息排查。

全息排查

在實際問題排查中經常會遇到上圖所示的問題，這些問題都具有明確的業務含義，這些問題儘管看上去和呼叫鏈並無關係，但可以用呼叫鏈得到很好的解決。如上圖右側所示，A-E五個節點在呼叫鏈上承載的呼叫關係實際上都是一些具體的業務，例如節點A處理HTTP請求表示賣家abc點選下單；在呼叫B時其實在計算賣家xyz在該路線的運費等等。在排查問題時，最有價值的切入點在於先從業務問題出發，再進一步在呼叫鏈中確認問題所在之處。

我們可以根據業務時間ID反查呼叫鏈，從而順藤摸瓜找到更多的上下游業務資訊。例如一個交易訂單（2135897412389123）發現存在問題，我們可以根據訂單號查到與之繫結的TraceId，根據TraceId不僅可以檢視系統呼叫的事件，還可以看到與業務相關的事件，如使用者下單、當前庫存情況等，也就是說根據交易ID可以在呼叫鏈上檢視交易、商品庫存以及支付等資訊，大大提升錯誤排查速度。

回到剛才提到的三個問題：要分析由哪筆訂單操作引起的呼叫異常其實是TraceId到OrderId的一次關聯；要分析異常訂單是否由賣家對所在商品的運費模板的某些異常操作導致其實是根據OrderId關聯ItemId再關聯TemplateId，最後關聯到TraceId；對於第三個問題，通常是由UserId關聯到TraceId再關聯到MyBizld。

根據這些問題及其解決方案可以看到，全息排查的關鍵在於：業務時間id與TraceId/RpcId的雙向繫結。 常見的雙向繫結有三種實現方式：

1. 在呼叫鏈的Tags 或UserData 中放入業務事件id，從而建立呼叫鏈到業務事件id 的關聯；
2. 打通TraceId 到資料庫的資料變更的關聯，從而建立呼叫鏈到每次資料變更的關聯；
3. 在業務日誌中記錄TraceId、業務事件id 等資訊，從而建立呼叫鏈與業務事件日誌的關聯。

目前，基於阿里雲ARMS整合了上述三種雙向繫結實現方式，使用者可以在產品上輕鬆配置搞定。

全息排查全景圖

上圖是阿里巴巴內部的全息排查全景圖。該圖的核心部分是鷹眼最初覆蓋的的後端系統，包括服務、訊息和快取；在前端層面涉及前端使用者訪問日誌，具有關聯TraceId的能力；在移動端也具有關聯TraceId的能力；透過對TraceId進行關聯，可以打通使用者訪問日誌；在資料庫層面，透過SQL語句將TraceId傳到資料庫的binlog中，在資料複製和資料分發時可以非常容易獲取到每次資料變更的記錄與TraceId的關聯；另外，業務透過自身的業務日誌和異常堆疊也可以列印TraceId；這樣一來，業務層、移動端、前端、資料層所有的元件都與TraceId進行了關聯，再關聯上業務中的訂單號、使用者號、商品號、物流單號、交易單號，最後形成一個非常強大的生態——從一個呼叫鏈可以看到上下游相關的訂單、使用者的詳細資訊，同時可以根據訂單查到與該訂單相關的業務ID，再根據業務ID擴充套件到與其相關的更多ID，甚至是TraceId，最後形成TraceId-->業務ID-->新的TraceId的網狀結構，將排查問題轉化為從網狀結構中尋找需要的整段資訊。

透過EDAS+ARMS打造的立體化監控體系

目前，透過阿里雲提供的EDAS結合ARMS可以打造立體化監控體系，其中EDAS用於應用管控層面，用於控制鏈路和應用；而ARMS更關注業務運營層面，如電商交易、車聯網、零售；實際上，監控需要全方位關注業務、鏈路、應用、系統，透過ARMS與EDAS相互補全，形成了立體化監控體系。

【最新快訊】EDAS上線方法追蹤新特性，打通應用診斷的"最後一公里"

EDAS 方法追蹤能夠幫助使用者在應用執行時出現問題時，進行快速的問題排查。

典型的場景

1. 應用執行時突然發現執行某一個業務邏輯耗時很長，此時希望能夠有一種方式定位執行時程式碼各個部分的耗時，以確定耗時點在什麼地方。

2. 應用執行時一切正常，絕大部分情況下，業務執行都非常順暢，但某一例使用者反饋，當傳入XXX引數時，業務響應非常緩慢。此時希望能夠有一種方式針對特定的方法入參來觀察程式碼執行情況。

3. 一個比較複雜的程式方法，其中業務邏輯較為複雜，在真正執行時，無法確定具體呼叫了那些邏輯，以及呼叫時序。此時希望能夠有一種方式詳細的展現出方法執行的具體邏輯、時序等。

此外，以上的任何一種場景，都希望程式碼無入侵，可以在應用執行時不停機的情況下，定位問題。 
EDAS 方法追蹤採用 JVM 位元組碼增強的技術，對選中方法的所有方法呼叫增加必要的耗時與呼叫序列記錄的增強，從而達到觀看執行過程中的具體執行序列的目的。