在由 Istio 定義的 Service Mesh 體系中，服務治理相關邏輯由獨立的 Sidecar 進程處理，如服務發現、故障注入、限流熔斷等等。這些處理邏輯是 Service Mesh 著重要解決的問題。通常在談論到 Service Mesh 時，會優先關注在這些點上，但是在落地過程中，有一個問題同等重要但往往容易被忽視。這個問題概括起來，就是流量是如何被導入到Sidecar的監聽端口的。
在數據平面的 Sidecar 中攔截進出應用容器的流量，這一直以來就是 Istio Service Mesh 中一切功能的基礎，如何實現透明高效的攔截也是 Service Mesh 設計中的一大難點，本文為大家介紹云原生網絡代理 MOSN 是如何做到這一點的。
流量接管
如果服務注冊/發布過程能夠允許適當的修改，這個問題會得到極大的簡化，比如服務發布方 Sidecar 將地址修改為 127.0.0.1:15001，訂閱方Sidecar監聽本機 15001 端口，當訂閱方訪問 127.0.0.1:15001 時，流量就自然到達了本端Sidecar。在這種情況下，無需在網絡層面使用重定向技術就可以達到目的。
服務發布訂閱修改邏輯框圖
流量轉發流程圖
如上圖中，在發布服務時，Sidecar 將服務端原本的地址轉換為 Sidecar 自身的端口；服務訂閱時，訂閱方獲取到的端口則是本地Sidecar 監聽的端口。這一方案的優勢很明顯，邏輯都收斂在了 Sidecar 中，除了需要對 Sidecar 服務注冊/發布流程進行改造外，不需要其他組件的參與，但是缺點也很明顯，如果業務模型不存在注冊中心，或者是服務發布/訂閱 SDK 不能進行改造，這個方案就行不通了，而在 Mesh 落地場景中，這個條件恰恰較難滿足。
目前大多數業務的邏輯架構都不符合 Istio 定義的云原生體系，為了享受到 Service Mesh 在服務治理方面的優勢，需要選擇合適的流量劫持方案。一般而言，流量劫持工作在 L4 層，在進行劫持技術選型時需要考慮三個方面的問題：
第一是環境適配，包括容器、虛擬機、物理機、內核、系統發行版等方面的考慮，確保劫持方案在運行環境中能夠正常工作；
第二是控制靈活簡單，包括如何維護劫持規則，劫持規則如何下發等；
第三是性能，確保在業務運行期間，劫持本身不會帶來過大的開銷；
下面將從這三個層面分析 MOSN 在落地過程中的一些思考。
環境適配
在環境適配性上，最容易想到的是 iptables，作為一項古典網絡技術，iptables 使用簡單，功能靈活，幾乎所有現代生產級內核版本與 OS 發行版都默認具備使用條件，Istio 社區也使用 iptables 做流量透明劫持。
iptables 流量劫持原理圖
盡管環境適應性強，但是基于 iptables 實現透明劫持存在以下問題：
DNAT 模式下，需要借助于 conntrack 模塊實現連接跟蹤，在連接數較多的情況下，會造成較大的消耗，同時可能會造成 track 表滿的情況。為了避免這個問題，可以使用 TProxy 取代 DNAT，但受限于內核版本，TProxy 應用于 outbound 存在一定缺陷。
iptables 屬于常用模塊，全局生效，不能顯式的禁止相關聯的修改，可管控性比較差。
iptables 重定向流量本質上是通過 loopback 交換數據，outbond 流量將兩次穿越協議棧，在大并發場景下會損失轉發性能。
針對 oubound 流量，還可以使用hook connect 來實現，如圖所示：
hook connect邏輯框圖
無論采用哪種透明劫持方案，均需要解決獲取真實目的 IP/端口的問題，使用 iptables 方案通過 getsockopt 方式獲取，TProxy 可以直接讀取目的地址，通過修改調用接口，hook connect 方案讀取方式類似于 TProxy。
由于 MOSN 落地的場景十分復雜，有容器與 VM 甚至物理機環境，有基于 K8s 的云原生應用，有基于注冊中心的微服務，也存在單體應用，有些場景對性能要求非常高，有些則是夠用即可，針對不同的場景，我們選擇不同的劫持方案進行適配。如果應用程序通過注冊中心發布/訂閱服務時，可以結合注冊中心劫持流量；在需要用到透明劫持的場景，如果性能壓力不大，使用 iptables DNAT 即可，大并發壓力下使用 TProxy 與 sockmap 改善性能。
配置管理
通?；谏昝魇襟w系構建的服務在部署時能夠得到全局信息，而非申明式體系往往需要在運行期間進行動態的配置修改，由于缺乏全局信息，在運行期間很難獲取到準確的服務間調用信息。在生成透明劫持規則時，我們需要明確哪些流量要被重定向到 Sidecar，否則一旦出錯，而 Sidecar 又無法處理這部分流量時，將會使得 Sidecar 變成流量黑洞，比如，某一個容器內的 TCP 流量全部被重定向至 Sidecar，而該容器中存在一個使用私有協議承載應用數據的監控 Agent，而 Sidecar 不能識別該協議導致無法爭取轉發，只能選擇丟棄。
通常情況下，為了確保 Sidecar 能夠正確的轉發流量，需要滿足兩個條件，首先是要能夠正確識別協議，其次是需要配置轉發規則，明確下一跳。對于不滿足這兩個條件的流量，不應將其重定向至 Sidecar。對于現有的非云原生應用，同時滿足這兩個條件的代價非常高，比如，某個虛擬機上運行了一個業務，同時還運行了收集 Metrics 的 Agent、日志采集工具、健康檢查工具等等。而基于 L4 規則很難精確的將業務流量重定向至 Sidecar，如果多個業務混部，可能導致無法在 L4 層進行業務流量的區分?？偨Y起來，為了精確的把流量引至 Sidecar，需要獲得全局的調用關系，這一目標原本應該由 Service Mesh 來完成，而在流量劫持的場景下，卻成為了 Service Mesh 的前提。
為了使用 Service Mesh 而引入大量的部署運維開銷是得不償失的。在落地的過程中，MOSN 引入了多項手段來降低流量劫持的配置難度。我們將需要精確配置重定向規則的工作模式定義為精確匹配，與之相對應的是模糊匹配，即不要求精確區分出需要劫持的流量。降低配置難度的關鍵在于取消對于精確規則的依賴，在配置模糊規則的前提下，既做到對于關心的業務流量的治理，同時也不影響非業務流量的正常流程。
我們采用 L4 規則與 L7 規則融合的方式下發模糊的匹配規則，此規則下除了包含關心的業務流量外，還可能包含預期之外的非業務流量。對于業務流量，Sidecar 根據相應的服務治理規則處理，而對于非業務流量，則保持其默認行為不變。在模糊匹配模式下，僅需要為關心的流量配置服務治理與轉發規則，而無需關心 miss match 導致流量黑洞。在模糊匹配之外，MOSN仍然保留了精確匹配能力，可以通過配置項禁用模糊匹配，能夠兼容之前的工作模式。
MOSN 流量劫持模糊匹配邏輯框圖
為了支持更加靈活的配置手段，在配置模糊匹配規則時，支持默認白名單與默認黑名單兩種模式。默認黑名單模式適合業務場景簡單，業務流量特征明顯的場景，由于劫持邏輯的輸入流量少，性能損耗小。默認白名單模式適合業務特征明顯不明顯的場景，由于劫持邏輯的輸入流量多，可能存在一定的性能損耗，在這種模式下，可以顯示加入黑名單排除相應的流量，比如通常業務不會使用除了 80 之外的小于 1024 的端口。
MOSN 通過模糊規則匹配的手段極大降低了流量劫持的管理成本，在部署 Service Mesh 時，僅需要“大體上正確”即可，無需擔心沒有完全枚舉流量規則而產生流量黑洞，而借助于 Service Mesh，可以得到全局的服務調用信息，進而能夠對現有服務進行精細化的治理。
數據面性能
iptables 存在一個固有問題是在匹配規則數量增多時，匹配消耗會隨之增加，在規則數量較多的情況下，會對新建連接性能造成較大的影響，為了避免這種情況，可使用 ipset 降低匹配消耗。此外，在內核版本滿足要求（4.16 以上）的前提下，通過 sockmap 可以縮短報文穿越路徑，進而改善 outbound 方向的轉發性能。
在討論流量劫持的性能損耗時，需要結合具體的場景來看，比如某些場景中只有 iptables dnat能夠滿足環境適配的要求，在這種情況下，需要考慮的是iptables dnat的數據面性能是否能夠滿足業務的需求。實際落地過程中，需要結合實際情況與運維難度選擇劫持手段。
更多關于云服務器，域名注冊，虛擬主機的問題，請訪問三五互聯官網：www.shinetop.cn