背景

為了快速適應業務變化，聚焦業務迭代，各大廠商都進行了分散式架構的升級改造。特別是近幾年，隨著微服務與雲原生的流行，分散式系統的規模愈發龐大，內部服務之間的呼叫也越來越複雜。

然而，引入分散式架構的同時，也帶來相應的穩定性問題。各項服務的開發人員、開發語言和部署節點等情況很可能各不相同，當分散式系統整體出現異常或者效能瓶頸的時候，依靠傳統的指標監控和日誌排查已經很難快速定位到出問題的地方。因此當下分散式系統對可觀測性提出了更高的要求，需要能夠解決以下痛點：

● 如何動態的展示各服務之間的呼叫鏈路？

● 如何快速定位故障？

● 如何分析效能瓶頸並加以調優？

分散式鏈路追蹤系統

基於上述痛點，分散式鏈路追蹤系統應運而生，其目的在於透過洞察分散式服務之間的相互呼叫，自動發現系統存在的穩定性隱患，從而為 SRE & 研發 定位風險提供有效的資料支撐。分散式鏈路追蹤可以透過以下兩塊內容完整還原一整條呼叫鏈路：

● Trace ID: 代表唯一一次請求的 ID，此 ID 一般由叢集中第一個處理請求的系統產生，並在分散式呼叫下透過網路傳遞到下一個被請求系統。

● Span: 代表了本次請求的完整資訊，包括呼叫是否成功，呼叫型別，呼叫耗時等等。其中最核心是 Span ID，代表了本次請求在整個呼叫鏈路中的位置或者說層次。

同時，基於鏈路聚合可以產生站點內部流量的全域性視角，形成網路拓撲。

分散式鏈路追蹤系統近年來發展迅速，業內也湧現出了一些開源專案和框架，並且為了實現各專案和框架的介面的統一，發展出了 OpenTracing 與 OpenTelemetry 等標準。透過鏈路標準的制定和推廣，有利於使用者透過一套資料採集、處理、匯出流程，輕鬆對接多種雲廠商，避免 vendor鎖定，有效的降低了對接和使用的成本。

BOS一直以來致力於為使用者提供無縫的可觀測能力，持續擁抱可觀測性標準，作為 OpenTelemetry專案的重要貢獻者，率先在業內提供了完整的異構應用 OpenTelemetry 鏈路接入方案，並已經在眾多機構中成功落地。

產品能力

業務智慧可觀測服務 BOS（ Business-Intelligent Observability Service）是基於螞蟻大規模技術風險防控實踐自研的一套運維平臺，具有業務數字化運維、全息可觀測定位、智慧場景化防控、一體化資料分析和大規模實踐等產品特性，將業務場景視覺化和資料業務語義化，賦能雲上 /雲下的異構應用開箱即用的智慧可觀測能力，為業務提供全方位的穩定性保障，建設業務觀測新正規化，讓穩定更有力量。

BOS的分散式鏈路追蹤系統提供了以下豐富的產品功能，致力於幫助使用者定位和解決微服務架構下的效能問題：

● 應用呼叫拓撲及詳細效能指標

  ○ 根據鏈路資料動態生成，幫助使用者梳理微服務架構下各應用之間的呼叫關係。

  ○ 根據呼叫耗時，呼叫錯誤率等效能指標，自動定位和標註異常應用和異常呼叫關係，幫助使用者快速定位故障。

● 鏈路資料查詢

  ○ 支援多維度的查詢條件，例如超過多少耗時，呼叫是否失敗，具體的呼叫介面和方法等等，準確定位到感興趣的呼叫關係，進而跳轉到具體而詳細的鏈路詳情展示。

● 鏈路詳情展示

  ○ 透過多種展現方式，例如樹狀圖，拓撲圖、時序圖等，幫助使用者觀測到單條鏈路的完整呼叫關係。

  ○ 根據每次呼叫的成功與否以及耗時，自動標註出整條鏈路中異常或者潛在效能瓶頸的呼叫，幫助使用者快速定位具體的單次呼叫，透過詳盡的單次呼叫詳情，助力使用者進行應用調優。

  ○ 在鏈路詳情中同時打通了與監控和日誌資料的關聯，使用者可以非常容易的檢視到相關聯的全量可觀測性資料，幫助定位問題的根本原因。

為了方便使用者完成接入， BOS提供了業內所有常用的鏈路資料格式的對接能力，涵蓋了 OpenTelemetry， SofaTracer， Skywalking， Zipkin以及 Jaeger等等，使用者應用無論之前是否已經接入了鏈路框架，都可以快速的接入並體驗 BOS分散式鏈路追蹤系統的完整能力。

透過上述 BOS分散式鏈路追蹤產品提供的豐富功能，將賦予使用者以下的宏觀能力：

風險定位

在分散式場景下，服務呼叫錯綜複雜，並且涉及到眾多中介軟體的呼叫，出現問題的時候如何排查和定位具體的問題應用和服務，如果依靠傳統的單應用監控指標或者日誌，必然要涉及整條呼叫鏈路所有相關應用指標的來回切換，費時費力非常困難。

透過 BOS分散式鏈路跟蹤產品能夠幫助使用者迅速定位到有問題的應用和服務，協助快速解決風險。

● 完整的應用呼叫拓撲關係：自動發現該服務的歷史呼叫，以及對所有中介軟體的呼叫，繪製整個系統呼叫關係的拓撲圖。

● 快速定位不健康應用：在呼叫關係拓撲中，對不健康應用進行顯式標識，便於快速發現有問題應用並進行分析。

● 服務效能詳情：呼叫拓撲中的應用都可以單獨進行下鑽分析，可以從吞吐量、錯誤率、響應時間等指標出發，對應用效能進行詳細分析。

應用效能最佳化

BOS分散式鏈路產品透過應用呼叫拓撲和鏈路詳情等分析能力，全方位的展示應用以及具體介面方法層面的效能資料，可以幫助使用者快速定位到具體的單個造成效能瓶頸的呼叫所在或者是否存在不合理的呼叫關係，進而幫助使用者進行應用的效能最佳化。

● 呼叫鏈路聚合彙總：對所有的呼叫資訊進行聚合彙總，對各個應用的呼叫情況以及響應情況進行分析。

● 關鍵路徑：快速發現整個系統呼叫拓撲中，關鍵應用的路徑。

● 最佳化不合理呼叫：及時發現某些不合理的呼叫並進行處理，如頻繁進行資料庫操作等。

使用場景

洞察微服務呼叫拓撲

在大規模的微服務系統中，完整的鏈路呼叫拓撲可以提供一個全域性的視角，幫助發現不同應用之間的依賴關係，實時的以端到端的方式展示微服務應用架構。

此外針對應用開發者，也可以實時展示單個應用上下游呼叫關係的拓撲圖。

透過如下的服務呼叫拓撲圖，使用者可以獲得：

● 全鏈路資訊展示：展示應用程式及其關聯內部、外部服務系統的響應時間、吞吐量和狀態，同時顯示了各個服務之間的相互影響。如果一項服務中斷，您可以立即看到其他服務所受到的影響。

● 後端服務效能管理：快速、持續地監控應用效能，第一時間發現定位應用問題。

● 實時執行狀態：透過監控黃金指標（吞吐量，響應時間， 錯誤率）、視覺化的應用的效能監控描述，快速瞭解每個應用的執行狀態。

更進一步，對於感興趣的應用，可以檢視具體的應用效能詳情，瞭解應用在指定時間範圍內的效能指標資料。具體的資料涵蓋了 HTTP呼叫、 RPC呼叫、 SQL呼叫、 NoSQL呼叫、訊息呼叫的黃金指標統計（比如吞吐量、平均響應耗時、錯誤率、滿意度等）趨勢和指標明細。

同時應用效能詳情支援基於應用 > 上下游應用 > 介面等逐層下鑽分析，建立從底層至上層間的資料關聯資訊，從而深度分析分散式場景下影響應用效能的問題根因。若發現某個介面呼叫異常，可跳轉鏈路查詢介面，按照相關引數查詢鏈路。

定位異常呼叫與應用

服務呼叫的最關鍵的指標是 錯誤率 和 平均耗時，透過實時計算這兩項指標，配合上可自定義的評判標準，可以生成上述服務呼叫拓撲圖中部分呈現為黃色異常與紅色錯誤狀態的服務呼叫和應用自身。

應用評價標準

異常應用的評價是透過實時計算應用的平均介面耗時以及錯誤率實現的，使用者可以配置閾值，一旦超過閾值，將分別呈現為黃色異常與紅色錯誤狀態。

呼叫評價標準

異常呼叫的評判採用的是 Apdex標準， Apdex全稱是 Application Performance Index，是用於評估應用效能的開放標準，從使用者的角度出發，將響應時間的表現轉化為對應用效能的可量化滿意度評價。

Apdex根據響應時間以及代表使用者滿意的響應時間界限 T，定義了三種效能表現：

● 滿意：響應時間小於 T。

● 可接受：響應時間介於 T 到 4T 之間。

● 不可接受： 響應時間大於 4T。

將一段時間的響應時間統計出來後，便可根據下述計算公式得出 Apdex指數：

Apdex 指數 = （滿意數 + 0.5 * 可接受數）/ 總樣本數 。

Apdex指數大於 0.7的被認為擁有較為良好的效能，低於 0.7將會被標紅，提醒可能存在的效能問題。

應用效能調優

當排查到異常呼叫或者異常應用存在的時候，研發人員可以藉助分散式鏈路追蹤服務進行效能調優。

在應用效能分析過程中，對於技術研發來說，最為關鍵的指標是吞吐量、平均響應耗時、錯誤率。因此，分散式鏈路產品設計過程中， BOS 透過聚合鏈路資料，輕鬆展示服務呼叫明細，提供分鐘級資料統計。如上述 服務呼叫拓撲 -應用效能詳情圖 所示。

當發現平均響應耗時較高或者錯誤率較高請求時，透過點選明細最右邊一欄的實時鏈路查詢按鈕，可以跳轉到包含相關呼叫資訊的鏈路查詢頁面，透過對耗時的排序，可以定位到耗時較高的單條鏈路。

進而透過點選感興趣的呼叫鏈路，可以看到更為詳細的呼叫樹狀圖，單鏈路拓撲圖以及時序圖：

透過以上三種鏈路詳情展示圖，可以很方便的找到在整條鏈路中，哪些呼叫出現了失敗的情況，哪些呼叫的耗時過長需要最佳化。

更進一步：

● 點選鏈路詳情：可以看到更多鏈路的細節資訊，並且可以查到相關聯的業務日誌和錯誤日誌。

● 點選監控詳情：可以跳轉至 BOS的應用監控頁面，查到更為詳細的應用監控指標，比如系統指標和 JVM指標等。

透過鏈路、日誌和監控的全方位資訊，應用的研發人員可以很方便的發現問題和瓶頸所在，並加以最佳化，進入 效能最佳化 ->鏈路分析 ->效能最佳化 的正迴圈中，最終達到滿意的效能結果。

應用接入

看到前面的鏈路分析使用場景，是不是已經很迫不及待要把應用接入到分散式鏈路追蹤系統了？

彆著急，接入的方法很多樣，也很方便。

接入的核心就是如何為應用生成鏈路資料，並讓分散式鏈路追蹤系統採集到。

我們可以利用業內優秀的鏈路框架幫助應用進行鏈路改造，目前業內常用的鏈路框架有 OpenTelemetry， SofaTracer， Skywalking， Zipkin與 Jaeger等等，其中一些框架針對部分開發語言和部分中介軟體可以做到無侵入式的鏈路改造，還有一些場景需要透過相應的 SDK進行鏈路能力的引入增強。

隨後， BOS分散式鏈路追蹤系統可以接收應用框架主動上報上來的鏈路資料，或者透過採集應用框架列印落盤的鏈路日誌檔案來收集鏈路資料。

以 OpenTelemetry為例， Java應用只要接入一個探針，無需修改任何應用程式碼，即可自動生成鏈路資料，並透過 RPC介面上報至 BOS。

技術內幕

資料收集與解析

透過應用接入， BOS分散式鏈路追蹤系統會根據接入方式的不同，分別用不同的方法來接受框架生成的原始鏈路資料，比如日誌採集、 RPC接收或者是 HTTP協議接收等等。

然後不同原始鏈路資料的格式也各不相同，因此首先需要對這些原始資料按照不同的規則進行解析，解析後將構建出與框架無關的鏈路 Span資料，這些資料將被儲存至鏈路資料庫中。

資料修復

接下來，需要對鏈路資料進行修復操作，這塊修復的原因是，分散式鏈路資料是一種很特殊的資料型別，兩個應用之間的一次呼叫實際上會產生兩條鏈路資料，分別為客戶端 Span和服務端 Span，而從單個應用的角度出發，應用的視角里不會很清楚的知道呼叫對端的詳細資訊，所以這兩條鏈路資料通常情況下都會缺少部分對端的資訊。

因此，分散式鏈路追蹤系統會收集鏈路呼叫兩端各自的 Span，然後進行資料修復，藉助雙方各自的資料修復出呼叫的完整資訊，為後續的指標和拓撲資料計算做準備。

指標計算

下一步，根據鏈路資料的不同呼叫型別（ HTTP， RPC， SQL， NoSQL，訊息等），分別進行相應的效能指標計算和聚合，並將相關指標資訊存入時序性資料庫中。

拓撲計算

接下來，由於之前已經經過了資料修復，從一個 Span裡可以同時獲取到兩端的應用資訊，因此可以從應用拓撲的角度分別計算和儲存兩端的拓撲節點，以及這次呼叫代表的拓撲邊的相關資料。

為了從更多的角度觀測拓撲節點和拓撲邊的細節：

● 在拓撲節點的服務指標計算過程中，會根據拓撲節點處在呼叫方還是服務方分別進行彙總統計。

● 在拓撲邊的服務指標計算過程中，會根據呼叫型別的不同而分別進行彙總統計。

當拓撲節點和拓撲邊的相關資料計算以後，會經過序列化最終存入相關的資料庫之中。

產品展示

至此，鏈路分析所需要的所有資料都已經被解析落盤，當使用者進行應用拓撲查詢或者單條鏈路查詢的時候， BOS分散式鏈路追蹤系統會針對不同場景查詢不同型別的資料，進行拓撲或者呼叫鏈的還原。其中：

• 應用拓撲：需要先將拓撲關係繪製出來，並根據拓撲查詢時間範圍，將拓撲節點、拓撲邊的相關聯指標資料進行一定程度的降取樣，併為呼叫明細資訊進行指標的合併計算。

• 鏈路詳情：需要將一條鏈路所有的 Span資訊全部獲取到，緊接著根據父子關係，兄弟關係等等進行呼叫鏈的精確還原。在實際應用過程中，經常還會遇到某些應用因為一些原因無法接入鏈路系統的情況，進而導致呼叫出現 Span部分缺失的情況，這種時候 BOS 也會根據相關 Span接入方式的不同，從鏈路框架的資料生成原理出發，儘可能的排除掉這些干擾，還原出完整的鏈路呼叫關係。

總結

最後，總結一下 BOS分散式鏈路追蹤產品的核心特性：

• 完全相容業內常用的各種鏈路框架，方便業務以各種形式進行接入。

• 提供完整的應用呼叫拓撲關係，可以從全域性的角度快速定位不健康的應用以及應用間呼叫。

• 從吞吐量、錯誤率、響應時間等指標出發，提供詳細的應用效能分析。

• 提供豐富的鏈路查詢功能，準確定位到感興趣的鏈路。

• 對於單條鏈路，提供豐富的分析能力，透過樹狀圖，拓撲圖以及時序圖幫助發現關鍵路徑以及不合理和異常的呼叫。

• 透過鏈路、監控與日誌的三位一體能力，提供完整的應用可觀測能力，可以細化觀察到某一次呼叫相關的所有可觀測資料。

目前， BOS分散式鏈路追蹤產品已經廣泛應用在包括交通銀行，中華財險，寧波銀行，四川農信在內的多家機構，持續幫助使用者發現和解決應用故障以及效能問題。

後續我們會持續分享分散式鏈路追蹤能力持續演進過程中的落地與思考，歡迎大家提出任何意見與建議。