在現有的微服務體系架構下，隨着服務數量的增多，服務與服務之間的關聯關係錯綜複雜，一個請求下發後可能會經過 N 個服務處理後才返回響應，所以，當出現 bug 時，開發人員只能依靠日誌一個個排查，效率低的可怕，於是，分佈式鏈路追蹤成爲了你的最優解。

當然這只是其中一個因素，分佈式鏈路追蹤能夠解決服務鏈路的問題，它還可以做到:

• 1: 查詢每個應用的 ip

• 2: 各個接口響應了多長時間，網絡開銷是多少

• 3: 應用的執行時間，是否執行成功

• 4: 總共消耗了多長時間

• 5: 每個接口返回了什麼內容，請求的內容又是什麼？

• 6: 每個應用調了多少次數據庫？

trace_ID

===============

那麼怎麼樣才能判斷一個請求發起到結束究竟經過了哪些服務呢？

大家肯定想到了一個唯一 Id 來實現，就是說，我的請求在發起時，創建一個全局的唯一 Id，然後在後面的請求傳遞的時候都把這個 Id 帶上，這樣，就可以通過這個唯一 Id 來判斷究竟經過了哪些服務。

如下圖:

我們可以通過 trace_ID 清晰的發現一個從 A 開始的請求都經過了那些服務。

span_ID

現在我們知道了所有調用的服務，但是我們還會發現一個問題，我們發現 A 服務在調用 B 服務的時候，會 B 會調用兩個服務，一個是服務 C，一個是服務 B，那麼這個先後關係有要怎麼判斷呢？

沒錯，就是再引入一個 span_ID 來判斷服務的先後調用順序，如圖，就可以判定調用鏈路爲

服務 A-> 服務 B-> 服務 C-> 服務 D-> 服務 E-> 服務 F

parent_ID

當然，父子間的調用關係我們就可以用一個 parent_ID 去管理了

比如：我們看到服務 C 的 parent_ID 爲 2，那麼我們就知道 span_ID 爲 2 的服務調用了服務 C，也就是服務 B 調用了服務 C

以上都是基於我們的猜測，大概會有這些部分，來，讓我們看下分佈式鏈路追蹤的規範是什麼~

OpenTracing 是什麼

由於各種調用鏈監控產品層出不窮，各式各樣，爲了避免碎片化，促進互操作性，社區誕生了一個叫做 OpenTracing 的標準化組織，制定了一些鏈路跟蹤的 API 規範，並且提供了一些框架和庫，這些框架和庫實現了它制定的那些 API 規範。而且它是一個獨立開放的項目，現在已經是雲原生基金會（Cloud Native Computing Foundation, CNCF）的項目了。任何組織和個人都可以貢獻符合 API 規範的庫 / 框架。

OpenTracing 提供的框架和庫需要重點說明的是，並不做分析, 所以其並不是一個完備的鏈路系統.

OpenTracing 旨在標準化 Trace 數據結構和格式，其目的是：

• 不同語言開發的 Trace 客戶端的互操作性，只要遵循 OpenTracing 標準，就都可以對接 OpenTracing 兼容的監控後端。

• Tracing 監控後端的互操作性，只要遵循 OpenTracing 標準，企業可以根據需要替換具體的 Tracing 監控後端產品，比如從 Zipkin 替換成 Skywalking 等後端。

分佈式鏈路跟蹤系統的數據模型

=====================

在 OpenTracing 規範中，有三個關鍵的，相關關聯的類型：Tracer，Span 和 SpanContext。

Traces(一般翻譯爲鏈路)：一起請求從發出，然後經過多個模塊（這個模塊可能是函數或者系統，或者都有），最終得到請求回覆，整個請求按照調用時間和關係串起來就是一個 trace。

Span 則是組成 trace 的最基本單元，它一般代表分佈式系統中一個獨立的工作單元。一個 Span 包含如下幾部分：

• 操作名稱：一般用於展示、過濾、聚合

• 開始和結束時間戳：用於計算耗時 由 key-value 組成的 Tags：用於添加一些時間無關的信息（可選） 由 key-value 組成幷包含時間戳的 Logs：用於添加一些時間相關的信息（可選）

• SpanContext。一般包含兩部分數據：

• （1）span 的狀態數據，比如 traceID 和 spanID

• （2）Baggage Items。Baggage 是鏈路跟蹤提供的一個通用的跨進程 / 服務傳遞數據的方式，格式也是 key-value 形式的。

• Trace 就是由若干個 span 組成的有向無環圖，圖中的每個節點就是 Span，連接節點的邊稱之爲 References。每個 trace 有一個唯一標識符 traceID，每個 span 也有一個唯一標識符 spanID。一個鏈路中的所有 span 的 traceID 是相同的，但 spanID 各不相同。一個鏈路中 span 典型的調用關係圖如下：

對應的時間維度爲：

一個 trace 的 span 間有兩種可能的關係：

• ChildOf：即父子關係，一個操作可以是另一個操作的子操作，在一個 ChildOf 引用中，父操作在一定程度上依賴於子操作，可以說，等子操作都完成之後父操作纔會完成。

• FollowsFrom：其實也是父子關係，子 Span 是由父 Span 調用產生的，但父 Span 是否完成不依賴於子 Span, 在這種場景下，子操作僅僅由父操作觸發。符合這種關係的操作可以進一步分成很多子類型，。

最後需要介紹的一個概念就是 “active span”。一個線程裏面可以包含多個 span，但同一時刻只能有一個 span 處於工作狀態，這個 span 稱之爲 ActiveSpan。Span 可以有這麼幾個狀態：

• Started

• Not Finished

• Not "active"

• Active Span 的狀態由 ScopeManager 管理，但是否實現由開發者決定。另外 OpenTracing 定義了 Inject 和 Extract 接口來簡化 SpanContext 跨進程傳遞。

總結

=========

1、分佈式鏈路追蹤就是將一次完整的請求鏈路還原，能夠清晰的追蹤到每個服務的信息。

2、由於分佈式鏈路追蹤實現方式多樣，於是 opentracing 組織定製了一個規範，定義了一個標準，最重要的三個指標就是 Tracer，Span 和 SpanContext。

參考鏈接：

https://niyanchun.com/opentracing-introduction.html

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/DcoBntNKWBcclP0gZz6edQ