開源邊緣計算平臺研究分析

黃 倩，黃 蓉，王友祥，陳 杲（中國聯(lián)通研究院，北京 100044）

0 引言

2020年，5G商用引爆通信業(yè)發(fā)展。以往通信設(shè)備都是軟硬件一體，一旦標(biāo)準(zhǔn)技術(shù)換代，就得研制新設(shè)備，導(dǎo)致投資大、靈活性差。5G 引入SDN∕NFV 技術(shù)后，采用標(biāo)準(zhǔn)服務(wù)器、存儲器和交換機來承載軟件化網(wǎng)絡(luò)功能，替代原有軟硬件一體專有設(shè)備，解決了通信設(shè)備迭代更新難度大的問題。隨著5G 不斷向軟件定義網(wǎng)絡(luò)方向發(fā)展，網(wǎng)絡(luò)架構(gòu)變得更加靈活，為了適應(yīng)這種變化，傳統(tǒng)CT、IT、公有云廠商也適時推出了開源邊緣計算平臺項目。

1 邊緣計算平臺現(xiàn)狀

萬物互聯(lián)時代到來，邊緣計算規(guī)模和業(yè)務(wù)復(fù)雜度發(fā)生了根本變化：邊緣實時計算、分析和邊緣智能等新型業(yè)務(wù)不斷涌現(xiàn)，對邊緣計算效率、可靠性和資源利用率提出了更高要求；因此，諸多廠家提出建設(shè)邊緣計算平臺，平臺涉及邊緣側(cè)網(wǎng)絡(luò)、計算以及存儲資源管理，提供基礎(chǔ)功能，如設(shè)備接入、安全校驗、監(jiān)控等，其接口、架構(gòu)、管理逐步成體系。但各廠家的邊緣計算平臺差異較大，行業(yè)邊緣應(yīng)用部署時需要適配不同邊緣計算平臺，導(dǎo)致跨平臺應(yīng)用部署難度大，故考慮引入開源技術(shù)打造5G MEC 邊緣計算架構(gòu)和能力開放的事實標(biāo)準(zhǔn)，打破當(dāng)前邊緣計算平臺市場煙囪式、碎片化現(xiàn)狀，降低產(chǎn)業(yè)應(yīng)用客戶上車門檻，實現(xiàn)規(guī)模復(fù)制，通過開源協(xié)作方式構(gòu)建統(tǒng)一5G MEC 平臺。下文從邊緣計算平臺參考架構(gòu)入手，引出2 種開源邊緣計算平臺進行分析。

2 典型邊緣計算平臺參考架構(gòu)

2020 年，在OSF 邊緣計算小組（Open Stack 基金會主導(dǎo)）發(fā)布的《邊緣計算：架構(gòu)，設(shè)計和測試的下一步》白皮書中，開源基礎(chǔ)設(shè)施運營商和供應(yīng)商聯(lián)合定義了以下2類典型邊緣參考體系結(jié)構(gòu)模型。

a）集中式控制平面模式：傳統(tǒng)單數(shù)據(jù)中心環(huán)境下中心控制器和邊緣計算節(jié)點由廣域網(wǎng)連接。該模式從集中運營角度看有優(yōu)勢，安全性高，但節(jié)點嚴重依賴集中式數(shù)據(jù)中心來承載管理和協(xié)調(diào)邊緣計算、存儲和網(wǎng)絡(luò)服務(wù)，邊緣節(jié)點自主性差，是一種傳統(tǒng)架構(gòu)模式。

b）分布式控制平面模式：多數(shù)控制服務(wù)駐留在大∕中型邊緣數(shù)據(jù)中心上，也要求邊緣站點自身功能全面。這種體系結(jié)構(gòu)比較靈活，尤其在網(wǎng)絡(luò)連接丟失情況下更凸顯其優(yōu)勢，但由于需要跨地域運行大量控制功能，管理編排類型服務(wù)更復(fù)雜。KubeEdge 屬于此類去中心化架構(gòu)模式。

3 開源平臺項目分析

KubeEdge和OpenNESS是市面上較為常見的開源平臺，均采用了通用VNF Manger 和NFV Orchestrator組件，參考了標(biāo)準(zhǔn)ETSI MANO 體系結(jié)構(gòu)，但其特點不盡相同，詳細分析如下。

3.1 KubeEdge

2019 年，KubeEdge 由華為捐給CNCF 基金會，基于Kubernetes（簡稱k8s）構(gòu)建，100%兼容k8s API，是Kubernetes IoT Edge WG 關(guān)鍵參考架構(gòu)之一，可提供云邊協(xié)同能力開放。

3.1.1 整體架構(gòu)

該平臺分為云端、邊緣端和終端3層，是解耦式的架構(gòu)，具體如圖1所示。

圖1 KubeEdge整體架構(gòu)

a）云端：負責(zé)應(yīng)用和配置策略下發(fā)，通過旁路設(shè)計開發(fā)CloudCore 組件，進行邊緣節(jié)點同步和維護，利用list watch與Kubernetes集群做信息同步。

b）邊緣端：負責(zé)運行邊緣應(yīng)用和管理接入設(shè)備。Edgecore 支持CRI，底層可以對接多種container runtime、device Twin 和DEvent Bus，主要做設(shè)備元數(shù)據(jù)管理以及MQTT 協(xié)議訂閱和發(fā)布，從而完成與終端設(shè)備通信。

c）終端：運行各種邊緣設(shè)備。設(shè)備終端有多類訪問協(xié)議，部分新設(shè)備可能直接支持MQTT 協(xié)議。但部分專用設(shè)備存在專用協(xié)議，KubeEdge 采用Mapper 設(shè)計，可將專有設(shè)備協(xié)議轉(zhuǎn)換成MQTT協(xié)議，實現(xiàn)邊緣應(yīng)用和云上設(shè)備數(shù)據(jù)同步和管理。

3.1.2 主要特點

KubeEdge針對邊緣側(cè)實際環(huán)境做了諸多優(yōu)化。

a）云邊可靠協(xié)同：采用雙向多路復(fù)用消息通道，支持邊緣節(jié)點位于私有網(wǎng)絡(luò)中，云邊消息傳輸默認使用Websocket 消息封裝，減少通信壓力，高時延下仍可正常工作。

b）邊緣離線自治：通過消息總線和元數(shù)據(jù)本地存儲實現(xiàn)節(jié)點離線自治，節(jié)點故障恢復(fù)也無需listwatch，從而降低網(wǎng)絡(luò)壓力，提升故障恢復(fù)速度。

c）邊緣極致輕量化：邊緣側(cè)節(jié)點Edgecore 內(nèi)存約70M，支持CRI 集成containerd 和CRI-O，優(yōu)化了runtime 資源消耗，方便在資源受限邊緣上運行；保留了Kubernetes 的管理面，重新開發(fā)了節(jié)點agent，大幅降低邊緣組件資源占用率。

d）k8s 原生支持：云端可以通過k8s API 管理邊緣設(shè)備和邊緣應(yīng)用程序。

但是作為一個開源項目，KubeEdge 仍有很多方面待繼續(xù)完善。

a）不支持設(shè)備協(xié)議如OPC-UA。

b）不支持使用數(shù)千個Edge 節(jié)點和數(shù)百萬個設(shè)備評估并啟用更大范圍的Edge群集。

c）不支持對大型Edge 集群的應(yīng)用程序進行智能調(diào)度。

3.2 OpenNESS

由Intel 主導(dǎo)，OpenNESS 是一套開源軟件開發(fā)套件，為在用戶邊緣側(cè)或網(wǎng)絡(luò)邊緣側(cè)等位置運行的應(yīng)用提供單一應(yīng)用托管環(huán)境，旨在多種網(wǎng)絡(luò)接入方式（Wi-Fi∕4G∕5G等）下助力邊緣業(yè)務(wù)管理與編排，通過抽象化去除網(wǎng)絡(luò)復(fù)雜性，讓開發(fā)人員可以像編寫云軟件一樣輕松編寫適用于邊緣的軟件，該項目在Akraino Edge Stack（Linux基金會項目）中被廣泛應(yīng)用。

3.2.1 整體架構(gòu)

OpenNESS 由邊緣節(jié)點和邊緣控制器2 個部分構(gòu)成。

a）邊緣節(jié)點：支持多種網(wǎng)絡(luò)接入方式，能夠從IP、S1_U 或者SG1 接口提取數(shù)據(jù)；支持針對5G 延遲、多租戶和服務(wù)注冊流量定向，并支持部署邊緣應(yīng)用。

b）邊緣控制器：一般處于數(shù)據(jù)中心、云中或邊緣等位置，進行邊緣平臺編排，采用GUI 方式，支持其他通信服務(wù)提供商采用API 方式鏈接到自己的控制器GUI 環(huán)境。圖2 為OpenNESS 抽象描述，展示邊緣節(jié)點上軟件和云控制器與其他技術(shù)相互配合的使用方式。

圖2 OpenNESS整體架構(gòu)

3.2.2 主要特點

OpenNESS 當(dāng)前側(cè)重4G∕5G 功能集成、底層Cloud native能力以及不同硬件資源適配能力。

a）支持獨立5G NR 和增強平臺感知部署。有5G接入模塊，AF可與NEF通過N33接口或者與PCF通過N5 接口通信，幫助MEP 下發(fā)分流規(guī)則以及事件訂閱等，支持HTTP∕2、HTTPS∕oAuth2 協(xié)議；OpenNESS 的DataPlane模塊是所有邊緣開源項目中比較獨特的。

b）高效擴展簡化編排：可以與Kubernetes（將來還包括Openstack）配合使用，可用于預(yù)配邊緣資源并為網(wǎng)絡(luò)邊緣配置增強型平臺感知功能，雖然本身不包含服務(wù)編排，但具備可連接到服務(wù)編排器的控制API。

c）提供應(yīng)用使能服務(wù)能力：提供API，可供應(yīng)用實現(xiàn)服務(wù)注冊、發(fā)現(xiàn)、訂閱和已訂閱服務(wù)查詢。

d）靈活擴展性強，多云兼容：基于微服務(wù)和開源API，OpenNESS可以為AWS Green grass、Microsoft Azure IoT Hub 和百度IntelliEdge 提供云連接器，因此更易于實施升級和更新管理。

3.3 對比分析

整體來看，各平臺涉及的技術(shù)?；疽恢拢诓渴鹦螒B(tài)、架構(gòu)、編排策略、可靠性和應(yīng)用場景等方面仍有差異（見表1），因此未來多平臺共存將是常態(tài)，如何加強各平臺間的協(xié)作將是未來的研究重點。

表1 開源邊緣計算平臺性能分析對比

4 3GPP&ETSI邊緣計算平臺架構(gòu)映射分析

4.1 3GPP

3GPP 主要關(guān)注的是網(wǎng)絡(luò)架構(gòu)對MEC 特性的支持，其中5G 網(wǎng)元UPF 作為邊緣計算的數(shù)據(jù)錨點、涉及用戶面重選、靈活業(yè)務(wù)疏導(dǎo)和計費等服務(wù)質(zhì)量保障方面內(nèi)容；MEC 與5G 的融合架構(gòu)主要關(guān)注3 個接口：MEC 平臺與NEF 的接口N33，與PCF 的接口N5，與UPF的接口N6。目前由Intel開發(fā)的OpenNESS平臺也已經(jīng)搭建了5G+MEC測試床。

4.2 ETSI

ETSI 對MEC 的定義為在移動網(wǎng)絡(luò)的邊緣提供IT服務(wù)環(huán)境和計算能力。MEC 架構(gòu)設(shè)計遵守基礎(chǔ)資源開放、平臺能力開放（通過MP1 接口，為APP 提供ME services ）、網(wǎng)絡(luò)能力開放（RNS API、Location API、bandwidth API、UE identity API）、管理能力開放、本地流量卸載以及移動性管理等原則。

4.3 部分開源平臺映射關(guān)系

OpenNESS 符合ETSI MEC 框架，其中邊緣控制器對應(yīng)MEPM，邊緣服務(wù)對應(yīng)MEP，邊緣應(yīng)用對應(yīng)ME APP。OpenNESS主要參考ETSI MEC規(guī)范，OpenNESS與ETSI 的映射關(guān)系如圖3 所示，其中藍色及橘色部分由OpenNESS實現(xiàn)。

圖3 OpenNESS與ETSI的映射關(guān)系

5 運營商實施建議

隨著企業(yè)大步向云原生時代邁進，電信運營商也逐步將云原生技術(shù)擴展到邊緣側(cè)，并密切關(guān)注全過程中的安全性、服務(wù)遙測、計算性能、彈性和擴展性，以便未來以開放互操作的方式調(diào)整組織、業(yè)務(wù)和運營流程，加快部署節(jié)奏，降低總成本和運維風(fēng)險，筆者建議如下。

a）提供統(tǒng)一邊緣計算參考實現(xiàn)標(biāo)準(zhǔn)，聚焦整體框架、接口定義及實現(xiàn)方式，并進一步統(tǒng)一面向應(yīng)用的接口，降低應(yīng)用開發(fā)伙伴上車門檻，逐步打破各家煙囪式MEC方案，打破市場隔離。

b）積極與公有云廠商合作，作為當(dāng)前公有云服務(wù)提供商的補充，可避免重復(fù)部署資本密集型基礎(chǔ)設(shè)施，實現(xiàn)快速上市和測試新行業(yè)用例，共享行業(yè)應(yīng)用程序生態(tài)系統(tǒng)資源。

c）打造新協(xié)作生產(chǎn)關(guān)系，改善運營商與廠家之間的關(guān)系，由傳統(tǒng)的供應(yīng)關(guān)系改為合作，聯(lián)合設(shè)備廠家、應(yīng)用廠家以及科研機構(gòu)從不同角度加強協(xié)作共建，構(gòu)建開放的生產(chǎn)關(guān)系，打破傳統(tǒng)的封閉式合作模式，激活商業(yè)創(chuàng)新。

d）重點關(guān)注邊緣計算平臺的異構(gòu)硬件支持、移動性支持、IT∕CT鴻溝的關(guān)鍵技術(shù)點以及平臺是否支持邊緣節(jié)點輕量化部署和邊緣離線自治。

總體看來，當(dāng)前邊緣計算相關(guān)創(chuàng)新和開源化進程仍處于早期階段。雖然開源將打破舊有設(shè)備供應(yīng)鏈格局，但在開放架構(gòu)下，如何加強各開源平臺間協(xié)同創(chuàng)新，保障各方利益，平衡開源和專利保護，這些有待進一步研究與探討。