服務網格DPU卸載解決方案

1.?背景介紹

1.1.?業(yè)務背景

服務網格（Service Mesh）是微服務架構中的一種重要技術，它主要處理服務之間的通信，為服務間的信息交換提供更安全、更快速且更可靠的基礎設施層。服務網格將服務治理從業(yè)務邏輯中剝離出來，拆解為獨立的進程，實現(xiàn)異構系統(tǒng)的統(tǒng)一治理和增強網絡安全。

一個典型的服務網格部署示意圖如下：

其中綠色方塊為應用服務，藍色方塊為代理。應用服務之間通過代理進行通信，整個服務通信形成圖中的藍色網絡連線，圖中所有藍色部分就形成了服務網格。

服務網格的主要特點包括：

• 無侵入性：服務網格的設計理念是將通信和管理邏輯與業(yè)務邏輯解耦，使得業(yè)務邏輯無需關注通信細節(jié)，從而實現(xiàn)了對業(yè)務代碼的無侵入性。
• 統(tǒng)一治理：通過服務網格，可以實現(xiàn)對微服務架構中所有服務的統(tǒng)一治理，包括服務發(fā)現(xiàn)、負載均衡、安全認證、監(jiān)控和跟蹤等功能。
• 可擴展性：服務網格支持多種微服務框架和服務治理能力，能夠輕松擴展以支持更多的服務和場景。

服務網格的架構通常包括控制平面和數(shù)據(jù)平面，其中控制平面用于配置、管理和監(jiān)控數(shù)據(jù)平面中的Sidecar代理，提供服務發(fā)現(xiàn)、負載均衡、安全認證等功能。

數(shù)據(jù)平面主要由邊車Sidecar組成，它以輕量級的網絡代理形式存在，與每個微服務實例部署在同一個主機或容器中，作為服務的附屬組件運行。邊車的主要職責是攔截和處理服務之間的通信流量，并與控制平面進行交互，實現(xiàn)服務發(fā)現(xiàn)、負載均衡、安全認證、監(jiān)控和跟蹤等功能。

邊車的工作流程通常包括以下幾個步驟：

• 攔截通信流量：邊車代理攔截服務之間的所有入站和出站請求和響應。
• 服務發(fā)現(xiàn)：邊車代理向服務注冊中心注冊服務實例，并根據(jù)需要動態(tài)地發(fā)現(xiàn)和管理服務實例。
• 負載均衡：邊車代理根據(jù)配置的負載均衡算法，將請求分發(fā)到多個服務實例中，以提高服務的可用性和性能。
• 安全認證：邊車代理可以實施安全認證策略，確保服務之間的通信是安全的。
• 監(jiān)控和跟蹤：邊車代理收集和傳輸服務間的通信流量數(shù)據(jù)，以實現(xiàn)監(jiān)控、日志記錄、錯誤追蹤和性能調優(yōu)等功能。

綜上所述，服務網格是微服務架構中的重要組成部分，它們共同為服務間的通信提供了安全、快速且可靠的基礎設施層，并實現(xiàn)了對業(yè)務代碼的無侵入性服務治理。

1.2.?問題與挑戰(zhàn)

在微服務架構中引入服務網格確實可以帶來諸多好處，如簡化服務治理、提高安全性和可觀察性等，但同時也伴隨著一系列問題和挑戰(zhàn)。以下是幾個主要方面：

• 邊車帶來的資源開銷：每個微服務應用都都需要運行一個邊車代理，實際部署是每個POD部署一個邊車容器。邊車容器需要額外的計算資源來處理服務間的通信，默認情況下每個邊車容器占用0.2個CPU核。假設一臺服務器運行了60個POD，那么邊車容器將額外占用12個CPU核。
• 業(yè)務轉發(fā)時延增加：應用程序的每個數(shù)據(jù)包都必須通過邊車容器，數(shù)據(jù)包在應用程序和內核之間往返多次，如下對比是單個pod進或出增加的時延。

如圖所示，右側的是引入服務網格的方案，Pod內多了邊車容器，相比左側未引入服務網格的方案，數(shù)據(jù)包增加了內核往返次數(shù)，增加了時延。

通過上述分析可以看出，在微服務架構中引入服務網格確實帶來了資源開銷和轉發(fā)時延的問題。

2.?方案介紹

2.1.?整體方案架構

服務網格DPU卸載解決方案將服務網格的sidecar邊車容器集中卸載到DPU卡上執(zhí)行，可以顯著降低服務器CPU的算力消耗。同時，DPU卡高性能轉發(fā)引擎實現(xiàn)了網絡轉發(fā)功能的加速，從而能夠有效降低業(yè)務時延。該方案支持和原生Istio的無縫對接，對用戶業(yè)務無侵入，可以實現(xiàn)業(yè)務的平滑遷移。

如圖所示，紅色系為本方案涉及本方案涉及部分，包括DPU卡及其提供給到主機側的SRIOV vf口、主機側CNI(istio-dpu-cni)。

業(yè)務容器的流量治理功能由DPU卡上的共享服務代理dpu-proxy提供，它由原生的邊車容器從POD中抽離出來卸載到DPU卡上。它的配置由istio-dpu-cni通過對接istio獲取并轉換為集中式配置并下發(fā)下來。流量通過DPU提供的vf口到達DPU側的dpu-proxy進行流量治理。

此架構的控制面仍為原生的istio，下發(fā)xDs配置給轉發(fā)面；服務網格CNI（istio-dpu-cni）做為DPU卡在k8s集群的接口，無縫對接istio/收集集群信息，相當于DPU管理面給DPU組件下發(fā)配置及規(guī)則，使DPU卡可以實現(xiàn)原生的透明流量劫持以及流量治理的功能；DPU卡上的dpu-proxy做為服務網格的轉發(fā)面，接收配置并根據(jù)配置對流量進行流量治理。

集群內的主機上插入DPU卡（紅色），在主機側集群內部署安裝服務網格CNI（istio-dpu-cni組件）后，istio-dpu-cni組件可無縫對接控制平面K8s及Istio獲取服務網格及網絡配置、使能DPU卡上的共享服務代理dpu-proxy及轉發(fā)引擎dataplane、下發(fā)相關的啟動配置，主機即具有服務治理功能。之后在部署業(yè)務POD時，業(yè)務添加高速網口vf后，提供用戶接口，使業(yè)務流量通過vf到達DPU側dpu-proxy進行流量治理與轉發(fā)。

2.2.?方案描述

2.2.1.?主機側組件服務網格CNI實現(xiàn)管理平面

服務網格CNI（istio-dpu-cni組件）在主機側k8s集群部署，無縫對接控制平面K8s及Istio獲取配置等信息，轉換為共享式代理配置下發(fā)到DPU側的共享代理；基于DPU板卡的sriov功能，可給業(yè)務POD添加低時延高速網口vf及分配置IP地址；同時使能DPU側轉發(fā)引擎dataplane，給dataplane下發(fā)引流轉發(fā)配置。

如圖所示，服務網格CNI包括istio-dpu-controller、istio-dpu-adapter和istio-dpu-cni三個組件：

① istio-dpu-controller 使用daemonset方式部署在集群master上

主要是用于生成dpu級別的集中式服務網格配置，收集集群信息如pod變化、nodename等，轉換為istio的inbound和internal 配置，并下發(fā)給對應節(jié)點的istio-dpu-adapter。

② istio-dpu-adapter 使用daemonset部署在每個主機節(jié)點上

主要是用于無縫對接原生控制平面istio，可自動獲取配置，轉換集群內信息把原生配置聚合為共享式服務網格配置下發(fā)給代理dpu-proxy。

③ istio-dpu-cni 使用daemonset部署在每個主機節(jié)點上

可配置網絡模式是underlay或者overlay，針對性下發(fā)不同的網絡規(guī)則；收集集群內信息（node, ns, service, pod等），提供用戶接口可對dpu側的轉發(fā)引擎dataplane下發(fā)轉發(fā)及引流規(guī)則，使dataplane能進行透明劫持低時延業(yè)務流量到dpu-proxy做流量治理。

除自研的CNI外，引入的開源組件為multus、sriov、spiderpool（不涉及開源組件的改動），通過二進制或pod的形式部署在需要的節(jié)點上。

2.2.2.?DPU側組件轉發(fā)引擎及代理實現(xiàn)轉發(fā)平面

如圖所示，DPU側組件包括轉發(fā)引擎dataplane和共享服務代理dpu-proxy兩個組件。在DPU卡的soc上，部署兩個容器組件實現(xiàn)服務網格轉發(fā)面功能，流量透明劫持及流量治理。

① 共享服務代理dpu-proxy采用容器方式部署在DPU卡的SOC上

擴展封裝原生邊車代理istio-proxy為DPU共享服務代理dpu-proxy。它解析istio-dpu-adapter下發(fā)的動態(tài)共享式服務網格配置，對進出本機的低時延業(yè)務流量進行治理與轉發(fā)。支持原生的四層TCP流量及七層HTTP流量治理；支持generic-proxy框架對其他七層流量進行流量治理。

② 轉發(fā)引擎dataplane采用容器方式部署在DPU卡的SOC上

dataplane接入?yún)f(xié)議棧(內核/用戶態(tài)），并可通過vcl共享內存方式與共享服務代理dpu-proxy交互；接收istio-dpu-cni下發(fā)的轉發(fā)及引流規(guī)則，根據(jù)規(guī)則把流量劫持到dpu-proxy；治理過的流量按轉發(fā)規(guī)則進行網絡封裝及轉發(fā)；dataplane加載vf-representer，通過NP（網絡轉發(fā)引擎）從vf-representer口收發(fā)對應pod內vf口的流量。

2.2.3.?DPU共享服務代理流量轉發(fā)模型

同主機內的業(yè)務互訪如圖（紅色），client端業(yè)務流量經高速口vf到達DPU共享服務代理進行服務治理后，再經轉發(fā)引擎dataplane轉發(fā)到本主機的server端Pod。

跨主機業(yè)務互訪如圖（藍色），client端業(yè)務流量經高速口vf到達DPU共享服務代理進行服務治理。治理后流量到達轉發(fā)引擎dataplane，根據(jù)轉發(fā)規(guī)則轉到目標主機的DPU上共享服務代理做inbound入口流量治理。治理后流量再經轉發(fā)引擎dataplane轉到目標主機的server端Pod。

3.?方案優(yōu)勢

3.1.?方案優(yōu)勢

本方案創(chuàng)新性的將服務網格邊車代理集中卸載到DPU上，可以帶來一系列顯著的優(yōu)勢，包括以下幾個方面：

①顯著降低服務器開銷：

• 資源消耗減少：傳統(tǒng)的邊車模式需要在每個服務容器旁邊部署一個邊車代理，這會導致大量的資源消耗（如CPU、內存）。通過將代理集中部署在DPU上，可以消除這些額外的資源消耗，使主機側的資源更加專注于業(yè)務邏輯處理。
• 優(yōu)化資源利用率：DPU作為專門的硬件加速單元，能夠更高效地處理網絡流量和加密解密等任務，從而釋放主機CPU資源，提高整體系統(tǒng)的資源利用率。

②極致的低時延：

• 用戶態(tài)協(xié)議棧Bypass內核：通過將網絡處理移至DPU的用戶態(tài)協(xié)議棧，繞過傳統(tǒng)的內核態(tài)處理，可以顯著減少數(shù)據(jù)包在內核與用戶空間之間切換的開銷，從而大幅降低網絡延遲。
• 服務網格快路徑：自研的服務網格快路徑技術可以進一步優(yōu)化網絡路徑，減少不必要的處理步驟，確保數(shù)據(jù)包能夠以最短的路徑和最快的速度在網絡中傳輸。

③即插即用：

• 無侵入式服務治理：集中式代理模式允許在不修改現(xiàn)有應用代碼的情況下實現(xiàn)服務治理功能，如流量管理、安全控制等。這使得新服務的部署和現(xiàn)有服務的升級變得更加簡單快捷。
• 靈活部署：DPU作為獨立的硬件組件，可以輕松地集成到現(xiàn)有的服務器架構中，實現(xiàn)即插即用。這種靈活性使得企業(yè)可以根據(jù)實際需求快速調整網絡架構和服務部署策略。

④增強的安全性和隔離性：

• 服務隔離：通過DPU上的集中式代理，可以減少不同服務和邊車容器之間的干擾，防止?jié)撛诘陌踩L險。

綜上所述，將邊車代理集中卸載到DPU上是一種高效、靈活且安全的網絡架構優(yōu)化方案，能夠顯著降低開銷、提升系統(tǒng)的性能并增強安全性和隔離性。

3.2.?未來與展望

服務網格DPU卸載解決方案，作為云原生時代的一項創(chuàng)新技術，其核心價值在于顯著優(yōu)化了邊車代理模式所帶來的資源消耗問題，并大幅降低了業(yè)務請求在微服務間的轉發(fā)時延。

隨著云原生技術和微服務架構在各行各業(yè)的深入滲透，特別是在云計算、金融科技、物聯(lián)網、邊緣計算等領域，對于高效、可靠、可擴展的系統(tǒng)架構需求日益迫切。服務網格DPU卸載解決方案正是順應這一趨勢，憑借其卓越的性能提升和資源優(yōu)化能力，展現(xiàn)出了極為廣闊的應用前景和市場空間。

更為重要的是，該方案和技術正處于快速發(fā)展和不斷完善的階段。隨著DPU技術的不斷創(chuàng)新和服務網格框架的持續(xù)演進，未來將有更多高級功能被集成到DPU中，如更精細的流量管理、增強的安全策略執(zhí)行、智能的數(shù)據(jù)處理加速等。服務網格DPU卸載方案將吸引更多行業(yè)巨頭、初創(chuàng)企業(yè)以及技術開發(fā)者加入DPU生態(tài)，共同探索和實踐DPU技術的潛力，推動其標準化、生態(tài)化的發(fā)展進程。

總之，服務網格DPU卸載解決方案作為云原生和微服務架構下的技術探索，展現(xiàn)出了巨大的潛力，有望成為推動云原生技術普及和深化的關鍵力量，為數(shù)字化轉型注入新的活力和動力。

本方案來自于中科馭數(shù)軟件研發(fā)團隊，團隊核心由一群在云計算、數(shù)據(jù)中心架構、高性能計算領域深耕多年的業(yè)界資深架構師和技術專家組成，不僅擁有豐富的實戰(zhàn)經驗，還對行業(yè)趨勢具備敏銳的洞察力，該團隊致力于探索、設計、開發(fā)、推廣可落地的高性能云計算解決方案，幫助最終客戶加速數(shù)字化轉型，提升業(yè)務效能，同時降低運營成本。