[[404533]]

【51CTO.com快譯】微服務架構的分布式跟蹤是一個新興概念，它在基于互聯網的商業組織中將會得到更廣泛的應用。

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

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

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

分布式追蹤的解釋

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

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

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信號指標的端到端檢測，可以克服實施過程中的挑戰。

原文標題：Using Distributed Tracing in Microservices Architecture，作者：Biju Chacko，Merlyn Shelley

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】