分布式鏈路跟蹤技術如何應用至災備系統中？

<i id='tn1kl'></i>

隨著分布式系統的廣泛應用，業務系統的復雜度快速提升，在業務邏輯的執行情況的分析和定位，變得愈發困難。

在災備系統中，災備方案的設計通常需要對系統有一個清晰的鏈路調用圖譜的理解，這不僅是主動發現系統故障部位的前置條件，也是系統發生非自然災害故障后，對于故障的排解必不可少的手段。

而目前的常見的混沌工程，例如阿里的ChaosBlade、云原生團隊的ChaosMesh，可以提供通用且常見的故障模擬方案，例如基礎資源、云原生環境等實驗場景，工具非常強大，不過模擬的故障粒度較大，例如物理機器宕機，斷網等，而災備方案對于這類故障的處理通常需要進行災備系統喚醒、流量切換。

這種故障一旦發生如果沒有災備方案帶來的損失是巨大的，不過這類故障發生的頻率還是比較小，災備切換影響范圍也比較大，而對于某些應用級、甚至更小型的故障，例如中間件掛掉、或者應用bug等這種類型的故障，其發生的概率更高，影響有時也非常嚴重，但通常不在災備考慮的范圍內，主要是因為這類小型故障難以定位。尤其在分布式系統中，業務場景下的某次請求通常需要經過若干個服務、中間件、甚至多臺機器的處理，問題的定位費時費力。

如果在災備方案確定之前，盡可能把所有故障都考慮在內，那么這套災備方案將是完整的，線上業務將是穩定且持續的。

目前分布式場景下，小型故障追蹤的手段包括兩種：

1. 收集日志至ES，根據關鍵字篩選(ELK方案)
2. 基于單次請求調用的會話追蹤

故障演練

故障演練是災備系統中的一個步驟，在災備方案確立部署完成之后，通常需要進行故障的模擬注入，來驗證災備系統的可行性，從而不斷完善。而如何提高故障演練的覆蓋面，也就是盡可能在故障演練階段就把所有以后可能發生的故障都注入一邊，從而增強災備系統的健壯性，這個問題通常是比較難的。

traceId: sn0o1c
---1--->A---2--->B---3--->C
        |
        4
        |
        v
        D---5--->E

分布式鏈路跟蹤原理

在分布式系統環境下，為了發現某一次的服務調用經過了哪些服務、哪些機器是比較難的，而且場景復現困難。

鏈路跟蹤的作用是：

1. 自動采集數據
2. 分析數據，產生完整調用鏈，方便問題復現
3. 可視化展示，可以幫助直觀的發現問題

在鏈路跟蹤系統中，一次請求就是一個trace，它有一個traceId來標識它的唯一性，內部的每一次調用是一個span，每個span都攜帶全局的traceId，這樣可以吧traceId與每個調用關聯起來。

以下圖為例，某次請求，經過了5次調用。

在這其中鏈路跟蹤系統共收集了以下數據：

1. 此次的請求的traceId為sn0o1c；
2. 此次請求經歷了5此調用，因此包含了5個span，其id分別是1,2,3,4,5，同時每個span存儲了其父子關系；
3. 每次調用的時間。

因此匯總下來：

----------------------1-------------------------
      ------------------2-------------------
            -----------3-----------
            --------------4-------------
                  ------- 5--------
----------------------Time---------------------->

另外鏈路跟蹤工具比如SkyWalking有一套標準流程OpenTracing，比如span如何采集、如何跨進程傳遞上下文信息等等，感興趣的同學可以具體區了解學習，在此不再贅述。

分布式鏈路追蹤可以提高災備系統的災難覆蓋度

整理完后續補充...