面向FaaS的算網異構資源調度技術

李銘軒 常 培 崔 童 李朝霞

1 中國聯通研究院 北京 100048

2 中國聯合網絡通信集團有限公司 北京 100032

3 聯通數字科技有限公司 北京 100085

引言

傳統云計算技術的研究領域主要集中在虛擬化、存儲等資源的集中管理和調度等方面，而對于網絡資源的納管，更多關注領域是研究如何通過建立網絡連接，實現計算、存儲等資源的互聯互通。而隨著算網融合技術的發展以及面向底層計算架構的多樣化，目前云計算技術的發展更多需要考慮兩個方面：一方面，對底層異構計算單元的統一納管；另一方面，網絡資源不單單只提供計算資源的網絡連接，更多的能夠面向不同的計算場景提供不同的網絡類型。文獻[1]具體闡述了在算力網絡發展過程中，網絡如何更好滿足計算的需求，同時也提出“將邊緣節點、云計算節點以及含廣域網在內的各類網絡資源深度融合在一起……其能夠根據客戶需求，在云、網、邊之間按需分配和靈活調度計算資源、存儲資源以及網絡資源”。

另外，云原生技術的興起，改變了傳統對于云計算資源的交付模式，從傳統的云主機、云存儲等計算單位逐漸發展到面向服務能力的交付，使得使用者不再需要關注底層計算資源的使用情況，而更加關注服務能力以及其之上業務場景和需求的開發[2]，而Serverless模式的概念正是滿足了這種模式發展的需求。本文從不同的算網資源的角度出發，研究了底層異構算力的統一管理，同時面向上層業務和場景不同，提供面向FaaS的服務能力，以期能夠屏蔽底層的異構資源，更好地為業務創新和開發提供便捷的環境[3]。

1 Serverless介紹

Serverless是一種構建和管理基于微服務架構的完整流程，允許在服務部署級別而不是服務器部署級別來管理應用部署。與傳統架構的不同之處在于，服務完全由第三方管理，由事件觸發，存在于無狀態(Stateless)、暫存(可能只存在于一次調用的過程中)計算容器內。構建無服務器應用程序意味著開發者可以專注于產品代碼開發上，而無須管理和操作云端或本地的服務器或運行時，Serverless真正做到了部署應用無需涉及基礎設施的建設，自動構建、部署和啟動服務[4]。

FaaS(Function as a Service,函數即服務)和BaaS(Backend as a Service，后端即服務)目前是Serverless技術發展所涵蓋的兩個主流方向，其中FaaS意在無須自行管理服務器系統或自己的服務器應用程序，即可直接運行后端代碼。FaaS可以取代一些服務處理服務器，不僅僅不需要自行供應服務器，也不需要全時運行應用程序[5]。

1.1 Knative技術架構

Knative是谷歌開源的Serverless架構方案，旨在提供一套簡單易用的Serverless方案，把Serverless標準化。目前參與的公司主要有Google、Pivtal、IBM等，自2018年7月24日對外發布以來，迅速得到業務的廣泛關注，又由于是谷歌開放的開源架構[6]，因此和Kubernetes天然耦合，因此處于快速發展的階段。根據官方的闡述，其主要架構如圖1所示。

圖1 Knative技術架構

基于上述架構，Knative基于Kubernetes進行部署，并且能夠通過Kubernetes調度到底層的容器資源，同時對外暴露API接口以便于開發者進行開發和部署，而上層用戶可以基于Istio的Service Mesh(服務網格)來承載應用的編排。通過這種方式可以進一步屏蔽掉用戶和開發者共用同一個Kubernetes平臺入口，一方面為開發者提供基于Knative實現應用DevOps開發；另一方面，為用戶提供基于Istio的應用服務部署。同時兩者都不再需要關心Kubernetes本身的容器資源調度情況和人工手動編寫腳本來實現業務層的編排調度的煩惱，而進一步關注于業務代碼開發本身。

1.2 Knative核心概念

Knative本身主要由Build、Serving和Eventing三大核心組件構成。Knative正是依靠著這三個核心組件來實現整個Serverless的運作機制的。

1)Build：基于Kubernetes能力之上，提供一套完整的標準化、可移植、可復用的容器鏡像構建方式。

2)Serving：主要用來提供服務，其構建于Kubernetes和Istio之上，為Serverless應用提供部署和服務支持。應用服務可以基于Serving進行自動擴縮容，并且基于Istio組件提供路由和網絡編程等。

3)Eventing：滿足云原生開發中通用需求，以提供可組合的方式綁定事件源和事件消費者。

2 算力網絡技術架構

算力網絡是從傳統的云網融合的角度出發，結合邊緣計算、云化網絡以及智能控制等優勢，在算力網絡連接下實現更加廣泛的算力資源的納管和動態調度。在資源納管方面，算力網絡與傳統的云網融合不同，更加注重網絡連接和控制對于“云、邊、端”的異構資源的納管和多集群協調的影響和融合[7]。算力網絡整體技術架構如圖2所示。

圖2 算力網絡技術架構

依據上述技術架構，算力網絡的云原生資源統一調度平臺對底層實現對于存儲、計算和網絡控制節點的統一管理，通過網絡插件實現對于底層算力承載網的控制，從而實現網絡連接和網絡質量控制，而通過存儲插件實現對于共享存儲的調度和管理。另外通過Kubernetes的多集群管理能力，實現對于邊緣云的對接，從而可以實現和遠端邊緣嵌入式終端的資源管理和調度[8]。

基于上述的算力網絡技術架構，底層算力網絡資源和邊緣云終端資源納管基于云原生資源編排調度技術實現統一納管。而上層則通過平臺能力下沉等方式形成算力網絡的服務能力，結合算力網絡的第三方算力能力和自有的算力能力形成一個統一的算力網絡能力集并通過算力網絡統一開放平臺對外進行開放。從而為上層的用戶和開發者提供應用商店實現一鍵部署，同時統一提供API接口為實現第三方的開發提供基礎。

3 基于FaaS的算網異構算力調度方案

基于上述的算力網絡技術架構，傳統的云網融合技術只能通過基礎設施層提供虛擬化計算、存儲和網絡的統一納管，并且對于上層應用場景只能夠單純提供虛機資源、共享存儲以及虛擬網絡等資源，用戶還需要在此基礎上進行平臺的部署和二次開發。并且在開發過程中同樣需要考慮算力和網絡資源的整合等問題，從而也提高了整個面向算力網絡資源的利用率。而基于FaaS的算網異構資源統一調度環境下，整合了底層算力網絡資源的能力，對上通過服務網格的方式實現應用服務的編排調度，同時通過API和服務鏡像打包的方式提供算力網絡開放能力，這樣使用者可以基于算力網絡本身的服務能力進行開發，因此使用者可以更多地關注業務代碼本身。

3.1 技術架構

基于上述的算網異構資源的統一調度和面向使用者的FaaS服務開放，本文提出了基于云原生的異構算力資源的Serverless模式的技術架構，其技術架構如圖3所示。

圖3 FaaS異構算力技術架構

依據圖3的技術架構，面向FaaS的算網異構資源調度由算力管理層實現對底層網絡、存儲、邊緣計算和中心云進行統一管理和編排調度。在算力管理層包括算力注冊、算力發現、算力路由來實現對于底層異構算力的生命周期管理，并且基于開源的云原生資源調度平臺Kubernetes來實現對于算力的調度管理，同時基于網絡接口和存儲接口來實現對于網絡和存儲的管理。

通過Kubernetes底層資源的調度能力對上層提供面向異構資源的編排調度能力[9]，與無服務框架Knative進行融合和對接，從而提供函數服務能力。而在函數服務能力中結合Knative的Build組件來實現代碼的鏡像打包、部署和版本管理等，底層算力管理層也依托函數服務能力來封裝底層資源，從而提供開放的API函數接口。依托Knative的Service組件來實現面向上層的服務編排，整個開發者的代碼由函數服務能力層中的代碼托管來進行統一管理，而打包生成的鏡像則由鏡像倉庫來進行管理。所有版本更新和新函數事件發布等則是由核心組件Event來進行統一的事件消息發布等。

基于上述的整體技術架構，為上層應用提供了封裝好的算力網絡異構資源的函數級調度和封裝能力，開發者或者用戶本身不需要關注底層的資源部署在什么位置或者服務器上，不需要關心需要申請多少硬件或者虛機資源等，而將更多的精力關注在業務邏輯代碼的開發和業務創新上面。從而可以大大降低算網異構資源作為新基建在應用過程中的門檻。

3.2 異構資源管理

面向FaaS的算網異構資源調度管理機制是基于云原生的底層異構算力節點統一資源納管，通過底層異構計算芯片作為算力節點在云原生編排調度平臺上進行節點管理和注冊，并且通過標簽的方式來實現算力節點的管理，同時將容器作為原子級的算力調度單元實現了算力節點的資源獲取和應用部署，從而實現了異構資源的統一管理。

基于上述的異構算力資源的整體納管機制，本文采用多集群管理和異構計算芯片資源抽象的方式來實現分級的異構資源統一管理，其中在多集群管理中基于Kubernetes云原生的Operator多集群管理機制實現對于不同數據中心、邊緣集群以及網絡連接的融合管理[10]。在跨數據中心的集群選擇和算力路由等方面，結合業務需求和算力推薦，通過Operator來選擇合適的數據中心位置和算力集群來承載應用運行。

而對于異構算力資源抽象機制，如圖4所示，在底層的異構算力芯片的管理方面，通過云原生Kubernetes的CRD資源抽象的方式來進行定義[11]，通過底層驅動層將算力節點注冊到資源編排調度層中，并且在CRD資源抽象層進行資源定義和抽象。通過Kubernetes的配置腳本yaml在云原生應用中將所需運行的資源進行調用，Kubelet在接收到配置腳本時，則會根據yaml腳本將POD創建在指定的算力節點上執行，從而實現了異構資源的調度。

圖4 異構算力資源抽象調度圖

3.3 面向FaaS的服務能力開放

基于底層異構算力資源的抽象定義機制能夠實現對于算力資源的統一納管和調度，并且在資源層實現了統一，而基于FaaS的算網異構資源調度機制能夠在服務層實現算力網絡能力的統一，通過云原生技術來實現底層資源的調度以及面向上層應用的服務能力開放[12]。其平臺的整體功能架構如圖5所示。

依據圖5所示，在資源層主要實現計算、存儲和網絡的整體管理。在調度層基于云原生基礎實現網絡、算力和存儲的調度，同時結合能力下沉的研發模式，不斷積累和豐富相關能力集從而形成算力網絡的中臺能力。而編排層則主要負責將底層的資源進一步轉化為服務能力，基于Service Mesh實現服務路由、服務注冊和服務發現等功能。而在應用層則進一步采用Serverless模式，結合開源框架Knative實現鏡像打包、業務代碼托管和應用商店能力，并且通過函數服務為上層的自服務門戶和開發者門戶提供API函數接口和調用服務。

圖5 異構算網資源能力開放平臺

依據上述異構算網資源能力開放平臺的整體架構，主要分為以下幾個部分。

1)資源層主要對基礎設施進行統一納管，包括異構算力，諸如X86、GPU、ARM、TPU、NPU等各種架構的算力，各種存儲類型以及網絡的管理和調度能力。

2)調度層主要分為兩部分的能力，一方面具備對于底層資源層的計算、存儲和網絡的基本調度能力以及異構資源的抽象；另一方面能夠實現能力下沉，結合服務應用場景的調度能力形成基礎能力集。根據不同的應用場景分為計算能力集、機器學習能力集以及網絡方面的控制能力集，從而可以更好地銜接基礎算力能力和上層服務編排需求。

3)編排層基于目前主流的云原生Kubernetes和服務網格Service Mesh實現服務注冊、服務發現、服務路由以及邊車管理等功能來實現微服務組件之間的連接和通訊。

4)函數服務是基于云原生的Kubernetes和Service Mesh的服務編排基于開源Serverless框架Knative的API網關來實現服務編排能力的API開放以及業務的代碼的托管和鏡像打包，并且通過應用商店能力提供可視化的服務能力瀏覽和一鍵化部署等能力。

5)自服務門戶/開發者門戶為用戶提供不同的業務服務渠道，自服務門戶為用戶提供業務部署和業務運營的服務門戶，提供應用商店的服務部署等功能；而開發者門戶為用戶提供業務代碼開發和API調用，代碼托管等方面的功能。

6)監控層實現整個異構算網資源開放平臺常規的平臺運行、資源監控以及安全告警等方面的功能。

異構算網資源調度服務平臺，從底層逐步統一納管異構算力網絡資源的管理和調度，到逐步轉向面向應用的服務化編排調度能力，再到上層的函數服務能力開放，從而將異構的算力網絡資源進行了有效的統一和開放。這樣開發者或者應用使用者不需要關心底層計算資源的分配或者網絡帶寬的連接，而將更多的精力關注到面向業務代碼的開發和邏輯編排上來，從而可以更好地促進算力網絡平臺架構下的多場景應用的業務創新，真正可以引入互聯網化的“前店后廠”業務創新模式和思維。

4 總結

異構算力網絡技術的發展是下一代云網融合2.0技術的發展趨勢，而在傳統的基礎設施建設過程中，云原生技術和網絡新技術的引入為算力網絡的發展注入了新的活力[13]。而本文所提出的面向FaaS的算網異構資源調度技術，在傳統納管各種新型異構計算資源的基礎上，采用云原生架構提出了面向FaaS的Serverless框架，從而可以很好地屏蔽掉紛繁復雜且異構多變的算力網絡資源，從而使得用戶更多地關注于上層業務邏輯的開發和編排，以更好地促進算力網絡技術的發展。