目前，随着網際網路架構的擴張，分布式系統變得日趨複雜，越來越多的元件開始走向分布式化，如微服務、消息收發、分布式資料庫、分布式緩存、分布式對象存儲、跨域調用，這些元件共同構成了繁雜的分布式網絡。
如上圖右側所示，當應用a發出某個請求時，其背後可能有數十個甚至更多的服務被調用，可謂是“牽一發而動全身”。
如果将分布式系統比作高速公路網，每個前端的請求就相當于高速上行駛的車輛，而處理請求的應用就是高速上的收費站，在收費站上将車輛通行資訊記錄成日志，包括時間、車牌、站點、公路、價格等，如果将所有收費站上的日志整合在一起，便可以通過唯一的車牌号确定該車的完整通行記錄；分布式調用系統跟蹤和監控就是類比這種思想，對每一次請求進行跟蹤，進而明确每個請求所經過的應用、耗時等資訊。
阿裡巴巴中分布式調用跟蹤是采用鷹眼（eagleeye）系統來實作的，鷹眼是基于日志的分布式調用跟蹤系統，其關鍵核心在于調用鍊，為每個請求生成全局唯一的id（traceld），通過它将不同系統的“孤立的”調用資訊關聯在一起，還原出更多有價值的資料。
上圖是一條來自生成環境的調用鍊，在應用名列可以看到請求中間過程所經過的一系列應用，可以看到最先經過buy應用，後續調用delivery、tee、inventoryplatform等，形成調用樹（樹上的縮進表示嵌套關系），從調用樹上很容易看到前端請求的完整處理過程。
另外值得注意的一點，上圖是由白色背景和藍色背景組成。其中藍色背景表示調用鍊經過消息之後，變成了異步的消息通道，其後續處理過程也都是異步處理過程；白色背景處表示同步過程。一般而言，對于前端的使用者等待的時間是不包含藍色背景内的耗時，也就是隻包含了同步處理的時間。
在上圖所示的頁面中也清晰地展示了每塊應用處理請求得具體耗時，非常直覺地進行定位；此外，狀态資訊也是值得關注的一點，如上圖所示，如果在調用過程中發生錯誤，就會出現異常（圖中紅色區域所标注），通過點選狀态碼，使用者可以檢視錯誤的具體資訊。
下面來具體看一下調用鍊的具體使用場景。
可以在業務異常日志的錯誤資訊中找到traceld（如圖中的traceid=ac18287913742691251746923），之後在鷹眼系統中隻需要輸入traceld，就可以看到調用鍊中具體的情況，在調用鍊上更加直覺地定位到問題（如上圖所示），層層排查後确定問題的所在。
對于分布式調用跟蹤系統而言，它并不僅僅提供了調用鍊這一功能，因為它對所有中間件的調用做埋點，是以中間件上的所有情況都可以監控的到。是以，在形成調用鍊的過程中也會形成一份詳細的調用監控報表，它與其他監控的不同之處在于：該監控報表是帶有上下鑽取功能的報表。因為調用鍊是詳細的底層統計，對上可以形成的報表次元是非常豐富的，在上圖所示的調用報表裡，不僅可以看到服務的情況，還可以下鑽到它所調用服務的情況；另外從監控報表上還可以進行調用鍊的下鑽，檢視清晰的調用鍊資訊。
鍊路與調用鍊不同，鍊路是一個統計學的概念，而調用鍊是單體調用的過程。分析鍊路的價值主要展現在以下幾點：
拓撲形态分析：分析來源、去向，識别不合理來源；
依賴樹立：識别易故障點/性能瓶頸、強依賴等問題；
容量估算：根據鍊路調用比例、峰值qps評估容量；
下面來具體分析這三點。
上圖是全局調用拓撲圖，可以明顯的看到不同的應用之間存在複雜的調用關系，也可以檢視某個應用和其他應用之間的調用關系以及調用的頻次；圖中紅點表示在調用過程中出現錯誤。
通過該拓撲圖，架構師可以清楚地觀察到系統上的調用情況，此外，點選全局調用拓撲圖上的某個節點，可以下鑽到下圖所示的單應用鍊路拓撲圖。
在以某應用為中心的單應用鍊路拓撲圖，可以檢視該應用在調用鍊上下遊的應用之間的具體調用關系。
鍊路分析除了進行拓撲形态分析之外，還能進行依賴梳理：識别易故障點、性能瓶頸、強依賴等問題；也可以根據鍊路調用比例、峰值qps 評估容量。
上圖是一份單鍊路報表，單鍊路報表是指同一http入口的調用鍊疊加形成、包含所有依賴情況的調用關系。上圖左側模糊部分是一棵調用樹，它表現了應用之間的依賴關系，與調用鍊不同的是，這種依賴關系是統計學意義上的依賴，是以在該報表上包含了qps和統計qps統計類型的資料。在進行容量預估時，可以很容易分析上遊應用對下遊造成的壓力。
在該報表上，還可以進行依賴梳理方面的工作，根據出錯率确定易故障點；此外，那些存在強依賴、錯誤阻塞的地方都是潛在故障點；最後，還可以根據耗時比例進行相關的性能優化。
調用鍊作為排查問題的核心，通過其可以将各類資料關聯在一起，提高問題排查能力。下面來看一下調用鍊的最佳實踐——全息排查。
在實際問題排查中經常會遇到上圖所示的問題，這些問題都具有明确的業務含義，這些問題盡管看上去和調用鍊并無關系，但可以用調用鍊得到很好的解決。如上圖右側所示，a-e五個節點在調用鍊上承載的調用關系實際上都是一些具體的業務，例如節點a處理http請求表示賣家abc點選下單；在調用b時其實在計算賣家xyz在該路線的運費等等。在排查問題時，最有價值的切入點在于先從業務問題出發，再進一步在調用鍊中确認問題所在之處。
我們可以根據業務時間id反查調用鍊，進而順藤摸瓜找到更多的上下遊業務資訊。例如一個交易訂單（2135897412389123）發現存在問題，我們可以根據訂單号查到與之綁定的traceid，根據traceid不僅可以檢視系統調用的事件，還可以看到與業務相關的事件，如使用者下單、目前庫存情況等，也就是說根據交易id可以在調用鍊上檢視交易、商品庫存以及支付等資訊，大大提升錯誤排查速度。
回到剛才提到的三個問題：要分析由哪筆訂單操作引起的調用異常其實是traceid到orderid的一次關聯；要分析異常訂單是否由賣家對所在商品的運費模闆的某些異常操作導緻其實是根據orderid關聯itemid再關聯templateid，最後關聯到traceid；對于第三個問題，通常是由userid關聯到traceid再關聯到mybizld。
根據這些問題及其解決方案可以看到，全息排查的關鍵在于：業務時間id與traceid/rpcid的雙向綁定。
常見的雙向綁定有三種實作方式：
在調用鍊的tags 或userdata 中放入業務事件id，進而建立調用鍊到業務事件id 的關聯；
打通traceid 到資料庫的資料變更的關聯，進而建立調用鍊到每次資料變更的關聯；
在業務日志中記錄traceid、業務事件id 等資訊，進而建立調用鍊與業務事件日志的關聯。
目前，基于阿裡雲arms內建了上述三種雙向綁定實作方式，使用者可以在産品上輕松配置搞定。
上圖是阿裡巴巴内部的全息排查全景圖。該圖的核心部分是鷹眼最初覆寫的的後端系統，包括服務、消息和緩存；在前端層面涉及前端使用者通路日志，具有關聯traceid的能力；在移動端也具有關聯traceid的能力；通過對traceid進行關聯，可以打通使用者通路日志；在資料庫層面，通過sql語句将traceid傳到資料庫的binlog中，在資料複制和資料分發時可以非常容易擷取到每次資料變更的記錄與traceid的關聯；另外，業務通過自身的業務日志和異常堆棧也可以列印traceid；這樣一來，業務層、移動端、前端、資料層所有的元件都與traceid進行了關聯，再關聯上業務中的訂單号、使用者号、商品号、物流單号、交易單号，最後形成一個非常強大的生态——從一個調用鍊可以看到上下遊相關的訂單、使用者的詳細資訊，同時可以根據訂單查到與該訂單相關的業務id，再根據業務id擴充到與其相關的更多id，甚至是traceid，最後形成traceid-->業務id-->新的traceid的網狀結構，将排查問題轉化為從網狀結構中尋找需要的整段資訊。
目前，通過阿裡雲提供的edas結合arms可以打造立體化監控體系，其中edas用于應用管控層面，用于控制鍊路和應用；而arms更關注業務營運層面，如電商交易、車聯網、零售；實際上，監控需要全方位關注業務、鍊路、應用、系統，通過arms與edas互相補全，形成了立體化監控體系。
<a href="https://common-buy.aliyun.com/?commoditycode=prepaid_edas#/buy">開通edas 進階版 使用鍊路監控</a>
<a href="https://www.aliyun.com/product/edas">edas産品詳情</a>
<a href="https://page.aliyun.com/form/aliware_edas_product_application/page.htm">申請edas産品專家一對一咨詢</a>
<a href="https://www.aliyun.com/product/arms">arms産品詳情</a>