原文：

https://baijiahao.baidu.com/s?id=1676176041873514480&wfr=spider&for=pc

轉載本文需註明出處：微信公眾號EAWorld，違者必究。

前言：

隨著微服務架構技術的普及和廣泛在企業應用中落地，由於微服務架構本身的特性，架構由一系列相對獨立的細粒度的服務組成，一個完整的業務邏輯呼叫請求的背後可能牽涉後端幾個、幾十個甚至上百個服務介面，每個服務可能是由不同的團隊開發，使用了不同的程式語言，還有可能部署在不同的機器上，分佈在不同的資料中心，對於這樣的一個邏輯呼叫關係，如果在呼叫過程中發生問題，比如說呼叫失敗，或者呼叫過程響應很慢，如何在這樣一個分散式環境下快速定位問題所在、快速分析業務處理中的響應慢的瓶頸在哪？多個微服務之間存在呼叫關係，如何在系統執行時總覽一個系統中微服務間的拓撲關係？如何完整還原一次請求的鏈路情況？

以上這些問題可以藉助鏈路追蹤技術進行解決。鏈路追蹤元件通過在微服務應用中以程式碼侵入或者非侵入的方式進行資料表示、埋點、傳遞、收集、儲存、展示等技術手段，達到將一次分散式請求還原成呼叫鏈路，將一次分散式請求的呼叫情況集中展示，比如各個服務節點上的耗時、請求具體到達哪臺機器上、每個服務節點的請求狀態等等。

目錄：

1.鏈路追蹤的應用場景

2.鏈路追蹤基本原理

3.鏈路追蹤的Demo實現

4.普元微服務平臺的鏈路追蹤應用

1.鏈路追蹤的應用場景

移動平臺8.0打開了以往eclipse平臺的枷鎖，全面擁抱了主流的VSCode編輯器，包括支援實用的cli命令列支援、及優秀的跨平臺開發框架ReactNative。

在微服務架構下，分散式系統變得日趨複雜，越來越多的元件開始走向分散式化，如微服務、分散式資料庫、分散式快取等，使得後臺服務構成了一種複雜的分散式網路，這樣一個場景下，對於使用者的每一次請求呼叫，後端執行了多少元件間的呼叫無法知曉，由於分散式的呼叫，增加了程式呼叫異常的錯誤率，在這樣的應用場景下，新的架構技術帶來了新的問題。

場景下的關鍵問題

1. 如何在請求發生異常時快速定義問題所在

2. 如何在請求響應慢的時候快速找出慢的原因

3. 如何通過日誌檔案快速定位問題的根本原因

傳統的問題排查手段

一般在系統發生問題時，比如系統異常或者系統性能出現問題時，通常都是從系統記錄的日誌檔案中找出蛛絲馬腳，而對於微服務架構下的分散式部署，日誌檔案的分散，想從日誌中查詢問題工作量很大。對於使用者某一次請求呼叫後端哪些服務，每個服務執行情況，想從日誌中獲得更是不可能的事。

對於傳統的監控告警平臺也緊針對平臺資源的監控包括cpu、記憶體、網路頻寬情況等，對業務微服務應用的指標（平均響應時間、慢端點情況等）的監控顯得無從下手。

在這樣的背景下，新的監控體系下的細分領域-鏈路追蹤問世了。

首先，我們來看看在系統監控的體系下具體的細分領域的專注點：

Logging- 用於記錄離散的事件。例如，應用程式的除錯資訊或錯誤資訊。它是我們診斷問題的依據。

Metrics- 用於記錄可聚合的資料。例如，佇列的當前深度可被定義為一個度量值，在元素入隊或出隊時被更新；HTTP 請求個數可被定義為一個計數器，新請求到來時進行累加。

Tracing- 用於記錄請求範圍內的資訊。例如，一次遠端方法呼叫的執行過程和耗時。它是我們排查系統性能問題的利器。

2.鏈路追蹤基本原理

在每個請求呼叫的入口和出口進行程式碼埋點記錄呼叫之間的關係、每個呼叫處理時間點資訊。

通過呼叫關係梳理出一次請求的完整鏈路還原、請求具體到達哪臺機器。

通過每次處理記錄的時間點，計算出相關的呼叫執行時間、響應時間、網路延時。

對呼叫請求量進行統計。

顯示鏈路拓撲結構、應用依賴關係。

https://pics4.baidu.com/feed/0eb30f2442a7d93309a829d6ad86e11472f00163.jpeg?token=e01895248e138b46b96519a509c73ff3

Trace：指一個請求經過後端所有服務的路徑，每一條鏈路都用一個全域性唯一的traceid來標識。

Span：鏈路中的呼叫由span來表示，每個span由spanid和parentid來標識，可以記錄呼叫的父子關係。

Timestamp：呼叫點的時間戳，記錄每個執行點的時間資訊。

如果想知道一個介面在哪個環節出現了問題，就必須清楚該介面呼叫了哪些服務，以及呼叫的順序，如果把這些服務串起來，看起來就像鏈條一樣，我們稱其為呼叫鏈。

到現在，已經知道呼叫順序和層級關係了，但是接口出現問題後，還是不能找到出問題的環節，如果某個服務有問題，那個被呼叫執行的服務一定耗時很長，要想計算出耗時，上述的三個標識還不夠，還需要加上時間戳，時間戳可以更精細一點，精確到微秒級。

只記錄發起呼叫時的時間戳還算不出耗時，要記錄下服務返回時的時間戳，有始有終才能算出時間差，既然返回的也記了，就把上述的三個標識都記一下吧，不然區分不出是誰的時間戳。

3.鏈路追蹤的Demo實現

前面我們介紹了鏈路追蹤的技術原理，以及相關的實現鏈路追蹤的開源元件，那麼我們實際在專案中要怎麼做，是否需要根據技術原理去實現底層的相關開發。通過這個章節，我簡單的通過一個demo去演示如何在微服務架構系統中完成鏈路追蹤的功能。

我們簡單描述一下demo的相關情況，首先demo是要基於微服務架構的，那麼我們提供2個微服務應用（訂單服務、產品服務），並且提供一個服務註冊發現中心，訂單服務會呼叫產品服務，並且是通過註冊中心去發現服務呼叫服務，這樣從前端請求呼叫訂單服務，再由訂單服務呼叫產品服務，完成了一個簡單的鏈路呼叫，需求鏈路很短，只有兩次呼叫，足夠演示demo的鏈路追蹤功能。

通過demo將教打家一步一步的去實現鏈路的相關功能，包括還原請求的完整呼叫鏈路情況，能夠檢視請求過程中訂單服務，產品服務執行的耗時情況，總的請求響應時間，並且可以根據請求鏈路的traceid檢視到對應的請求處理的日誌資訊。

首先建立springboot專案，通過依賴eureka元件，提供服務的註冊中心，實現服務的註冊與發現。

新增依賴

Properties配置資訊

再新增兩個springboot專案，一個訂單服務，一個產品服務

由於服務需要註冊到註冊中心，因此兩個專案需要新增依賴

並新增配置資訊

並且訂單服務需要呼叫產品服務的方法，在demo中我們使用feign的方式進行服務呼叫，因此在訂單服務專案中需要新增依賴

由於是demo，因此我們服務中的方法就簡單通過返回字串的方式實現。

至此我們啟動兩個微服務應用，可以在註冊中心中看到兩個服務都已經註冊上來，再通過瀏覽器請求訂單服務的介面，可以看到後端通過呼叫產品服務的介面，並返回資訊。

到目前為止，我們只是構建好了微服務應用，對應鏈路追蹤功能還沒有實現，其實在微服務架構下實現鏈路追蹤很簡單，畢竟有很多開源的元件封裝了底層實現原理，我們只需要引用這些元件就可以實現鏈路追蹤功能，在demo中我通過skywalking來進行鏈路追蹤，由於skywalking本身的特性無需程式碼侵入，只需要以探針的方式啟動微服務應用即可。並自動採集服務呼叫的相關資訊，寫入資料庫，然後通過自帶的dashboard檢視相關資訊。

首先我們先下載skywalking

其中，agent目錄是應用啟動時用的代理，bin目錄是skywalking後端服務和dashboard，在bin目錄執行startup.bat檔案，啟動服務。

在訂單服務和產品服務的專案啟動配置中，加上jvm引數，以探針方式啟動2個服務應用

啟動後，我們可以通過skywalking自帶的dashboard檢視資訊。

可以看到請求的鏈路情況，以及每個路徑上的處理時間，總的響應時間等資訊。

還有一個目標就是，如何將鏈路跟我們實際的日誌記錄進行繫結，這樣方便在某個鏈路出現問題時，我們可以針對這個具體的鏈路去檢視具體問題原因。

在demo中，我們通過logback記錄日誌，新增依賴

目前很多的鏈路追蹤元件都已經實現了與日誌元件的整合，只需要引入依賴，即可完成將鏈路traceid對應寫入到日誌中。

在程式碼中加入寫日誌的程式碼

增加配置資訊，以及logback-spring.xml檔案

可以看到控制檯日誌中，記錄的日誌前面都加上了TID資訊，也就是traceid。

4.普元微服務平臺的鏈路追蹤應用

上面的demo只是簡單的驗證瞭如何快速通過第三方元件實現微服務架構下的鏈路追蹤功能，對於在實際專案應用中我們需要進行優化和整合，這章節中介紹我們普元微服務平臺在鏈路追蹤中的相關應用場景：

1. 系統拓撲結構

2. 應用執行時

3. 業務鏈路

4. 跟蹤日誌

5. 服務統計

在鏈路追蹤下，系統可以根據請求呼叫關係繪製去系統拓撲結構，通過系統拓撲結構你可以清楚知道當前系統下有多少微服務應用，微服務應用間是否有呼叫關係，每個服務的具體概況。

由於微服務架構下，一個系統的微服務相對比較多，如果沒有這個系統拓撲結構，後期對系統的情況，尤其是系統間的呼叫依賴關係跟蹤也很困難。

應用執行時，通過收集統計相關呼叫請求資訊，計算相關效能指標，幫助系統管理員運維人員快速瞭解系統的相關情況，主要是微服務應用例項的能力指標，比如平均響應時間、平均響應成功率等指標。

由於普元微服務平臺的架構特性，每一個服務對應多個應用例項組，因此在檢視時可以選擇具體例項組下的例項節點。幫助我們瞭解應用節點的效能，以及慢節點情況。

業務鏈路，快速檢視某個應用、甚至應用下某個具體的操作的完整鏈路呼叫情況，鏈路中每個過程處理的時間資訊，每個鏈路上顯示traceid資訊，並提供快速複製功能，方便使用者在跟蹤日誌中快速檢視此次鏈路對應的日誌資訊。

根據請求中的時間資訊，在請求響應慢的時候追溯具體慢的操作。

鏈路呼叫的時序情況，通過不同顏色區分應用系統，可以檢視具體呼叫的詳細資訊（元件、url、請求方式、異常資訊等）。

鏈路日誌，前面我們已經完成了請求完整鏈路的還原，不過這些資訊還不能查出根本原因，對應異常發生的根本原因，我們有時還需要通過系統記錄的日誌檔案進行檢視，通過日誌檔案記錄的錯誤資訊進行排查根本原因。

我們在檢視日誌檔案時，也不是直接顯示日誌檔案所有內容，而是通過以與鏈路對應的方式，顯示每個鏈路環節中記錄的日誌資訊，檢視異常詳細原因。

另外，在跟蹤日誌模組，我們針對性的過濾篩選錯誤日誌、事務日誌等資訊。

平臺通過鏈路元件採集的請求處理資訊，對這些資訊進行統計，從多個維度提供統計資料供運維人員進行參考分析

統計某個應用、某個請求路徑的總請求數、正常響應數、錯誤響應數、最長處理時間、最少處理時間、平均處理時間以及各類異常處理的統計

在平臺正常執行一段時間後，運維人員普遍關注平臺的執行情況，尤其是哪些請求比較頻繁、哪些請求比較耗時、哪些請求錯誤率比較高、哪些錯誤數多，而這些資訊對於運維人員比較敏感，因此平臺中提供直接顯示統計資料的方式供參考。

本文主要介紹微服務架構下的鏈路追蹤的應用場景，主要解決哪些問題，對於一個剛接觸鏈路追蹤的新人來說，如何快速上手將鏈路追蹤引入到專案中，也將我們普元微服務平臺下的鏈路追蹤的應用簡單介紹了一下，便於大家在專案中進行實際的應用參考。文中沒有對目前市場上開源的鏈路追蹤的元件做過多介紹以及之間的比較，也沒有對skywalking這個元件的使用配置做詳細介紹，相關的這些知識我們有專欄介紹，大家可以檢視歷史文章進行了解。

關於作者：軒雨，普元產品經理，主要負責公司微服務、容器雲相關產品的研發和實施，在分散式架構、微服務、DevOps、容器雲、軟體工程等領域方向具有較深的積累，擁有十多年的產品研發與多個大型平臺專案管理經驗。

關於EAWorld：微服務，DevOps，資料治理，移動架構原創技術分享。