分布式 虛擬時間和虛擬同步

跟蹤提供了對系統的可見性，使開發人員和操作人員可以在運行時觀察應用程序。 當系統不斷增長并與更多微服務進行交互時，跟蹤變得非常有價值。 在這樣的環境中，這些痕跡非常棒，可以定位導致性能下降的故障和瓶頸。

在這篇文章中，我們將幫助您詳細了解跟蹤。 我們將通過示例跟蹤事件和問題管理過程中如何使用跟蹤。

什么是痕跡？

在檢查如何捕獲跟蹤及其組成之前，讓我們看一下跟蹤的正式定義：

這樣，您可以將跟蹤視為一棵樹，其根節點是用戶進行的交互，并且這些節點代表所有參與處理請求和準備響應的微服務。

分布式跟蹤的外觀如何？

上面的示例說明了一個由七個跨度組成的跡線。 要了解跨度和軌跡，請看一下定義：

• 跟蹤公開了通過分布式系統的執行路徑。 跡線由一個或多個跨度組成。
• 跟蹤中的跨度表示執行路徑中的一項微服務。 例如，信用評分檢查可能是貸款申請處理過程中的跨度。 跨度可以創建多個子跨度，而一個子跨度恰好具有一個父跨度。

因此，將跨度組合到跟蹤中可以揭示整個分布式系統中請求處理的流程。 可視化跟蹤使用父子表示法來顯示跨度之間的依賴性以及每個跨度執行所需的時間。

如何捕獲跟蹤？

所有跟蹤解決方案都要求參與處理入站請求的微服務由代理庫進行檢測。 每個這樣的代理庫都捕獲跟蹤的一部分，并將其發送到組成跟蹤的中央服務器。 要了解它是如何工作的，讓我們看一個示例電子商店，該例子說明了跟蹤捕獲：

---

每當請求到達系統邊界時，代理都會通過監視第一個節點為它分配一個唯一的ID。 該標識符稱為跟蹤ID。

E-shop前端節點處理入站請求，并決定調用下游的SubmitOrder微服務。 這樣做時，它通常使用自定義HTTP標頭將跟蹤ID傳遞到下游。

SubmitOrder微服務會在HTTP標頭中發現跟蹤ID。 這使SubmitOrder可以將其跨度與E-shop父級鏈接。 處理請求時， submitOrder微服務發現它需要調用checkInventory微服務。 再次通過向下游傳遞跟蹤ID來實現。 checkInventory微服務現在是該樹中的終端節點，沒有子依賴項。 因此，它僅處理請求并將響應發送回父級。 完成此操作后， checkInventory微服務中的整個范圍就準備好了。

在SubmitOrder中間節點和E-shop父節點中也是如此。 跨度組成，配備有開始和結束時間戳記，并使用跟蹤ID進行鏈接。

代理庫捕獲跨度后，它們會將跨度發送到集中式服務器。 在此服務器中，節點被組成跟蹤并存儲以進行查詢。

該過程的結果是組成了完整的痕跡。 在上面的示例中，組合的跟蹤看起來類似于以下內容：

代理商如何工作？

可以使用兩種不同的方法來構建從單個微服務捕獲跨度的代理：

諸如Zipkin ， OpenTracing和Jaeger之類的Tracer庫使應用程序開發人員能夠檢測代碼并將跨度發送到集中式服務器。 它們提供了最常用的語言和框架的庫，并在缺少支持的情況下使用戶能夠構建自己的庫

舉例說明如何使用Zipkin來檢測PHP微服務的示例可能會給您一個想法：

SubmitOrder微服務會在HTTP標頭中發現跟蹤ID。這使SubmitOrder可以將其跨度與E-shop父級鏈接。

處理請求時， submitOrder微服務發現它需要調用checkInventory微服務。 再次通過向下游傳遞跟蹤ID來實現。 checkInventory微服務現在是該樹中的終端節點，沒有子依賴項。 因此，它僅處理請求并將響應發送回父級。 完成此操作后， checkInventory微服務中的整個范圍就準備好了。

這種方法有其缺點-從將跟蹤庫引入微服務的示例可以看出，需要更改代碼才能捕獲所需的信息。 要在大型組織中實現這一目標，而由不同團隊開發和維護數十甚至數百個微服務，可能是一個艱巨的挑戰。

基于代理的解決方案（例如NewRelic或DataDog或我們自己的Plumbr）使用應用程序運行時中的低級掛鉤來對微服務進行檢測。 代理已附加在應用程序配置中，不需要更改代碼。

例如，使用Plumbr Java代理進行跟蹤等效于僅更改JVM啟動參數，類似于：

SubmitOrder微服務會在HTTP標頭中發現跟蹤ID。這使SubmitOrder可以將其跨度與E-shop父級鏈接。

處理請求時， submitOrder微服務發現它需要調用checkInventory微服務。 再次通過向下游傳遞跟蹤ID來實現。 checkInventory微服務現在是該樹中的終端節點，沒有子依賴項。 因此，它僅處理請求并將響應發送回父級。 完成此操作后， checkInventory微服務中的整個范圍就準備好了。

因此，推出基于代理的解決方案更加簡單，尤其是在管理更大的部署時。 但是，大多數基于代理的解決方案都是商業的， 而不是開放源代碼的跟蹤程序庫，因此涉及一些成本。

標記軌跡和跨度

跡線和跨度往往會被標記以支持多維查詢以分析跡線。 常用標簽的一些示例：

• 用戶身份
• serverId
• clusterId
• API端點
• HTTP響應碼

使用標簽，可以輕松回答不同的問題：

• 此微服務中的哪個API端點已損壞？
• 該前端中哪些API端點最慢？
• 哪些用戶遇到了錯誤？
• 罪魁禍首是哪個微服務？

良好的跟蹤提供程序將不同的維度無縫地集成到產品UI和警報設置中，因此您可以避免使用數百萬條單獨的跟蹤，而是立即而及時地獲得寶貴的見解。

帶走

跟蹤是一種非常強大的診斷工具，尤其是在應用于分布式環境時。 由于可以在整個執行路徑中觀察每個單獨的請求，因此問題得以解決。 借助標簽，可以公開分析查詢，從而使影響估算變得微不足道。

翻譯自: https://www.javacodegeeks.com/2020/02/distributed-tracing-for-dummies.html

分布式 虛擬時間和虛擬同步

總結

以上是生活随笔為你收集整理的分布式 虚拟时间和虚拟同步_分布式虚拟跟踪的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。