大家都知道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

idou老師教你學Istio 22 : 如何用istio實現調用鏈跟蹤