idou老師教你學Istio 22 : 如何用istio實現呼叫鏈跟蹤
大家都知道istio可以幫助我們實現灰度釋出、流量監控、流量治理等一些功能。
每一個功能都幫助我們在不同場景中實現不同的業務。那麼其中比如流量監控這種複雜的功能Istio是如何讓我們在不同的應用中實現呢？
因篇幅所限，我們今天重點介紹Istio裡面實現這些功能的關鍵技術--呼叫鏈跟蹤。
雖然 Istio 代理能夠自動傳送 Span 資訊，但還是需要一些輔助手段來把整個跟蹤過程統一起來。應用程式應該自行傳播跟蹤相關的 HTTP Header，這樣在代理髮送 Span 資訊的時候，才能正確的把同一個跟蹤過程統一起來。在Istio中的Sidecar裡面已經實現了埋點的邏輯，業務程式碼不用呼叫以上這些埋點方式來建立trace，維護span等這些複雜邏輯，但是為了能真正形成一個完整的鏈路，業務程式碼在某些場景下還是需要做適當修改。
1
服務呼叫關係
為了便於大家理解，我們以Istio最經典的Bookinfo為例來說明。Bookinfo的4個微服務的呼叫關係如下圖所示，在這裡我們不就具體闡述了。
然後我們要弄明白幾個問題：什麼是呼叫鏈跟蹤？為什麼要用呼叫鏈跟蹤？
呼叫鏈跟蹤顧名思義就是服務與服務之間相互呼叫的時候，來記錄下呼叫的關係。比如使用者發起請求訪問Ingress，這是入口。然後Ingress——>Productpage——>Reviews——>Ratings這是一個完整的呼叫鏈，而這個過程中的誰呼叫誰的關係就是呼叫鏈跟蹤。
當我們獲得了服務之間呼叫的關係，就可以對流量狀況進行一個微觀監控。比如當我們發現流量異常時，通過呼叫鏈跟蹤我就可以清晰的知道流量異常出現在哪一塊服務呼叫中，又或是提取呼叫中的響應時延等等。
2
如何實現
在上文中，我們說Istio要實現呼叫鏈跟蹤需要去修改使用者的程式碼，其實就是採用一種被稱為埋點的方法。
在Istio中對於經過sidecar流出的流量，如例子中ingress呼叫productpage，或者productpage呼叫details和reviews的請求。如果經過sidecar時header中沒有任何跟蹤相關的資訊，則會建立根span，並將該根span相關上下文資訊放在請求頭中傳遞給下一個呼叫的服務，當然呼叫前會被目標服務的sidecar攔截掉執行上面流入的邏輯；當存在trace資訊時，sidecar從header中提取span相關資訊，並基於這個span建立子span，並將新的span資訊加在請求頭中傳遞。
如下所示就是需要在請求頭中傳遞的欄位資訊，包括traceid、spanid等。被呼叫的服務接收trace相關的header並在請求時傳送出去，這樣在出流量的proxy向下一跳服務發起請求前才能判斷並生成子span並和原span進行關聯，進而形成一個完整的呼叫鏈。否則，如果在應用容器未處理Header中的trace，則Sidecar在處理outbound的請求時會建立根span，最終會形成若干個割裂的span，並不能被關聯到一個trace上。這就是為何需要部分的修改應用程式碼。
-
x-request-id
-
x-b3-traceid
-
x-b3-spanid
-
x-b3-parentspanid
-
x-b3-sampled
-
x-b3-flags
-
x-ot-span-context
3
業務場景
最後讓我們看一下實現了呼叫鏈跟蹤的一些具體場景，如下圖所示：
從上圖中可以看到在某種場景下的所有應用、例項名稱、狀態以及總呼叫耗時、traceID等資訊，這些資訊給我們提供了最直觀的呼叫資料，點選檢視呼叫關係，將會看到更加詳細的呼叫鏈資訊。如下圖：
從這張圖中，我們可以監測到不同服務間更加詳細的呼叫資料。
如該呼叫鏈包含三個應用，最大呼叫深度為2，不同應用直接呼叫的耗時以及應用狀態等，這些都是在實際場景中非常具有價值的資訊。設想在一個大規模高併發以及巨大訪問量的業務中，如果我們可以對業務的監測可以細化到這種程度，那麼我們的業務將會處於更加安全的保護中。
通過以上場景以及擴充套件資訊我們就可以清晰的看到服務之間呼叫的具體資訊，例如請求狀態、響應時延等等，而這些資訊都是通過呼叫鏈跟蹤獲取的。
相關服務請訪問 https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019