[[404533]]

【51CTO.com快譯】微服務(wù)架構(gòu)的分布式跟蹤是一個新興概念，它在基于互聯(lián)網(wǎng)的商業(yè)組織中將會得到更廣泛的應(yīng)用。

微服務(wù)架構(gòu)引入了一種全新的方式來擴(kuò)展具有多個獨(dú)立服務(wù)的應(yīng)用程序。與單體架構(gòu)相比，它確實(shí)有助于提高彈性、可擴(kuò)展性、生產(chǎn)力、效率。

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

本文旨在介紹分布式跟蹤方法及其對微服務(wù)架構(gòu)的影響。

分布式追蹤的解釋

可觀察性是在細(xì)粒度級別上監(jiān)控基礎(chǔ)設(shè)施的行為。這有助于最大限度地提高基礎(chǔ)設(shè)施內(nèi)部的可見性，并支持事件管理團(tuán)隊(duì)維護(hù)微服務(wù)架構(gòu)的可靠性。

可觀察性是通過以各種形式(工具)記錄系統(tǒng)數(shù)據(jù)來實(shí)現(xiàn)的，例如指標(biāo)、警報(事件)、日志和跟蹤。這些功能有助于深入了解基礎(chǔ)設(shè)施的內(nèi)部健康狀況。在這里對跟蹤的重要性以及它如何演變?yōu)榉植际礁欉M(jìn)行分析。

1.跟蹤

跟蹤是對應(yīng)用程序流程和數(shù)據(jù)進(jìn)展的持續(xù)監(jiān)督，通常代表一個用戶通過應(yīng)用程序堆棧的行程軌跡。這些使整個系統(tǒng)的行為和狀態(tài)更加明顯和易于理解。分布式請求跟蹤是一種具有可觀察性的進(jìn)化方法，有助于保持云計(jì)算應(yīng)用程序的良好運(yùn)行狀況。

分布式跟蹤是跟蹤事務(wù)請求并記錄貫穿微服務(wù)架構(gòu)路徑的所有相關(guān)數(shù)據(jù)的過程。它用于跨行業(yè)以結(jié)構(gòu)化的格式檢查和可視化跟蹤。這種數(shù)據(jù)跟蹤方法有助于SRE/DevOps團(tuán)隊(duì)快速了解和檢查導(dǎo)致基礎(chǔ)設(shè)施中出現(xiàn)異常的技術(shù)故障。

這可以通過使用諸如OpenTelemetry(跨云原生應(yīng)用程序可觀察性的標(biāo)準(zhǔn)化框架)之類的工具來完成，該工具被認(rèn)為是一種供應(yīng)商中立的跟蹤方法。

2.為什么需要分布式跟蹤?

在2018年進(jìn)行的一項(xiàng)研究表明，63%的傳統(tǒng)組織正在將其設(shè)施更改為微服務(wù)架構(gòu)。由于從單體架構(gòu)到微服務(wù)架構(gòu)的重大轉(zhuǎn)變，在高度分布式系統(tǒng)中進(jìn)行數(shù)據(jù)跟蹤的需求變得更加明顯。這種分布式跟蹤極大地減少了具有細(xì)粒度可觀察性功能的監(jiān)控系統(tǒng)中的常見挑戰(zhàn)。

以一個互動社交游戲平臺為例，該平臺在世界各地?fù)碛袛?shù)以百萬的用戶。當(dāng)這些用戶在平臺中輸入某些偏好數(shù)據(jù)時，該平臺必須快速處理數(shù)據(jù)并提供適當(dāng)?shù)慕Y(jié)果。在這里，分布式跟蹤在捕獲每個用戶的請求、各種微服務(wù)處理這些請求并在很短的時間內(nèi)交付預(yù)期結(jié)果方面起著至關(guān)重要的作用。

以下了解分布式跟蹤如何幫助這個社交游戲平臺基礎(chǔ)設(shè)施處理的一些問題。

其中一些功能包括：

• 提供跨基礎(chǔ)設(shè)施的端到端可見性。
• 在上述這個游戲平臺中，分布式追蹤將跟蹤用戶位置和用戶數(shù)據(jù)并將其存儲在系統(tǒng)中。它遵循用戶請求并記錄與之相關(guān)的所有必要數(shù)據(jù)。通過這種功能，該平臺將在其架構(gòu)內(nèi)實(shí)現(xiàn)端到端的可見性。
• 提供有關(guān)服務(wù)依賴性的信息。
• 微服務(wù)環(huán)境中的每個服務(wù)在完成用戶請求時將相互依賴。在這里，當(dāng)游戲玩家更新他們的狀態(tài)時，它將通過訪問中央服務(wù)器和架構(gòu)內(nèi)的各種其他基于位置的節(jié)點(diǎn)來與其他游戲玩家通信以完成這個任務(wù)。因此，每個服務(wù)請求都會提供其他相關(guān)服務(wù)的信息。
• 在系統(tǒng)遇到故障時確保具備彈性。
• 考慮游戲平臺中的應(yīng)用程序中的購買功能，該功能由于用戶憑據(jù)無效而失敗。通過分布式跟蹤，開發(fā)人員可以輕松識別支付門戶的API流程跟蹤以糾正問題，而無需搜索各種日志。通過使用必要的網(wǎng)絡(luò)數(shù)據(jù)記錄每筆交易，可以節(jié)省大量時間。

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

在研究如何在用戶請求期間執(zhí)行分布式跟蹤之前，先了解一些基本術(shù)語。

• 請求(Request)：這個術(shù)語表明各種云計(jì)算應(yīng)用程序、微服務(wù)和其他功能如何相互通信。
• 跨度(Span)：跨度將告知一個服務(wù)在一定時間間隔和相應(yīng)的元數(shù)據(jù)方面所做的工作。這些是跟蹤的基本構(gòu)建塊。
• 跟蹤(Trace)：這意味著由單個或多個跨度組成的端到端用戶請求。
• 標(biāo)簽(Tag)：這些是與每個跨度(沿路徑記錄)相關(guān)聯(lián)的信息(元數(shù)據(jù))，提供跨度期間執(zhí)行的操作的詳細(xì)概述。

而一個跟蹤包含一系列帶有關(guān)聯(lián)標(biāo)簽的跨度。

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

(1)當(dāng)最終用戶開始與系統(tǒng)和應(yīng)用程序交互時，分布式跟蹤過程就會開始。例如，如果新用戶注冊交互式移動游戲平臺，需要輸入電子郵件ID和設(shè)置密碼。

(2)現(xiàn)在，每個用戶請求都被轉(zhuǎn)換成一個HTTP請求，并被分配一個唯一的跟蹤ID(全局 ID)。在這里，用戶數(shù)據(jù)將被提取并分配一個唯一的ID。

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

(4)每一個用戶操作都被標(biāo)記了三個ID：

• 請求跟蹤ID，
• 根跨度ID，
• 子跨度ID。

(5)最終用戶 (跨度) 的每個唯一請求都使用有關(guān)處理請求的所有信息(標(biāo)簽)進(jìn)行編碼。這些數(shù)據(jù)包括：

• 處理用戶請求的微服務(wù)的名稱和地址。
• 執(zhí)行請求時與進(jìn)程相關(guān)的事件和日志的場景。
• 查詢和篩選請求標(biāo)簽，通過其會話ID、數(shù)據(jù)庫主機(jī)、HTTP方法和各種其他關(guān)鍵標(biāo)識符指示請求。
• 有關(guān)系統(tǒng)在處理請求時遇到故障時的錯誤消息和堆棧跟蹤的信息。
• 現(xiàn)在，所有這些處理過的數(shù)據(jù)都將附加一個全局ID，其中包含有關(guān)跟蹤從源到目的地的路徑的相關(guān)信息。
• 最后，用戶請求行程中跟蹤的所有信息存儲在相應(yīng)的數(shù)據(jù)存儲設(shè)施中。在這個游戲平臺中，數(shù)據(jù)將存儲在后端服務(wù)器的數(shù)據(jù)庫層中，以供將來參考。

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

此外，還有一些用于跨架構(gòu)執(zhí)行分布式跟蹤的工具，這些工具可以劃分為以下三個子類別：

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

(2)數(shù)據(jù)跟蹤工具：在使用源系統(tǒng)驗(yàn)證關(guān)鍵數(shù)據(jù)元素 (CDE) 或遙測數(shù)據(jù)期間執(zhí)行跟蹤，并使用統(tǒng)計(jì)過程控制 (SPC) 方法對其進(jìn)行監(jiān)控。數(shù)據(jù)跟蹤工具的一些示例是Datadog、Jaeger、New Relic、Dynatrace和Lightstep。

(3)程序(進(jìn)程)跟蹤工具：在應(yīng)用程序執(zhí)行過程中建立跟蹤操作。包含執(zhí)行指令的索引和執(zhí)行期間引用的數(shù)據(jù)的跟蹤。這些被開發(fā)人員大量用于調(diào)試目的。這些工具的一些示例包括Strace、Ltrace、Opensnoop和Valgrind Lackey。

如何開始對基礎(chǔ)設(shè)施進(jìn)行分布式跟蹤?

以下列出了一些有助于在微服務(wù)架構(gòu)中開始分布式跟蹤的鏈接。

• 要在架構(gòu)中實(shí)施分布式跟蹤，按照相關(guān)步驟，OpenTelemetry (OpenTracing + OpenCensus)。
• 擁有跨Docker本地運(yùn)行Jaeger的組織可以按照J(rèn)aeger文檔中提到的步驟進(jìn)行操作。
• 如果采用Java或Docker配置基礎(chǔ)設(shè)施，按照相關(guān)步驟在基礎(chǔ)設(shè)施中應(yīng)用OpenZipkin。
• 要為微服務(wù)架構(gòu)應(yīng)用分布式跟蹤模式，可以參閱分布式跟蹤模式。
• 跨基于微服務(wù)的Web應(yīng)用程序?qū)嵤┓植际礁?，例如IBM Garage方法。
• 要沿網(wǎng)絡(luò)路徑跟蹤系統(tǒng)請求并了解系統(tǒng)未按預(yù)期工作的原因，需要了解分布式跟蹤指南。
• 要了解微服務(wù)架構(gòu)及其使用分布式跟蹤的行為，需要了解使用分布式跟蹤的微服務(wù)。

因此，通過執(zhí)行或?qū)嵺`上述策略，可以跨任何微服務(wù)架構(gòu)實(shí)現(xiàn)分布式跟蹤系統(tǒng)。

隨著分布式跟蹤越來越多地采用，也面臨一些隨之而來的挑戰(zhàn)。為了保持可靠性，應(yīng)該在實(shí)現(xiàn)這些功能的同時保持最佳實(shí)踐。

在微服務(wù)架構(gòu)中采用分布式跟蹤的最佳實(shí)踐：

• 實(shí)施端到端檢測并記錄所有入站和出站服務(wù)調(diào)用的跟蹤。
• 關(guān)注SRE信號，例如延遲、流量、錯誤和飽和(利用率)以及RED(響應(yīng)、錯誤和持續(xù)時間)指標(biāo)，以便在記錄所有系統(tǒng)跟蹤的同時對它們設(shè)置警報，并關(guān)注研究系統(tǒng)行為的持續(xù)時間指標(biāo)。
• 始終遵循OpenTelemetry(OpenTracing+OpenCensus)標(biāo)準(zhǔn)化并確保采用的工具符合全球標(biāo)準(zhǔn)。
• 記錄所有定制的業(yè)務(wù)指標(biāo)和跟蹤范圍以備將來參考。

結(jié)論

分布式跟蹤是一種監(jiān)控微服務(wù)架構(gòu)的有效技術(shù)。它提供了有關(guān)網(wǎng)絡(luò)路徑的更精確的數(shù)據(jù)和信息。通過采用標(biāo)準(zhǔn)化的分布式跟蹤工具以及SRE信號指標(biāo)的端到端檢測，可以克服實(shí)施過程中的挑戰(zhàn)。

原文標(biāo)題：Using Distributed Tracing in Microservices Architecture，作者：Biju Chacko，Merlyn Shelley

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