服務網格中 sidecar 流量治理與多協議嗅探

語言: CN / TW / HK

時間 2022-07-15 14:20:00

:point_up_2: 點選“ 博文視點Broadview ”，獲取更多書訊

服務網格架構已經是一個老生常談的問題，服務的進出口流量經過 iptables 等技術手段被劫持到 sidecar，經由 sidecar 觀察、治理之後再被轉發到實際目標服務或者例項。

那麼，在 sidecar 內部流量是如何處理並正確應用治理規則和轉發的呢？

更具體一點，某個服務訪問其他服務時，流量被劫持到到 sidecar 之後：

如何確認流量原始目標地址並實現正確轉發？
如何確認哪些治理規則需要對當前流量生效？

接下來，本文將以 envoy sidecar 實現為例一點點說明 sidecar 是如何解決以上兩個問題的（服務入口流量劫持和處理相對簡單，所以本文主要關注出口流量處理）。

0 1

只是代理

說一千，道一萬，envoy sidecar 也只是最簡單不過的代理而已，它所有能做的事情都不會超過代理的範疇。

回顧代理的通用工作機制 ：接受下游連線和請求，按需對請求解析，然後經過一系列的模組或過濾器處理之後，將請求轉發給上游服務。

在 envoy sidecar 中，接受下游的連線和請求的模組被抽象為 listener，而上游服務則被抽象為 cluster，形成如下結構：

當然，envoy 支援多 listener 機制，即同時監聽複數個地址，並且可以通過 xDS 協議實現 listener 的動態更新。並且，envoy 允許 listener 並不實際繫結地址和埠，即不產生實際的地址監聽。這兩個特性對於 sidecar 來說很關鍵，不過並不複雜。

在對 sidecar 本身最簡單的結構有了基本的瞭解之後，接下里就可以正式開始回答之前的問題了。

0 2

你去哪兒？

第一個問題，流量劫持之後，如何確認原始的目標地址並轉發？

一般來說，sidecar 會建立兩個特殊的 listener 並開啟埠監聽。一個作為服務入口流量劫持的入口（virtual inbound），一個作為服務出口流量劫持的入口（virtual outbound）。服務進出口流量被劫持後被分別傳送 sidecar 這兩個特殊 listener 處理。

以出口流量的 virtual outbound 為例。資料流量經過 iptables 劫持和重定向之後和 virtual outbound 建立連線。而 virtual outbound 則可以使用系統呼叫通過 SO_ORIGINAL_DST 獲得該連線原始目標地址（IP 地址和埠）。該原始目標地址就可以用於輔助後續流量的轉發。

當然，對於部分的應用層協議來說，其協議訊息本身就可能會攜帶目標服務的相關資訊。sidecar 也可以在對流量內容解析之後，根據其中的資訊識別目標服務並轉發。

舉個例子，HTTP 協議。當客戶端使用域名訪問目標服務時，該域名就會直接被新增到請求的 host 當中。

根據配置，sidecar 也可以使用請求訊息中的 host 將 HTTP 請求轉發給目標服務。根據應用層訊息中服務標識選擇目標服務轉發也是一個關鍵特性，在後續內容中還會提到。

0 3

路在何方？

在服務網格中，sidecar 的職責當然不只是簡單的流量轉發了，更重要的是流量觀察及流量治理。所以，獲取到了流量原始目標 IP 和埠之後，直接轉發出去顯然不是網格想要的，必須進行更進一步的治理。

這就是第二個問題了，如何使治理規則生效，又有哪些治理規則需要對當前流量生效呢？

答案其實就在第1小節中。作為代理的 sidecar 本身就具備流量觀察、流量治理、負載均衡等基礎能力，流量自 listener 進入，經過過濾器處理，最終通過 cluster 轉發給目標服務。

同時，envoy sidecar 又具備靈活的多 listener 機制，且允許 listener 不產生實際監聽。

那麼，sidecar 完全可以為每一個服務建立一個不會實際監聽地址的內部 listener （簡稱為 fake listener），以服務 VIP（注意，是服務 VIP，一個服務可能有很多個例項，每個例項都有例項 IP，但是一個服務一般只有一個 VIP）為索引。而所有與該服務相關的治理規則，都以各種過濾器配置下發到該 fake listener 當中。不同 fake listener 可以使用不同過濾器配置。

如上圖所示，上層服務抽象中的服務以及治理規則最終被對映為 sidecar 中具體的 listener 和過濾器。

一般來說，在 K8S 的服務模型當中，客戶端服務會使用目標服務域名訪問目標服務。目標服務域名經 DNS 解析為目標服務 VIP。訪問流量經 iptables 劫持，自 virtual outbound 進入 sidecar，在使用 SO_ORIGINAL_DST 獲得流量原始目標地址（也即目標服務 VIP 地址和埠）之後，搜尋該原始目標地址對應的 fake listener，然後把連線整個交給該 fake listener 處理，該 fake listener 會負責應用對應服務的治理規則（以過濾器實現）並將流量最終轉發給目標服務（以 cluster 實現）。

0 4

公共的路

前文說過，sidecar 為每個服務都建立一個對應的 listener，以服務 VIP 為索引。可是如果存在大量的服務，那麼就會建立大量的 listener，帶來更大的資源開銷。

另外，並不是所有服務模型中都有 VIP。比如在 Dubbo 的微服務模型中，就沒有 VIP 的位置，所以就必須為每個例項建立一個 listener 保證流量被正確的治理和轉發。且相同服務的所有例項對應的多個 listener 會應用相同的治理規則。

如此，顯然會帶來配置和資源的膨脹，給控制面和資料面都帶來壓力。

為了緩解該問題，envoy sidecar 提供了通配的 fake listener。通配 fake listener 使用 0.0.0.0:<port> （IPv4）為索引。

當以流量原始目標地址無法搜尋到對應 fake listener 之後，就會根據流量原始目標埠搜尋對應的通配 fake listener 來處理該流量。舉例來說，如果一個請求（連線 or 流量）原始目標地址為 1.2.3.4:80，但是 sidecar 中不存在 1.2.3.4:80 fake listener 時，該請求就會被交由 0.0.0.0:80 通配 fake listener 處理。多個不同的 Dubbo 服務例項，也可以只建立一個對應的 fake listener。

但是，顯然，通配 fake listener 會引入一些新問題。

首先，多個不同服務的流量最終會被同一個 fake listener 處理，為了保證服務治理規則能夠正確、準確的生效，該通配 listener 內部必須要根據請求訊息內服務標識（如 HTTP 中 host 請求頭，如 Dubbo 請求中 interface）識別流量的目標服務並應用治理規則。

其次，通配 fake listener 可能會帶來協議衝突問題。一般來說，同一地址（相同 IP，相同埠）只會使用一種協議（一般如此，當然也存在特殊情況，暫不討論）。

可是，現在多個不同目標目標流量都可能聚集到同一 fake listener，必然存需要在同一 fake listener 處理多種不同協議流量的場景。比如說，目標地址 1.2.3.4:8080 提供 Dubbo 服務，目標地址 2.3.4.5:8080 提供 HTTP 服務，指向兩者的流量最終都被 0.0.0.0:8080 處理。為了解決該問題，envoy sidecar 提供了協議嗅探機制，在同一 listener 中處理不同協議流量。

0 5

選擇車道

如前文所述，請求流量和連線最終會交由 listener 處理，並以各種過濾器來實現各種治理規則，並且由於通配 fake listener，會大量出現需要在同一 listener 中處理不同協議流量的能力。

不同協議，可能有完全不同的訊息格式和模型，顯然需要不同的過濾器來進行處理。在 envoy sidecar 中就有相關的機制來支援該場景。

在 sidecar 的 listener 中，可以同時配置多組不同的過濾器，每組過濾器稱為一個 filter chain。並且還提供了名為 listener filter 的特殊過濾器，可以對流量和連線進行預處理，並根據預處理的結果選擇不同的 filter chain。

再次以 Dubbo 和 HTTP 協議為例。

當一個新的連線在 fake listener 中建立時，會首先經過 listener filter 預處理。它們會預讀該連線上少量位元組，如果其中包含 Dubbo Magic Number 和訊息型別等位元組，則為 Dubbo 協議；如果包含 HTTP 協議行，則為 HTTP 協議。最終 sidecar 會根據協議的不同選擇不同的 filter chain 來處理，實現協議嗅探的效果。