分散式跟蹤在微服務架構中的應用

微服務架構的分散式跟蹤是一個新興概念，它在基於網際網路的商業組織中將會得到更廣泛的應用。

微服務架構引入了一種全新的方式來擴展具有多個獨立服務的應用程式。與單體架構相比，它確實有助於提高彈性、可擴展性、生產力、效率。

然而，其自身也帶來一些複雜性，例如難以追蹤錯誤或監控整個基礎設施的流量。 因此，為了消除這些複雜性，很多組織採用了分散式跟蹤方法。這種方法有助於解決高階偵錯問題並提高網路中的可見性。它還通過縮小端到端延遲、特定服務或功能等當前所遇到的錯誤為開發人員提供支援。

本文旨在介紹分散式跟蹤方法及其對微服務架構的影響。

分散式追蹤的解釋

可觀察性是在細粒度級別上監控基礎設施的行為。這有助於最大限度地提高基礎設施內部的可見性，並支援事件管理團隊維護微服務架構的可靠性。

可觀察性是通過以各種形式(工具)記錄系統資料來實現的，例如指標、警報(事件)、日誌和跟蹤。這些功能有助於深入瞭解基礎設施的內部健康狀況。在這裡對跟蹤的重要性以及它如何演變為分散式跟蹤進行分析。

1.跟蹤

跟蹤是對應用程式流程和資料進展的持續監督，通常代表一個使用者通過應用程式堆棧的行程軌跡。這些使整個系統的行為和狀態更加明顯和易於理解。分散式請求跟蹤是一種具有可觀察性的進化方法，有助於保持雲端計算應用程式的良好運行狀況。

分散式跟蹤是跟蹤事務請求並記錄貫穿微服務架構路徑的所有相關資料的過程。它用於跨行業以結構化的格式檢查和視覺化跟蹤。這種資料跟蹤方法有助於SRE/DevOps團隊快速瞭解和檢查導致基礎設施中出現異常的技術故障。

這可以通過使用諸如OpenTelemetry(跨雲原生應用程式可觀察性的標準化框架)之類的工具來完成，該工具被認為是一種供應商中立的跟蹤方法。

2.為什麼需要分散式跟蹤?

在2018年進行的一項研究表明，63%的傳統組織正在將其設施更改為微服務架構。由於從單體架構到微服務架構的重大轉變，在高度分散式系統中進行資料跟蹤的需求變得更加明顯。這種分散式跟蹤極大地減少了具有細粒度可觀察性功能的監控系統中的常見挑戰。

以一個互動社交遊戲平臺為例，該平臺在世界各地擁有數以百萬的使用者。當這些使用者在平臺中輸入某些偏好資料時，該平臺必須快速處理資料並提供適當的結果。在這裡，分散式跟蹤在捕獲每個使用者的請求、各種微服務處理這些請求並在很短的時間內交付預期結果方面起著至關重要的作用。

以下了解分散式跟蹤如何幫助這個社交遊戲平臺基礎設施處理的一些問題。

其中一些功能包括：

• 提供跨基礎設施的端到端可見性。

• 在上述這個遊戲平臺中，分散式追蹤將跟蹤使用者位置和使用者資料並將其儲存在系統中。它遵循使用者請求並記錄與之相關的所有必要資料。通過這種功能，該平臺將在其架構內實現端到端的可見性。

• 提供有關服務依賴性的資訊。

• 微服務環境中的每個服務在完成使用者請求時將相互依賴。在這裡，當遊戲玩家更新他們的狀態時，它將通過訪問中央伺服器和架構內的各種其他基於位置的節點來與其他遊戲玩家通訊以完成這個任務。因此，每個服務請求都會提供其他相關服務的資訊。

• 在系統遇到故障時確保具備彈性。

• 考慮遊戲平臺中的應用程式中的購買功能，該功能由於使用者憑據無效而失敗。通過分散式跟蹤，開發人員可以輕鬆識別支付門戶的API流程跟蹤以糾正問題，而無需搜尋各種日誌。通過使用必要的網路資料記錄每筆交易，可以節省大量時間。

3.分散式跟蹤如何工作?

在研究如何在使用者請求期間執行分散式跟蹤之前，先了解一些基本術語。

• 請求(Request)：這個術語表明各種雲端計算應用程式、微服務和其他功能如何相互通訊。

• 跨度(Span)：跨度將告知一個服務在一定時間間隔和相應的元資料方面所做的工作。這些是跟蹤的基本構建塊。

• 跟蹤(Trace)：這意味著由單個或多個跨度組成的端到端使用者請求。

• 標籤(Tag)：這些是與每個跨度(沿路徑記錄)相關聯的資訊(元資料)，提供跨度期間執行的操作的詳細概述。

而一個跟蹤包含一系列帶有關聯標籤的跨度。

以下討論分散式跟蹤如何處理一個請求。

(1)當終端使用者開始與系統和應用程式互動時，分散式跟蹤過程就會開始。例如，如果新使用者註冊互動式移動遊戲平臺，需要輸入電子郵件ID和設定密碼。

(2)現在，每個使用者請求都被轉換成一個HTTP請求，並被分配一個唯一的跟蹤ID(全局 ID)。在這裡，使用者資料將被提取並分配一個唯一的ID。

(3)當請求通過主機系統時，每個系統操作都被視為一個跨度，子操作被視為一個子跨度。跟蹤的第一個跨度也稱之為根跨度。在這個示例中，電子郵件ID將是根跨度，密碼將是子跨度。

(4)每一個使用者操作都被標記了三個ID：

• 請求跟蹤ID，

• 根跨度ID，

• 子跨度ID。

(5)終端使用者 (跨度) 的每個唯一請求都使用有關處理請求的所有資訊(標籤)進行編碼。這些資料包括：

• 處理使用者請求的微服務的名稱和地址。

• 執行請求時與程序相關的事件和日誌的場景。

• 查詢和篩選請求標籤，通過其會話ID、資料庫主機、HTTP方法和各種其他關鍵標識符指示請求。

• 有關係統在處理請求時遇到故障時的錯誤訊息和堆棧跟蹤的資訊。

• 現在，所有這些處理過的資料都將附加一個全局ID，其中包含有關跟蹤從源到目的地的路徑的相關資訊。

• 最後，使用者請求行程中跟蹤的所有資訊儲存在相應的資料儲存設施中。在這個遊戲平臺中，資料將儲存在後端伺服器的資料庫層中，以供將來參考。

4.分散式跟蹤工具的類型

此外，還有一些用於跨架構執行分散式跟蹤的工具，這些工具可以劃分為以下三個子類別：

(1)程式碼跟蹤工具：在計算機程式(程式碼)執行過程中進行跟蹤。這些工具有助於跟蹤每一行程式碼、聲明的變數、使用的條件語句、迭代函數，並最終交付預期的程式碼輸出。這些對於程式碼分析和診斷目的有很大幫助。程式碼跟蹤工具的一些示例包括OpenTracing、OpenZipkin和Appdash。

(2)資料跟蹤工具：在使用源系統驗證關鍵資料元素 (CDE) 或遙測資料期間執行跟蹤，並使用統計過程控制 (SPC) 方法對其進行監控。資料跟蹤工具的一些示例是Datadog、Jaeger、New Relic、Dynatrace和Lightstep。

(3)程式(程序)跟蹤工具：在應用程式執行過程中建立跟蹤操作。包含執行指令的索引和執行期間引用的資料的跟蹤。這些被開發人員大量用於偵錯目的。這些工具的一些示例包括Strace、Ltrace、Opensnoop和Valgrind Lackey。

如何開始對基礎設施進行分散式跟蹤?

以下列出了一些有助於在微服務架構中開始分散式跟蹤的連結。

• 要在架構中實施分散式跟蹤，按照相關步驟，OpenTelemetry (OpenTracing + OpenCensus)。

• 擁有跨Docker本地運行Jaeger的組織可以按照Jaeger文件中提到的步驟進行操作。

• 如果採用Java或Docker配置基礎設施，按照相關步驟在基礎設施中應用OpenZipkin。

• 要為微服務架構應用分散式跟蹤模式，可以參閱分散式跟蹤模式。

• 跨基於微服務的Web應用程式實施分散式跟蹤，例如IBM Garage方法。

• 要沿網路路徑跟蹤系統請求並瞭解系統未按預期工作的原因，需要了解分散式跟蹤指南。

• 要了解微服務架構及其使用分散式跟蹤的行為，需要了解使用分散式跟蹤的微服務。

因此，通過執行或實踐上述策略，可以跨任何微服務架構實現分散式跟蹤系統。

隨著分散式跟蹤越來越多地採用，也面臨一些隨之而來的挑戰。為了保持可靠性，應該在實現這些功能的同時保持最佳實踐。

在微服務架構中採用分散式跟蹤的最佳實踐：

• 實施端到端檢測並記錄所有入站和出站服務呼叫的跟蹤。

• 關注SRE訊號，例如延遲、流量、錯誤和飽和(利用率)以及RED(響應、錯誤和持續時間)指標，以便在記錄所有系統跟蹤的同時對它們設定警報，並關注研究系統行為的持續時間指標。

• 始終遵循OpenTelemetry(OpenTracing+OpenCensus)標準化並確保採用的工具符合全球標準。

• 記錄所有定製的業務指標和跟蹤範圍以備將來參考。

結論

分散式跟蹤是一種監控微服務架構的有效技術。它提供了有關網路路徑的更精確的資料和資訊。通過採用標準化的分散式跟蹤工具以及SRE訊號指標的端到端檢測，可以克服實施過程中的挑戰。