本文為大家介紹云原生網(wǎng)絡(luò)代理 MOSN如何實現(xiàn)透明高效的攔截，這是Service Mesh 設(shè)計中的一大難點。

十多年的大武口網(wǎng)站建設(shè)經(jīng)驗，針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時及時工作處理。成都營銷網(wǎng)站建設(shè)的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動調(diào)整大武口建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計，從而大程度地提升瀏覽體驗。創(chuàng)新互聯(lián)從事“大武口網(wǎng)站設(shè)計”,“大武口網(wǎng)站推廣”以來，每個客戶項目都認(rèn)真落實執(zhí)行。

MOSN 是一款使用 Go 語言開發(fā)的網(wǎng)絡(luò)代理軟件，作為云原生的網(wǎng)絡(luò)數(shù)據(jù)平面，旨在為服務(wù)提供多協(xié)議、模塊化、智能化、安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的簡稱，可以與任何支持 xDS API 的 Service Mesh 集成，亦可以作為獨立的四、七層負(fù)載均衡、API Gateway、云原生 Ingress 等使用。
MOSN：https://github.com/mosn/mosn

在由 Istio 定義的 Service Mesh 體系中，服務(wù)治理相關(guān)邏輯由獨立的 Sidecar 進程處理，如服務(wù)發(fā)現(xiàn)、故障注入、限流熔斷等等。這些處理邏輯是 Service Mesh 著重要解決的問題。通常在談?wù)摰?Service Mesh 時，會優(yōu)先關(guān)注在這些點上，但是在落地過程中，有一個問題同等重要但往往容易被忽視。這個問題概括起來，就是流量是如何被導(dǎo)入到Sidecar的監(jiān)聽端口的。

在數(shù)據(jù)平面的 Sidecar 中攔截進出應(yīng)用容器的流量，這一直以來就是 Istio Service Mesh 中一切功能的基礎(chǔ)，如何實現(xiàn)透明高效的攔截也是 Service Mesh 設(shè)計中的一大難點，本文為大家介紹云原生網(wǎng)絡(luò)代理 MOSN 是如何做到這一點的。

流量接管

如果服務(wù)注冊/發(fā)布過程能夠允許適當(dāng)?shù)男薷?，這個問題會得到極大的簡化，比如服務(wù)發(fā)布方 Sidecar 將地址修改為 127.0.0.1:15001，訂閱方Sidecar監(jiān)聽本機 15001 端口，當(dāng)訂閱方訪問 127.0.0.1:15001 時，流量就自然到達(dá)了本端Sidecar。在這種情況下，無需在網(wǎng)絡(luò)層面使用重定向技術(shù)就可以達(dá)到目的。

服務(wù)發(fā)布訂閱修改邏輯框圖

流量轉(zhuǎn)發(fā)流程圖

如上圖中，在發(fā)布服務(wù)時，Sidecar 將服務(wù)端原本的地址轉(zhuǎn)換為 Sidecar 自身的端口；服務(wù)訂閱時，訂閱方獲取到的端口則是本地Sidecar 監(jiān)聽的端口。這一方案的優(yōu)勢很明顯，邏輯都收斂在了 Sidecar 中，除了需要對 Sidecar 服務(wù)注冊/發(fā)布流程進行改造外，不需要其他組件的參與，但是缺點也很明顯，如果業(yè)務(wù)模型不存在注冊中心，或者是服務(wù)發(fā)布/訂閱 SDK 不能進行改造，這個方案就行不通了，而在 Mesh 落地場景中，這個條件恰恰較難滿足。

目前大多數(shù)業(yè)務(wù)的邏輯架構(gòu)都不符合 Istio 定義的云原生體系，為了享受到 Service Mesh 在服務(wù)治理方面的優(yōu)勢，需要選擇合適的流量劫持方案。一般而言，流量劫持工作在 L4 層，在進行劫持技術(shù)選型時需要考慮三個方面的問題：

第一是環(huán)境適配，包括容器、虛擬機、物理機、內(nèi)核、系統(tǒng)發(fā)行版等方面的考慮，確保劫持方案在運行環(huán)境中能夠正常工作； 第二是控制靈活簡單，包括如何維護劫持規(guī)則，劫持規(guī)則如何下發(fā)等； 第三是性能，確保在業(yè)務(wù)運行期間，劫持本身不會帶來過大的開銷；

下面將從這三個層面分析 MOSN 在落地過程中的一些思考。

環(huán)境適配

在環(huán)境適配性上，最容易想到的是 iptables，作為一項古典網(wǎng)絡(luò)技術(shù)，iptables 使用簡單，功能靈活，幾乎所有現(xiàn)代生產(chǎn)級內(nèi)核版本與 OS 發(fā)行版都默認(rèn)具備使用條件，Istio 社區(qū)也使用 iptables 做流量透明劫持。

iptables 流量劫持原理圖

盡管環(huán)境適應(yīng)性強，但是基于 iptables 實現(xiàn)透明劫持存在以下問題：

DNAT 模式下，需要借助于 conntrack 模塊實現(xiàn)連接跟蹤，在連接數(shù)較多的情況下，會造成較大的消耗，同時可能會造成 track 表滿的情況。為了避免這個問題，可以使用 TProxy 取代 DNAT，但受限于內(nèi)核版本，TProxy 應(yīng)用于 outbound 存在一定缺陷。 iptables 屬于常用模塊，全局生效，不能顯式的禁止相關(guān)聯(lián)的修改，可管控性比較差。 iptables 重定向流量本質(zhì)上是通過 loopback 交換數(shù)據(jù)，outbond 流量將兩次穿越協(xié)議棧，在大并發(fā)場景下會損失轉(zhuǎn)發(fā)性能。

針對 oubound 流量，還可以使用hook connect 來實現(xiàn)，如圖所示：

hook connect邏輯框圖

無論采用哪種透明劫持方案，均需要解決獲取真實目的 IP/端口的問題，使用 iptables 方案通過 getsockopt 方式獲取，TProxy 可以直接讀取目的地址，通過修改調(diào)用接口，hook connect 方案讀取方式類似于 TProxy。

由于 MOSN 落地的場景十分復(fù)雜，有容器與 VM 甚至物理機環(huán)境，有基于 K8s 的云原生應(yīng)用，有基于注冊中心的微服務(wù)，也存在單體應(yīng)用，有些場景對性能要求非常高，有些則是夠用即可，針對不同的場景，我們選擇不同的劫持方案進行適配。如果應(yīng)用程序通過注冊中心發(fā)布/訂閱服務(wù)時，可以結(jié)合注冊中心劫持流量；在需要用到透明劫持的場景，如果性能壓力不大，使用 iptables DNAT 即可，大并發(fā)壓力下使用 TProxy 與 sockmap 改善性能。

配置管理

通?；谏昝魇襟w系構(gòu)建的服務(wù)在部署時能夠得到全局信息，而非申明式體系往往需要在運行期間進行動態(tài)的配置修改，由于缺乏全局信息，在運行期間很難獲取到準(zhǔn)確的服務(wù)間調(diào)用信息。在生成透明劫持規(guī)則時，我們需要明確哪些流量要被重定向到 Sidecar，否則一旦出錯，而 Sidecar 又無法處理這部分流量時，將會使得 Sidecar 變成流量黑洞，比如，某一個容器內(nèi)的 TCP 流量全部被重定向至 Sidecar，而該容器中存在一個使用私有協(xié)議承載應(yīng)用數(shù)據(jù)的監(jiān)控 Agent，而 Sidecar 不能識別該協(xié)議導(dǎo)致無法爭取轉(zhuǎn)發(fā)，只能選擇丟棄。

通常情況下，為了確保 Sidecar 能夠正確的轉(zhuǎn)發(fā)流量，需要滿足兩個條件，首先是要能夠正確識別協(xié)議，其次是需要配置轉(zhuǎn)發(fā)規(guī)則，明確下一跳。對于不滿足這兩個條件的流量，不應(yīng)將其重定向至 Sidecar。對于現(xiàn)有的非云原生應(yīng)用，同時滿足這兩個條件的代價非常高，比如，某個虛擬機上運行了一個業(yè)務(wù)，同時還運行了收集 Metrics 的 Agent、日志采集工具、健康檢查工具等等。而基于 L4 規(guī)則很難精確的將業(yè)務(wù)流量重定向至 Sidecar，如果多個業(yè)務(wù)混部，可能導(dǎo)致無法在 L4 層進行業(yè)務(wù)流量的區(qū)分?？偨Y(jié)起來，為了精確的把流量引至 Sidecar，需要獲得全局的調(diào)用關(guān)系，這一目標(biāo)原本應(yīng)該由 Service Mesh 來完成，而在流量劫持的場景下，卻成為了 Service Mesh 的前提。

為了使用 Service Mesh 而引入大量的部署運維開銷是得不償失的。在落地的過程中，MOSN 引入了多項手段來降低流量劫持的配置難度。我們將需要精確配置重定向規(guī)則的工作模式定義為精確匹配，與之相對應(yīng)的是模糊匹配，即不要求精確區(qū)分出需要劫持的流量。降低配置難度的關(guān)鍵在于取消對于精確規(guī)則的依賴，在配置模糊規(guī)則的前提下，既做到對于關(guān)心的業(yè)務(wù)流量的治理，同時也不影響非業(yè)務(wù)流量的正常流程。

我們采用 L4 規(guī)則與 L7 規(guī)則融合的方式下發(fā)模糊的匹配規(guī)則，此規(guī)則下除了包含關(guān)心的業(yè)務(wù)流量外，還可能包含預(yù)期之外的非業(yè)務(wù)流量。對于業(yè)務(wù)流量，Sidecar 根據(jù)相應(yīng)的服務(wù)治理規(guī)則處理，而對于非業(yè)務(wù)流量，則保持其默認(rèn)行為不變。在模糊匹配模式下，僅需要為關(guān)心的流量配置服務(wù)治理與轉(zhuǎn)發(fā)規(guī)則，而無需關(guān)心 miss match 導(dǎo)致流量黑洞。在模糊匹配之外，MOSN仍然保留了精確匹配能力，可以通過配置項禁用模糊匹配，能夠兼容之前的工作模式。

MOSN 流量劫持模糊匹配邏輯框圖

為了支持更加靈活的配置手段，在配置模糊匹配規(guī)則時，支持默認(rèn)白名單與默認(rèn)黑名單兩種模式。默認(rèn)黑名單模式適合業(yè)務(wù)場景簡單，業(yè)務(wù)流量特征明顯的場景，由于劫持邏輯的輸入流量少，性能損耗小。默認(rèn)白名單模式適合業(yè)務(wù)特征明顯不明顯的場景，由于劫持邏輯的輸入流量多，可能存在一定的性能損耗，在這種模式下，可以顯示加入黑名單排除相應(yīng)的流量，比如通常業(yè)務(wù)不會使用除了 80 之外的小于 1024 的端口。

MOSN 通過模糊規(guī)則匹配的手段極大降低了流量劫持的管理成本，在部署 Service Mesh 時，僅需要“大體上正確”即可，無需擔(dān)心沒有完全枚舉流量規(guī)則而產(chǎn)生流量黑洞，而借助于 Service Mesh，可以得到全局的服務(wù)調(diào)用信息，進而能夠?qū)ΜF(xiàn)有服務(wù)進行精細(xì)化的治理。

數(shù)據(jù)面性能

iptables 存在一個固有問題是在匹配規(guī)則數(shù)量增多時，匹配消耗會隨之增加，在規(guī)則數(shù)量較多的情況下，會對新建連接性能造成較大的影響，為了避免這種情況，可使用 ipset 降低匹配消耗。此外，在內(nèi)核版本滿足要求（4.16 以上）的前提下，通過 sockmap 可以縮短報文穿越路徑，進而改善 outbound 方向的轉(zhuǎn)發(fā)性能。

在討論流量劫持的性能損耗時，需要結(jié)合具體的場景來看，比如某些場景中只有 iptables dnat能夠滿足環(huán)境適配的要求，在這種情況下，需要考慮的是iptables dnat的數(shù)據(jù)面性能是否能夠滿足業(yè)務(wù)的需求。實際落地過程中，需要結(jié)合實際情況與運維難度選擇劫持手段。

本文題目：幫你解讀云原生網(wǎng)絡(luò)代理MOSN透明劫持技術(shù)
本文路徑：http://www.rwnh.cn/article38/cpecpp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計、動態(tài)網(wǎng)站、手機網(wǎng)站建設(shè)、建站公司、企業(yè)網(wǎng)站制作、網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)