顧笛兒，盧華，謝人超,3，黃韜,3

邊緣計(jì)算開(kāi)源平臺(tái)綜述

顧笛兒1，盧華2，謝人超1,3，黃韜1,3

（1. 北京郵電大學(xué)網(wǎng)絡(luò)與交換國(guó)家重點(diǎn)實(shí)驗(yàn)室，北京 100876；2. 廣東省新一代通信與網(wǎng)絡(luò)創(chuàng)新研究院，廣東 廣州 510700；3.紫金山實(shí)驗(yàn)室，江蘇 南京 211111）

首先介紹了邊緣計(jì)算（EC）的基本概念和研究現(xiàn)狀，并從多視角討論了邊緣計(jì)算平臺(tái)的設(shè)計(jì)要求；接著聚焦到4個(gè)典型的開(kāi)源平臺(tái)，并從應(yīng)用領(lǐng)域、部署方式等方面比較了它們之間的異同點(diǎn)；隨后選取了兩個(gè)典型的應(yīng)用案例，分別針對(duì)它們的優(yōu)勢(shì)、搭建進(jìn)行了概述和分析；最后對(duì)邊緣計(jì)算平臺(tái)之間的合作、安全、標(biāo)準(zhǔn)化等問(wèn)題進(jìn)行了歸納和展望。

邊緣計(jì)算；開(kāi)源平臺(tái)；對(duì)比性研究；應(yīng)用案例

1 引言

近年來(lái)，隨著萬(wàn)物互聯(lián)（IoE，internet of everything）時(shí)代的到來(lái)和5G網(wǎng)絡(luò)的普及，傳感器、智能手機(jī)、可穿戴物件等物聯(lián)網(wǎng)設(shè)備產(chǎn)生的海量數(shù)據(jù)與邊緣設(shè)備本身受限的計(jì)算、存儲(chǔ)資源成為一對(duì)鮮明矛盾。針對(duì)終端設(shè)備資源受限問(wèn)題的傳統(tǒng)解決方法是將數(shù)據(jù)上傳至云端做統(tǒng)一集中式處理。但云數(shù)據(jù)中心通常部署在遠(yuǎn)離用戶的地方，這就帶來(lái)以下兩個(gè)問(wèn)題：①終端和云端之間數(shù)據(jù)傳輸存在較大的時(shí)延；②大量數(shù)據(jù)交換給網(wǎng)絡(luò)帶寬和數(shù)據(jù)中心之間的鏈路帶寬帶來(lái)巨大壓力。為了解決上述問(wèn)題，將計(jì)算資源下沉到網(wǎng)絡(luò)邊緣的邊緣計(jì)算（EC，edge computing）模型應(yīng)運(yùn)而生。

邊緣是業(yè)務(wù)的匯聚點(diǎn)，是網(wǎng)絡(luò)的自然延伸，邊緣計(jì)算的實(shí)現(xiàn)過(guò)程可概括為聯(lián)結(jié)能力下移、應(yīng)用能力下移和端側(cè)算力上移，可同時(shí)滿足超低時(shí)延、業(yè)務(wù)連續(xù)、超大吞吐、內(nèi)容本地化的需求。EC將計(jì)算密集型任務(wù)推向邊緣并在用戶附近對(duì)數(shù)據(jù)進(jìn)行本地處理，移動(dòng)網(wǎng)絡(luò)運(yùn)營(yíng)商可以減少核心網(wǎng)和回程鏈路中的流量瓶頸，同時(shí)協(xié)助將繁重的計(jì)算任務(wù)從用戶設(shè)備卸載到邊緣，極大減少了網(wǎng)絡(luò)時(shí)延[1]。邊緣計(jì)算的操作對(duì)象包括來(lái)自云服務(wù)的下行數(shù)據(jù)和來(lái)自萬(wàn)物互聯(lián)服務(wù)的上行數(shù)據(jù)[2]，邊緣的定義尚無(wú)統(tǒng)一標(biāo)準(zhǔn)，但多認(rèn)可位于接近最后一公里網(wǎng)絡(luò)的基礎(chǔ)設(shè)施側(cè)和設(shè)備側(cè)。不同邊緣位置各自產(chǎn)生的時(shí)延如圖1所示[3]。

邊緣計(jì)算這一技術(shù)的思想最早于2009年在“微云”[4]和“移動(dòng)云計(jì)算”[5]這兩個(gè)概念中有所體現(xiàn)，業(yè)界認(rèn)可度最高的包含霧計(jì)算（fog computing）以及移動(dòng)邊緣計(jì)算（MEC，mobile edge computing）這兩種方案。

思科于2012年針對(duì)物聯(lián)網(wǎng)應(yīng)用場(chǎng)景中海量終端分布在網(wǎng)絡(luò)邊緣以及傳統(tǒng)集中式云計(jì)算架構(gòu)很難滿足物聯(lián)網(wǎng)場(chǎng)景中時(shí)延敏感類業(yè)務(wù)的實(shí)時(shí)性要求等問(wèn)題，首次提出霧計(jì)算的概念。霧計(jì)算是云計(jì)算的一種拓展，在物聯(lián)網(wǎng)終端設(shè)備與傳統(tǒng)的云計(jì)算中間為用戶提供計(jì)算、存儲(chǔ)以及網(wǎng)絡(luò)服務(wù)。隨著研究深入，霧節(jié)點(diǎn)的范圍已從早期的分布式云計(jì)算，拓展至路由器、交換機(jī)等可以部署在終端周邊的網(wǎng)絡(luò)設(shè)備。

2014年，歐洲電信標(biāo)準(zhǔn)化協(xié)會(huì)（ETSI，European Telecommunications Standards Institute）首次提出了MEC（multi-access edge computing）的概念，并將其定義為在移動(dòng)網(wǎng)絡(luò)邊緣提供IT服務(wù)環(huán)境和云計(jì)算能力[6]。隨著ETSI MEC標(biāo)準(zhǔn)化工作的推進(jìn)，MEC概念已經(jīng)從第一階段針對(duì)第三代合作伙伴計(jì)劃（3GPP，Third Generation Partnership Project）為目標(biāo)，拓展至對(duì)非3GPP網(wǎng)絡(luò)（Wi-Fi、有線網(wǎng)絡(luò)等）以及3GPP后續(xù)演進(jìn)網(wǎng)絡(luò)（5G等）的支持，其名稱也從第一階段的移動(dòng)邊緣計(jì)算修改為多接入邊緣計(jì)算。

霧計(jì)算針對(duì)的是廣義網(wǎng)絡(luò)，致力于解決如何通過(guò)霧節(jié)點(diǎn)來(lái)為移動(dòng)終端或物聯(lián)網(wǎng)終端提供分布式云計(jì)算服務(wù)，其通信鏈路可以基于有線網(wǎng)絡(luò)、移動(dòng)網(wǎng)絡(luò)、Wi-Fi、傳感網(wǎng)等任意一種連接方式。因此霧計(jì)算在節(jié)點(diǎn)設(shè)備選擇上更加靈活，但設(shè)備算力和存儲(chǔ)容量略遜于MEC服務(wù)器[7]。上述邊緣計(jì)算的概念雖然是不同研究與標(biāo)準(zhǔn)組織在不同背景下提出的，但它們都擁有一個(gè)共同目標(biāo)——將云計(jì)算能力拓展至網(wǎng)絡(luò)邊緣，使終端用戶可以快速、高效、安全地使用云計(jì)算服務(wù)。并且可以根據(jù)用戶位置以及業(yè)務(wù)應(yīng)用需求靈活部署邊緣設(shè)備或者賦予相應(yīng)的邊緣設(shè)備網(wǎng)絡(luò)與業(yè)務(wù)能力，以虛擬化網(wǎng)絡(luò)與業(yè)務(wù)服務(wù)的形式，通過(guò)多種寬帶接入方式，滿足多租戶服務(wù)的共享與隔離。

圖1 不同邊緣位置各自產(chǎn)生的時(shí)延

Figure 1 Different delays produced under different definitions of edge

盡管霧計(jì)算和MEC存在很多相似之處，二者還是有一定區(qū)別。例如，EC部署位置的差異直接決定誰(shuí)會(huì)成為邊緣云計(jì)算服務(wù)的提供者[8]。在MEC場(chǎng)景下，運(yùn)營(yíng)商作為移動(dòng)網(wǎng)絡(luò)設(shè)施的投資建設(shè)和運(yùn)營(yíng)運(yùn)維者，自然成為MEC邊緣云功能的主要提供者，而霧節(jié)點(diǎn)可以由任意用戶部署，用戶也有機(jī)會(huì)成為服務(wù)提供者，甚至創(chuàng)建屬于用戶的私有云服務(wù)，成為邊緣云服務(wù)生態(tài)鏈中的一環(huán)。本文重點(diǎn)討論的邊緣計(jì)算解決方案，既可以部署在運(yùn)營(yíng)商管控的電信大樓中，為第三方業(yè)務(wù)提供更靠近移動(dòng)網(wǎng)絡(luò)、用戶的業(yè)務(wù)運(yùn)營(yíng)環(huán)境，實(shí)現(xiàn)移動(dòng)網(wǎng)絡(luò)上下文信息（位置、網(wǎng)絡(luò)負(fù)荷等）的感知與開(kāi)發(fā)；也可以部署在個(gè)人計(jì)算機(jī)中，直接實(shí)現(xiàn)對(duì)個(gè)人設(shè)備的操控。因此，本文統(tǒng)一稱這些方案為邊緣計(jì)算平臺(tái)。

面對(duì)邊緣數(shù)據(jù)的爆炸式增長(zhǎng)，邊緣計(jì)算作為一項(xiàng)新興技術(shù)受到了學(xué)術(shù)界和產(chǎn)業(yè)界的高度關(guān)注。企業(yè)產(chǎn)生的數(shù)據(jù)大約有10 %是在傳統(tǒng)集中式數(shù)據(jù)中心之外產(chǎn)生并處理的，據(jù)IT咨詢機(jī)構(gòu)Gartner估計(jì)，至2025年，這個(gè)數(shù)字將會(huì)上升至75%[9]。Grand View Research預(yù)測(cè)，對(duì)比2019年的35億美金，2020年到2027年全球邊緣計(jì)算市場(chǎng)規(guī)模的復(fù)合年增長(zhǎng)率將超過(guò)37%[10]，這意味著大數(shù)據(jù)時(shí)代的數(shù)據(jù)源也在經(jīng)歷轉(zhuǎn)變——從大規(guī)模云數(shù)據(jù)中心轉(zhuǎn)變?yōu)楦采w越來(lái)越廣的邊緣設(shè)備[11]。為了充分利用通信鏈路上的計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)資源處理這些數(shù)據(jù)，業(yè)內(nèi)已有多家廠商與機(jī)構(gòu)加入了邊緣計(jì)算平臺(tái)系統(tǒng)的開(kāi)發(fā)中，以實(shí)現(xiàn)對(duì)資源的統(tǒng)一管理并方便開(kāi)發(fā)者快速部署應(yīng)用。

從用戶視角來(lái)看，這些邊緣計(jì)算平臺(tái)必須滿足以下體驗(yàn)要求。

（1）互操作性：設(shè)備和服務(wù)器之間必須通過(guò)相同的通用通信協(xié)議進(jìn)行連接。

（2）可伸縮性：框架必須足夠靈活，可以自適應(yīng)容納新添的用戶和傳感器。

（3）可拓展性：框架必須支持新功能和設(shè)備的集成，而無(wú)須重新配置邊緣網(wǎng)絡(luò)。

（4）安全性：框架必須防止數(shù)據(jù)泄露以及未經(jīng)授權(quán)的內(nèi)部用戶訪問(wèn)網(wǎng)絡(luò)。

從開(kāi)發(fā)者視角來(lái)看，邊緣平臺(tái)開(kāi)發(fā)必須滿足以下設(shè)計(jì)要求。

（1）同一個(gè)邊緣計(jì)算平臺(tái)多微服務(wù)框架可以互相通信，并且可基于多微服務(wù)框架進(jìn)行相關(guān)的治理。

（2）邊緣計(jì)算平臺(tái)可以管理多種VIM，適配x86、ARM平臺(tái)；支持虛擬機(jī)和容器的部署。

（3）應(yīng)用可以基于邊緣計(jì)算平臺(tái)的軟件開(kāi)發(fā)工具包（SDK，software development kit）或者Rest API使用5G網(wǎng)絡(luò)能力。

（4）平臺(tái)擁有完善的生態(tài)應(yīng)用系統(tǒng)，可以自動(dòng)或手動(dòng)打包鏡像，并且能夠基于平臺(tái)測(cè)試提供對(duì)應(yīng)應(yīng)用程序接口（API，application program interface）能力。

目前已發(fā)布的邊緣計(jì)算平臺(tái)大致分為兩類：開(kāi)源框架和商業(yè)產(chǎn)品[12]。Linux基金會(huì)面對(duì)邊緣計(jì)算市場(chǎng)的碎片化成立了一個(gè)開(kāi)源項(xiàng)目——LF Edge，它包含Akraino Edge Stack和EdgeX Foundry等項(xiàng)目，該基金會(huì)希望通過(guò)這些項(xiàng)目，凝結(jié)用戶、企業(yè)、運(yùn)營(yíng)商之間的合作，實(shí)現(xiàn)涵蓋硬件、基礎(chǔ)架構(gòu)云、電信網(wǎng)絡(luò)和應(yīng)用程序的邊緣生態(tài)系統(tǒng)。ONF基金會(huì)和華為分別宣布了CORD和KubeEdge作為其開(kāi)源邊緣計(jì)算平臺(tái)向廣大開(kāi)發(fā)者開(kāi)放。商業(yè)產(chǎn)品包括亞馬遜的AWS、微軟的Azure等。

邊緣計(jì)算平臺(tái)作為一種可同時(shí)解決數(shù)據(jù)異構(gòu)性、計(jì)算資源可管理性、應(yīng)用程序復(fù)雜性等問(wèn)題的集成方案，已成為各界研究人員關(guān)注的重點(diǎn)之一。然而，盡管針對(duì)邊緣計(jì)算平臺(tái)的開(kāi)發(fā)已經(jīng)在企業(yè)內(nèi)部如火如荼地展開(kāi)，并取得了一些代表性成果，但學(xué)術(shù)界鮮有文獻(xiàn)對(duì)邊緣計(jì)算平臺(tái)作針對(duì)性的研究。因此，本文擬對(duì)邊緣計(jì)算平臺(tái)及其應(yīng)用場(chǎng)景進(jìn)行系統(tǒng)性的概述。

2 典型的邊緣計(jì)算平臺(tái)介紹

新興的邊緣計(jì)算部署方案中，用戶可以通過(guò)邊緣計(jì)算平臺(tái)在邊緣設(shè)備上安全、便捷地運(yùn)行本地處理、消息轉(zhuǎn)發(fā)、數(shù)據(jù)緩存及同步等操作，邊緣計(jì)算平臺(tái)正獲得越來(lái)越多的業(yè)內(nèi)關(guān)注和參與。本節(jié)就幾個(gè)典型的邊緣計(jì)算平臺(tái)架構(gòu)進(jìn)行了介紹。因此，本文擬對(duì)邊緣計(jì)算平臺(tái)及其應(yīng)用場(chǎng)景進(jìn)行系統(tǒng)性的概述。

2.1 Akraino Edge Stack

Akraino Edge Stack是Linux基金會(huì)于2018年2月創(chuàng)建的一個(gè)開(kāi)源軟件堆棧，支持包括5G、LTE、Wireline和Wi-Fi在內(nèi)的接入方式，并提供針對(duì)邊緣計(jì)算系統(tǒng)和應(yīng)用程序優(yōu)化的高可用性云服務(wù)。它旨在改善企業(yè)邊緣、OTT(over the top）邊緣和運(yùn)營(yíng)商邊緣網(wǎng)絡(luò)的邊緣云基礎(chǔ)架構(gòu)狀態(tài)，為用戶提供全新級(jí)別的靈活性，以便快速擴(kuò)展邊緣云服務(wù)，最大限度地提高每臺(tái)服務(wù)器上支持的應(yīng)用程序或用戶數(shù)量，幫助確保系統(tǒng)運(yùn)行時(shí)的可靠性[13]。

與大多數(shù)開(kāi)源項(xiàng)目只提供邊緣計(jì)算所需的組件功能不同，Akraino Edge Stack為構(gòu)建完全集成的邊緣基礎(chǔ)架構(gòu)提供了一個(gè)涵蓋基礎(chǔ)設(shè)施、中間件及邊緣計(jì)算應(yīng)用的完整的解決方案，如圖2所示。頂層是應(yīng)用部署，主要負(fù)責(zé)部署邊緣應(yīng)用并創(chuàng)建App/VNF（virtual network function）的邊緣生態(tài)系統(tǒng)。中間層包含支持頂層應(yīng)用的中間件，并通過(guò)開(kāi)發(fā)、統(tǒng)一API的方式實(shí)現(xiàn)與第三方開(kāi)源邊緣計(jì)算項(xiàng)目的交互性操作。底層對(duì)接上層開(kāi)源堆棧如Kubernetes、OpenStack等。

Akraino開(kāi)源項(xiàng)目以藍(lán)圖為組織架構(gòu)，使用藍(lán)圖來(lái)實(shí)現(xiàn)基于邊緣計(jì)算的多樣化用例。每個(gè)藍(lán)圖包含上述3層堆棧的聲明性配置，如云平臺(tái)、API和應(yīng)用。具體來(lái)講，它包括某一具體場(chǎng)景下的邊緣計(jì)算應(yīng)用或架構(gòu)的配置聲明、硬件、軟件、管理整個(gè)堆棧的工具和交付點(diǎn)（PoD，pod of delivery），其中PoD詳細(xì)描述了站點(diǎn)自動(dòng)部署流程和腳本，覆蓋了CI/CD、集成以及測(cè)試工具等。理想情況下，每個(gè)發(fā)布的藍(lán)圖可以實(shí)現(xiàn)自動(dòng)邊緣基礎(chǔ)架構(gòu)構(gòu)建、邊緣堆棧站點(diǎn)部署、上下游項(xiàng)目集成和自動(dòng)編排等，這意味著Akraino可以通過(guò)零接觸配置、生命周期管理以及自動(dòng)縮放功能支持大規(guī)模、低成本的邊緣計(jì)算應(yīng)用[14]，具有極高的商用價(jià)值。

2.2 EdgeX Foundry

EdgeX Foundry是一個(gè)由Linux基金會(huì)主持，旨在為物聯(lián)網(wǎng)邊緣計(jì)算構(gòu)建通用的開(kāi)放框架的開(kāi)源項(xiàng)目。該框架可以運(yùn)行在包括網(wǎng)關(guān)、路由器、邊緣服務(wù)器在內(nèi)的任何邊緣節(jié)點(diǎn)上，它獨(dú)立于硬件、協(xié)議和操作系統(tǒng)，實(shí)現(xiàn)了即插即用的組件生態(tài)系統(tǒng)，解決了異構(gòu)設(shè)備和應(yīng)用程序之間的互操作性問(wèn)題（如支持分析、數(shù)據(jù)編排、系統(tǒng)管理和服務(wù)、安全性等），進(jìn)而統(tǒng)一了市場(chǎng)，推動(dòng)了物聯(lián)網(wǎng)解決方案的部署。

圖2 Akraino Edge Stack范圍

Figure 2 The framework of Akraino Edge Stack

EdgeX Foundry亦可視為一系列松耦合、開(kāi)源的微服務(wù)集合。微服務(wù)架構(gòu)允許開(kāi)發(fā)人員將某一應(yīng)用程序劃分為一系列獨(dú)立的服務(wù)，每個(gè)服務(wù)運(yùn)行在獨(dú)立的進(jìn)程中，服務(wù)與服務(wù)采用輕量級(jí)的通信機(jī)制（如Restful API）進(jìn)行溝通。EdgeX Foundry中所有微服務(wù)都被部署成彼此之間相互隔離的輕量級(jí)容器，支持動(dòng)態(tài)增加或減少功能[15]，保證了整體框架的縮放能力和可維護(hù)性。

EdgeX Foundry的整體架構(gòu)如圖3所示，框架下方的“南向設(shè)備和傳感器”是數(shù)據(jù)產(chǎn)生源，指的是在物理領(lǐng)域內(nèi)所有的物聯(lián)網(wǎng)對(duì)象，以及與這些設(shè)備、傳感器等物聯(lián)網(wǎng)對(duì)象直接通信并從中收集數(shù)據(jù)的網(wǎng)絡(luò)邊緣?？蚣苌戏降摹氨毕蚧A(chǔ)設(shè)施和應(yīng)用”指的是將南向傳來(lái)的數(shù)據(jù)收集、存儲(chǔ)、聚合、分析并轉(zhuǎn)換為有用信息的云，以及與云通信的網(wǎng)絡(luò)部分。EdgeX Foundry由以下兩部分組成：用于業(yè)務(wù)邏輯定義的4個(gè)水平子層，負(fù)責(zé)安全和管理功能的兩個(gè)垂直子層（系統(tǒng)安全層和系統(tǒng)服務(wù)層），其中，第一部分的4個(gè)水平子層的描述如下。

（1）設(shè)備服務(wù)層：負(fù)責(zé)將來(lái)自設(shè)備的原始數(shù)據(jù)格式轉(zhuǎn)換后發(fā)送給核心服務(wù)層，并且翻譯來(lái)自核心服務(wù)層的命令請(qǐng)求。EdgeX Foundry提供了消息隊(duì)列遙測(cè)傳輸（MQTT，message queuing telemetry transport）協(xié)議、ModBus串行通信協(xié)議和低功耗藍(lán)牙（BLE，bluetooth low energy）協(xié)議等接入方式。對(duì)于非官方提供的協(xié)議可通過(guò)庫(kù)開(kāi)發(fā)集成此類協(xié)議的微服務(wù)。

（2）核心服務(wù)層：包含負(fù)責(zé)服務(wù)注冊(cè)與發(fā)現(xiàn)的注冊(cè)表配置和注冊(cè)微服務(wù)、采集和存儲(chǔ)南向設(shè)備側(cè)數(shù)據(jù)的核心數(shù)據(jù)微服務(wù)、描述設(shè)備自身能力的元數(shù)據(jù)微服務(wù)和向南向設(shè)備發(fā)送指令的命令微服務(wù)。

圖3 EdgeX Foundry的整體架構(gòu)

Figure 3 The framework of EdgeX Foundry

（3）支持服務(wù)層：提供邊緣分析和智能服務(wù)。目前已安裝了規(guī)則引擎、報(bào)警和通知、規(guī)劃、日志、記錄等微服務(wù)。規(guī)則引擎微服務(wù)允許用戶設(shè)定一些規(guī)則，當(dāng)監(jiān)測(cè)到數(shù)據(jù)達(dá)到規(guī)則要求時(shí)可以觸發(fā)某一特定操作。報(bào)警和通知微服務(wù)可以在緊急情況或服務(wù)故障發(fā)生時(shí)通過(guò)郵件、REST callback回調(diào)等方式告知另一系統(tǒng)或管理員。調(diào)度模塊可以設(shè)置計(jì)時(shí)器以定期清除陳舊數(shù)據(jù)。日志記錄用于記錄EdgeX的運(yùn)行信息。與設(shè)備服務(wù)層的協(xié)議類似，用戶也可以通過(guò)API開(kāi)發(fā)新的功能模塊[16]。

（4）導(dǎo)出服務(wù)層：用于將數(shù)據(jù)傳輸至北向云計(jì)算中心，由客戶端注冊(cè)和分發(fā)等微服務(wù)組件組成。前者使某一特定云端或本地應(yīng)用可以注冊(cè)為核心數(shù)據(jù)模塊中的數(shù)據(jù)接收者，后者將對(duì)應(yīng)數(shù)據(jù)從核心服務(wù)層導(dǎo)出至指定客戶端。

EdgeX數(shù)據(jù)流首先利用設(shè)備服務(wù)層從設(shè)備中收集數(shù)據(jù)，接著傳至核心服務(wù)層做本地持久化，最后由導(dǎo)出服務(wù)層轉(zhuǎn)換、格式化、過(guò)濾之后傳向北側(cè)云端做進(jìn)一步處理。傳至導(dǎo)出服務(wù)層的數(shù)據(jù)亦可在規(guī)則引擎模塊作邊緣分析，再通過(guò)命令模塊向南側(cè)設(shè)備發(fā)出相關(guān)指令。

代碼層面上，EdgeX Foundry的golang版本edgex-go共有cmd、Api、Docker、Internal、pkg、snap、bin這7個(gè)子目錄。cmd文件夾中包含項(xiàng)目程序入口main.go，并描述了調(diào)用的EdgeX微服務(wù)IP和端口等關(guān)鍵信息；Api文件夾包含了整個(gè)框架中每個(gè)微服務(wù)以http形式呈現(xiàn)的Api；Docker文件夾用于構(gòu)建鏡像，文本內(nèi)容是構(gòu)建鏡像所需的指令和說(shuō)明；Internal文件夾負(fù)責(zé)實(shí)現(xiàn)設(shè)備微服務(wù)驅(qū)動(dòng)初始化及對(duì)北向命令請(qǐng)求進(jìn)行處理等功能，pkg是IDE自動(dòng)生成的打包文件，方便應(yīng)用自動(dòng)化部署，snap包含所有基于EdgeX Go的微服務(wù)；bin包含可執(zhí)行的exe文件。

綜上，EdgeX Foundry提供了一個(gè)雙重轉(zhuǎn)換引擎：一是將來(lái)自不同傳感器和設(shè)備、有著不同通信協(xié)議和格式的數(shù)據(jù)統(tǒng)一轉(zhuǎn)換成常見(jiàn)的EdgeX數(shù)據(jù)結(jié)構(gòu)；二是通過(guò)基于TCP/IP的協(xié)議以客戶指定格式向應(yīng)用程序、企業(yè)、云系統(tǒng)提供數(shù)據(jù)[17]。

2.3 CORD

CORD是ONF基金會(huì)使用軟件定義網(wǎng)絡(luò)（SDN，software defined network）、網(wǎng)絡(luò)功能虛擬化（NFV，network functions virtualization）、云計(jì)算等技術(shù)，為網(wǎng)絡(luò)運(yùn)營(yíng)商創(chuàng)建的一個(gè)開(kāi)放的、云原生、可編程的數(shù)據(jù)中心開(kāi)源軟件平臺(tái)。它參考云原生的設(shè)計(jì)原則，借助云計(jì)算的敏捷性和通用硬件的規(guī)模性構(gòu)建更加靈活和經(jīng)濟(jì)的未來(lái)網(wǎng)絡(luò)基礎(chǔ)設(shè)施，并通過(guò)業(yè)務(wù)協(xié)同和編排層實(shí)現(xiàn)應(yīng)用的快速響應(yīng)和靈活部署。

CORD是一個(gè)集成了商用硬件和開(kāi)源軟件的通用平臺(tái)，包括以下4個(gè)面向不同部署場(chǎng)景的解決方案：面向5G移動(dòng)邊緣基站的分布式解決方案M-CORD、面向有線接入家庭用戶的R-CORD、面向城域網(wǎng)和廣域網(wǎng)中企業(yè)用戶的E-CORD和面向性能探測(cè)和度量的A-CORD。CORD體系結(jié)構(gòu)中通用的軟硬件架構(gòu)如圖4所示[18]。

圖4 CORD軟硬件架構(gòu)

Figure 4 The hardware and softwarearchitecture of CORD

CORD的軟件架構(gòu)包含OpenStack、ONOS和XOS 3部分。其中，控制層面的XOS是CORD的Web管理控制臺(tái)，調(diào)用數(shù)據(jù)層面的ONOS和OpenStack提供CORD相關(guān)服務(wù)，負(fù)責(zé)服務(wù)的診斷監(jiān)控、分配資源、性能隔離以及分發(fā)部署和遷移。OpenStack/Kubernetes提供了IaaS（infrastructure as a service）服務(wù)，管理計(jì)算存儲(chǔ)網(wǎng)絡(luò)資源和運(yùn)行虛擬化網(wǎng)絡(luò)功能的虛擬機(jī)和容器，它允許用戶在CORD平臺(tái)上實(shí)現(xiàn)自定義功能。ONOS是控制底層白盒（white box）硬件的網(wǎng)絡(luò)操作系統(tǒng)，同時(shí)為終端用戶提供通信服務(wù)[19]。

CORD硬件主要包括白盒交換機(jī)以及在其基礎(chǔ)上互聯(lián)形成的商用服務(wù)器。白盒交換機(jī)是SDN交換機(jī)的一個(gè)組件，負(fù)責(zé)根據(jù)SDN控制器調(diào)節(jié)數(shù)據(jù)流。商用服務(wù)器提供計(jì)算存儲(chǔ)和網(wǎng)絡(luò)資源，并將網(wǎng)絡(luò)構(gòu)建為葉脊拓?fù)浣Y(jié)構(gòu)以支持橫向網(wǎng)絡(luò)的通信帶寬需求[20]。商用服務(wù)器上部署了包括Kubernetes、OpenStack等在內(nèi)的功能組件，而ONOS則運(yùn)行在白盒交換機(jī)上。

2.4 KubeEdge

云邊協(xié)同邊緣計(jì)算框架KubeEdge是開(kāi)源的云原生生態(tài)圈中第一個(gè)邊緣計(jì)算框架，它由華為設(shè)計(jì)研發(fā)，旨在利用Kubernetes為邊和云之間的網(wǎng)絡(luò)通信、應(yīng)用部署和元數(shù)據(jù)同步提供基礎(chǔ)架構(gòu)支持[21]。用戶既能利用KubeEdge在云上統(tǒng)一管理邊緣節(jié)點(diǎn)上資源受限的應(yīng)用和設(shè)備，又能實(shí)現(xiàn)云邊應(yīng)用和設(shè)備數(shù)據(jù)之間的同步[22]。其整體框架共分為3層，分別是云端、邊緣層和設(shè)備層，如圖5所示。

（1）云端組件

為了兼容Kubernetes生態(tài)，云端組件采用標(biāo)準(zhǔn)的Kubernetes架構(gòu)模式進(jìn)行構(gòu)建，這意味著KubeEdge的云端不負(fù)責(zé)應(yīng)用的調(diào)度、管理，只是將調(diào)度到邊緣節(jié)點(diǎn)的應(yīng)用、設(shè)備元數(shù)據(jù)下發(fā)到邊緣[23]。KubeEdge在云端的核心組件是CloudCore，包含EdgeController、DeviceController和CloudHub 3個(gè)模塊。其中CloudHub是云端通信接口模塊，它實(shí)質(zhì)是Web套接字服務(wù)器，負(fù)責(zé)監(jiān)視云端更改、緩存以及向EdgeHub發(fā)送消息。EdgeController、DeviceController負(fù)責(zé)將應(yīng)用、設(shè)備元數(shù)據(jù)下發(fā)到邊緣，同時(shí)將來(lái)自邊緣的節(jié)點(diǎn)狀態(tài)、應(yīng)用狀態(tài)、設(shè)備狀態(tài)刷新到Kubernetes集群中。

（2）邊緣層

KubeEdge在邊緣層的核心組件是EdgeCore，包含EdgeHub、MetaManager等組件。與CloudHub相對(duì)應(yīng)，EdgeHub是邊緣通信接口模塊，它實(shí)質(zhì)是Web套接字客戶端，負(fù)責(zé)同步云端資源到邊緣以及上報(bào)云端邊緣主機(jī)和設(shè)備的狀態(tài)。MetaManager管理邊緣節(jié)點(diǎn)上的元數(shù)據(jù)，DeviceTwin是處理元數(shù)據(jù)的設(shè)備軟件鏡像。Edged是運(yùn)行在邊緣節(jié)點(diǎn)上的agent程序，管理邊緣容器化應(yīng)用程序。

圖5 KubeEdge框架

Figure 5 The architecture of KubeEdge

（3）設(shè)備層

KubeEdge利用MQTT Broker將設(shè)備狀態(tài)變化同步到邊緣節(jié)點(diǎn)上傳到邊緣節(jié)點(diǎn)再到云端。支持MQTT協(xié)議的設(shè)備可以直接接入KubeEdge。使用專有協(xié)議（非MQTT）的設(shè)備，通過(guò)協(xié)議轉(zhuǎn)換器Mapper將數(shù)據(jù)處理轉(zhuǎn)為MQTT接入KubeEdge。目前KubeEdge針對(duì)工業(yè)設(shè)備場(chǎng)景在DeviceAPI中內(nèi)置了Bluetooth、Modbus、OPC-UA 3種常見(jiàn)通信協(xié)議的設(shè)備支持。

以上介紹的是各模塊的基本功能，下面以邊緣上報(bào)設(shè)備狀態(tài)到云端為例，簡(jiǎn)要說(shuō)明KubeEdge的工作流程：實(shí)時(shí)設(shè)備狀態(tài)信息在依次到達(dá)Mapper、MQTT Broker和EventBus之后，最終到達(dá)Device Twin。此時(shí)KubeEdge將設(shè)備狀態(tài)保存在與Device Twin相連的輕量級(jí)數(shù)據(jù)庫(kù)SQLite中，接著通過(guò)EdgeHub同步狀態(tài)信息到云端組件CloudHub。DeviceController在接收到CloudHub發(fā)送來(lái)的狀態(tài)信息后完成實(shí)時(shí)更新，最后狀態(tài)信息可以通過(guò)Kubernetes API server執(zhí)行Kubernetes中針對(duì)各類資源對(duì)象的增刪改查功能。

代碼層面上，KubeEdge除了CloudCore和EdgeCore部分，還包括橫框云端和邊緣層的部分。① EdgeMesh：基于Istio的橫跨云和邊緣的服務(wù)網(wǎng)格解決方案；②EdgeSite：為滿足在邊緣需要完整集群功能的場(chǎng)景，定制的在邊緣搭建既能管理、編排又能運(yùn)行負(fù)責(zé)的完整集群解決方案[24]。這4個(gè)組件的源碼中都使用了命令行框架cobra，而組件中各個(gè)功能模塊是通過(guò)Beehive統(tǒng)一組織和管理的，因此KubeEdge的代碼相對(duì)而言邏輯清晰、可讀性較強(qiáng)。

KubeEdge充分利用Kubernetes的優(yōu)勢(shì)：良好的擴(kuò)展性、跨越底層基礎(chǔ)設(shè)施提供一致的體驗(yàn)、容器的輕量化和可移植性等，同時(shí)解決了原生Kubernetes在邊緣場(chǎng)景下離線自治的問(wèn)題，并且支持海量異構(gòu)邊緣設(shè)備的接入，因此具有廣闊的發(fā)展前景。

3 比較性研究

在4個(gè)開(kāi)源邊緣平臺(tái)單獨(dú)詳細(xì)介紹的基礎(chǔ)上，本節(jié)著重總結(jié)對(duì)比了上述平臺(tái)在應(yīng)用領(lǐng)域、部署方式等方面的不同，并分析了它們內(nèi)在的聯(lián)系和合作，如表1所示。

（1）應(yīng)用領(lǐng)域

Akraino Edge Stack旨在改善企業(yè)邊緣、OTT邊緣和運(yùn)營(yíng)商邊緣的邊緣云基礎(chǔ)架構(gòu)狀態(tài)，它更專注于將邊緣服務(wù)引入電信和網(wǎng)絡(luò)系統(tǒng)。Akraino的所有藍(lán)圖都來(lái)自實(shí)際的商業(yè)需求，涵蓋了電信、5G、虛擬無(wú)線接入網(wǎng)（vRAN，virtual radio access network）、工業(yè)物聯(lián)網(wǎng)（IIoT，industrial internet of things）等廣泛的應(yīng)用場(chǎng)景。

EdgeX Foundry收集和分析來(lái)自傳感器、設(shè)備或其他物聯(lián)網(wǎng)器件的數(shù)據(jù)，并將它們導(dǎo)出至邊緣計(jì)算應(yīng)用或云計(jì)算中心作處理，保障了各類異構(gòu)設(shè)備接口與應(yīng)用程序之間的互操作性，因此是統(tǒng)一物聯(lián)網(wǎng)邊緣計(jì)算平臺(tái)的一大利器。

CORD核心是通過(guò)軟硬件解耦、控制與轉(zhuǎn)發(fā)分離等技術(shù)，將傳統(tǒng)運(yùn)營(yíng)商網(wǎng)絡(luò)轉(zhuǎn)變成類似于云服務(wù)商的數(shù)據(jù)中心，從而達(dá)到降低網(wǎng)絡(luò)成本、提升網(wǎng)絡(luò)效益的目標(biāo)。目前CORD已將R-CORD、M-CORD、E-CORD三者打造成統(tǒng)一的通用平臺(tái)，向多邊緣接入演進(jìn)。

KubeEdge作為全球首個(gè)Kubernetes原生的開(kāi)源邊緣計(jì)算平臺(tái)，依托Kubernetes的容器編排和調(diào)度能力管理用戶的邊緣節(jié)點(diǎn)，提供將云上應(yīng)用延伸到邊緣的能力，聯(lián)動(dòng)邊緣層和云端的數(shù)據(jù)，滿足客戶對(duì)邊緣計(jì)算資源的遠(yuǎn)程管控、數(shù)據(jù)處理、分析決策、智能化的訴求。同時(shí)，在云端提供統(tǒng)一的設(shè)備或應(yīng)用監(jiān)控、日志采集等運(yùn)維能力，為企業(yè)提供完整的邊云協(xié)同一體化服務(wù)的邊緣計(jì)算解決方案[25]。目前KubeEdge最典型的商業(yè)應(yīng)用是攝像頭類場(chǎng)景，如園區(qū)人臉識(shí)別、車牌識(shí)別等。

表1 開(kāi)源平臺(tái)特性比較

（2）部署方式

邊緣計(jì)算平臺(tái)普遍依賴虛擬機(jī)和容器這兩種虛擬化技術(shù)。虛擬機(jī)隔離度高，適合重量級(jí)應(yīng)用或?qū)Π踩杂袠O高要求的應(yīng)用，但可能會(huì)帶來(lái)資源的重復(fù)使用、啟動(dòng)極慢等問(wèn)題。而容器的輕量級(jí)意味著任意數(shù)量的微服務(wù)可以快速打包并部署到邊緣計(jì)算平臺(tái)上，并且容器的API支持生命周期管理[26]。

Akraino Edge Stack支持在通用架構(gòu)中運(yùn)行的基于虛擬機(jī)（VM）或容器化的應(yīng)用，并利用Operator Framework對(duì)這些應(yīng)用程序進(jìn)行生命周期管理。Kubernetes Machine API允許用戶在任意地點(diǎn)部署邊緣應(yīng)用。例如，針對(duì)容器部署vRAN和MEC的應(yīng)用場(chǎng)景的Provider Access Edge藍(lán)圖，使用Kubernetes提供的插件對(duì)虛擬機(jī)和容器進(jìn)行集中管理[27]。

在EdgeX Foundry中，所有的微服務(wù)都以各類編程語(yǔ)言寫進(jìn)輕量級(jí)容器中，微程序之間彼此隔離保障了整個(gè)EdgeX Foundry的可伸縮性[28]。用戶可以在路由器、網(wǎng)關(guān)、交換機(jī)等邊緣設(shè)備中動(dòng)態(tài)增減微服務(wù)，運(yùn)行自定義的邊緣應(yīng)用。

CORD可以通過(guò)物理部署和虛擬化部署兩種方式實(shí)現(xiàn)[29]。在物理部署方案中，CORD集成了相關(guān)的開(kāi)源組件（無(wú)線電和光接入網(wǎng)、具有可編程轉(zhuǎn)發(fā)平面的白盒交換機(jī)、微服務(wù)基礎(chǔ)設(shè)施和端到端服務(wù)網(wǎng)格），打包成易于配置、部署和運(yùn)行的獨(dú)立PoD，配合若干物理服務(wù)器和交換機(jī)實(shí)現(xiàn)物理部署。在虛擬化部署方案中，PoD又稱為CiaB （CORD-in-a-box），服務(wù)器和交換機(jī)通常以虛擬機(jī)和Open vSwitch（OvS）的方式運(yùn)行在單個(gè)物理主機(jī)中。

KubeEdge的基本運(yùn)行環(huán)境要求：一個(gè)運(yùn)行了Kubernetes控制面的云端節(jié)點(diǎn)和一個(gè)可以運(yùn)行EdgeCore的邊緣節(jié)點(diǎn)（256 MB內(nèi)存即可）。云端部署完Kubernetes的控制面后，將CloudCore以容器的方式部署在云端，將EdgeCore以進(jìn)程的方式部署到邊緣層即可。用戶可以直接通過(guò)Kubernetes中的kubectl命令行在云端管理邊緣節(jié)點(diǎn)、設(shè)備和應(yīng)用。

（3）內(nèi)在聯(lián)系和區(qū)別

Akraino Edge Stack和EdgeX Foundry在IIoT領(lǐng)域的解決方案是互補(bǔ)的，用戶可以獲取EdgeX代碼并創(chuàng)建一個(gè)藍(lán)圖作為端到端堆棧保存在Akraino Edge Stack中。EdgeX專注于網(wǎng)關(guān)、傳感器等物聯(lián)網(wǎng)設(shè)備間的通信，而Akraino側(cè)重于云連接。因此，增強(qiáng)EdgeX應(yīng)用層上API與Akraino邊緣基礎(chǔ)設(shè)施相關(guān)的API之間的上下文感知，可以讓基礎(chǔ)架構(gòu)感知上下文變化動(dòng)態(tài)優(yōu)化自身，以滿足任意可兼容EdgeX的微服務(wù)的需求。

Akraino和CORD之間存在緊密合作。例如，可以在承載網(wǎng)邊緣支撐大量虛擬化訪問(wèn)技術(shù)的Akraino藍(lán)圖SEBA，它是基于R-CORD變體的一個(gè)輕量級(jí)平臺(tái)，支持用戶訪問(wèn)及無(wú)線回傳，確保流量可以通過(guò)快速通道直接進(jìn)入骨干網(wǎng)[30]。

此外，KubeEdge作為Akraino上游社區(qū)中的一個(gè)開(kāi)源堆棧，參與了Akraino多個(gè)藍(lán)圖的設(shè)計(jì)。例如，在KubeEdge Edge Service藍(lán)圖中，借助KubeEdge，應(yīng)用程序供應(yīng)商可以在邊緣推動(dòng)各種應(yīng)用程序。相比于EdgeX Foundry偏重端側(cè)設(shè)備的管理，KubeEdge還具有云邊協(xié)同等智能邊緣系統(tǒng)的能力。

4 典型應(yīng)用

5G背景下的服務(wù)場(chǎng)景對(duì)網(wǎng)絡(luò)的時(shí)延、帶寬、計(jì)算和存儲(chǔ)等方面提出了很高的要求。本節(jié)著重分析兩個(gè)經(jīng)典案例，并分別介紹了Akraino和KubeEdge在這些場(chǎng)景中的應(yīng)用價(jià)值。

4.1 Akraino在車聯(lián)網(wǎng)中的應(yīng)用

在萬(wàn)物互聯(lián)的背景下，車聯(lián)網(wǎng)領(lǐng)域內(nèi)激增的感知信息數(shù)據(jù)給核心網(wǎng)帶來(lái)了巨大壓力，同時(shí)實(shí)際視頻傳輸也會(huì)受到時(shí)變信道狀態(tài)的影響。針對(duì)上述問(wèn)題，利用Akraino的CVB（connected vehicle blueprint）藍(lán)圖在道路邊緣側(cè)實(shí)時(shí)處理地圖、交通、車輛信息業(yè)務(wù)，可以在回程帶寬受限的條件下，實(shí)時(shí)地為車輛提供事故預(yù)警、輔助駕駛等服務(wù)。

5G場(chǎng)景下基于Akraino的車聯(lián)網(wǎng)路障監(jiān)測(cè)工作流程如圖6所示。首先探頭獲取到路況信息，并將相關(guān)數(shù)據(jù)及時(shí)發(fā)送到相關(guān)的MEC平臺(tái)（注意分發(fā)策略可以自行配置），隨后在邊緣層和云端進(jìn)行智能分析和決策，最后將操作指令反饋給車輛。其中，位于MEC平臺(tái)的CVB藍(lán)圖共分為4層，從下到上的分布如下。①硬件層：支持Arm和x86框架；②IaaS層：支持虛擬機(jī)、容器及其他IaaS主流軟件如OpenStack、Kubernetes等；③PaaS層：Tars是CVB藍(lán)圖的微服務(wù)框架，它可以提供高性能的RPC調(diào)用，在大規(guī)模場(chǎng)景下高效部署微服務(wù)；④SaaS層：運(yùn)行最新V2X應(yīng)用程序。

圖6 基于Akraino的車聯(lián)網(wǎng)路障監(jiān)測(cè)流程

Figure 6 The process of roadblock monitoring in internet of vehicles based on Akraino

為減少硬件資源成本，官方提供了如下CVB藍(lán)圖部署方式[31]：在AWS（Amazon web service）上創(chuàng)建3臺(tái)CPU為8核，內(nèi)存為16 GB的虛擬機(jī)服務(wù)器，分別用來(lái)部署持續(xù)集成工具Jenkins、Tars Master節(jié)點(diǎn)、Tars Slave節(jié)點(diǎn)和車聯(lián)網(wǎng)相關(guān)應(yīng)用。用戶可先在AWS（騰訊云亦可）上申請(qǐng)創(chuàng)建3個(gè)新實(shí)例，依次配置Jenkins、Tarsframework、Jenkins slave以及Tars微服務(wù)框架相連的Tars節(jié)點(diǎn)。最后構(gòu)建CI jobs持續(xù)、自動(dòng)地測(cè)試CVB藍(lán)圖。

CVB藍(lán)圖已實(shí)現(xiàn)如下功能[32]。

精準(zhǔn)定位：定位準(zhǔn)確率比現(xiàn)在的GPS系統(tǒng)定位高出10倍。GPS系統(tǒng)的定位精準(zhǔn)范圍為5～10 m，但CVB藍(lán)圖可以把這個(gè)范圍縮至不到1 m。

便捷導(dǎo)航：實(shí)現(xiàn)實(shí)時(shí)路況信息更新，為司機(jī)提供最高效的路徑。

減少違規(guī)：CVB藍(lán)圖可以讓駕駛員了解某些特定區(qū)域的交通規(guī)則，如在狹窄街道前更改路線等。

4.2 KubeEdge在AI識(shí)別中的應(yīng)用

隨著5G通信的進(jìn)一步推廣，網(wǎng)絡(luò)邊緣的設(shè)備數(shù)量、產(chǎn)生的數(shù)據(jù)爆發(fā)式增長(zhǎng)使集中式的數(shù)據(jù)中心面臨著實(shí)時(shí)性、帶寬、能耗和數(shù)據(jù)隱私的挑戰(zhàn)，越來(lái)越多的場(chǎng)景需要應(yīng)用邊緣計(jì)算。KubeEdge作為一種云原生邊緣計(jì)算解決方案，為應(yīng)用從云端向云邊端的遷移提供了很好的解決思路。

圖7展示了一個(gè)汽車保養(yǎng)門店車位績(jī)效AI識(shí)別的應(yīng)用案例[33]。在該案例中，每個(gè)門店的多個(gè)車位均需記錄車輛維護(hù)數(shù)量、時(shí)長(zhǎng)，以評(píng)估每個(gè)工位、每個(gè)門店的業(yè)務(wù)績(jī)效。

部署上，KubeEdge 中CloudCore可作為應(yīng)用管理和業(yè)務(wù)運(yùn)營(yíng)平臺(tái)部署在云端，此外云端還需配置編譯環(huán)境Golang、集群管理工具Kubernetes和封裝工具Docker。每個(gè)線下門店作為一個(gè)邊緣側(cè)節(jié)點(diǎn)，只需額外配置一臺(tái)arm服務(wù)器，與云端類似，除了基礎(chǔ)配置（如Docker），在其上安裝KubeEdge邊緣核心模塊EdgeCore和負(fù)責(zé)與終端設(shè)備通信的Mosquitto，即可將其加入云端的集群進(jìn)行統(tǒng)一管理。用戶同樣可在邊緣arm服務(wù)器上部署AI計(jì)算類應(yīng)用，實(shí)現(xiàn)高效識(shí)別。

圖7 基于KubeEdge的AI識(shí)別

相比傳統(tǒng)做法中額外購(gòu)置智能攝像頭或者使用云識(shí)別服務(wù)，利用KubeEdge可以繼續(xù)采用原有系統(tǒng)的IP攝像頭抓取車輛進(jìn)出的照片，實(shí)時(shí)識(shí)別車輛信息、計(jì)算車輛停留保養(yǎng)時(shí)間。最后匯總報(bào)表推送至云端的運(yùn)營(yíng)中心，實(shí)現(xiàn)門店的業(yè)績(jī)效率統(tǒng)計(jì)、KPI考核以及門店所在地域的汽車維修熱點(diǎn)統(tǒng)計(jì)分析。

除了減少運(yùn)營(yíng)成本，KubeEdge還有助于提高識(shí)別效率。借助KubeEdge，單張圖片識(shí)別時(shí)間不超過(guò)50 ms，且在網(wǎng)絡(luò)質(zhì)量不佳時(shí)可以離線使用。同時(shí)，配合IoT感知技術(shù)，可以實(shí)時(shí)監(jiān)控輪胎等可燃物料存儲(chǔ)區(qū)域的溫度狀態(tài)，如果店面出現(xiàn)明火及煙霧時(shí)，及時(shí)推送報(bào)警短視頻到門店管理人員及運(yùn)營(yíng)平臺(tái)，達(dá)到自動(dòng)報(bào)警的目的。

5 問(wèn)題和挑戰(zhàn)

為了充分發(fā)揮邊緣計(jì)算平臺(tái)的優(yōu)勢(shì)，還有一些潛在的開(kāi)放性研究問(wèn)題與挑戰(zhàn)需要進(jìn)一步探討，總結(jié)如下。

1) 目前市面上的邊緣計(jì)算平臺(tái)的面向范圍包括物聯(lián)網(wǎng)端、網(wǎng)絡(luò)運(yùn)營(yíng)商、云邊融合等，如何提高平臺(tái)之間合作的安全性是值得思考的問(wèn)題。例如，當(dāng)數(shù)據(jù)從一個(gè)平臺(tái)遷移到另一個(gè)平臺(tái)時(shí)，應(yīng)采用何種數(shù)據(jù)遷移算法保證數(shù)據(jù)完整性[34]。此外，改進(jìn)接口設(shè)計(jì)、提高多平臺(tái)之間的互操作性也需要進(jìn)一步研究。

2) 邊緣設(shè)備之間的通信有時(shí)難免會(huì)涉及用戶位置等個(gè)人信息，如何加強(qiáng)對(duì)用戶的隱私保護(hù)，避免數(shù)據(jù)惡意泄露還需進(jìn)一步研究。區(qū)塊鏈技術(shù)作為一種限制未授權(quán)訪問(wèn)、防止數(shù)據(jù)被篡改的新興技術(shù)，可以為數(shù)據(jù)安全性提供一定的解決思路。

3) 邊緣計(jì)算平臺(tái)的生命周期安全管理涉及平臺(tái)開(kāi)發(fā)方、平臺(tái)運(yùn)營(yíng)方、應(yīng)用開(kāi)發(fā)者、軟硬件組件供應(yīng)商等多方，任何一環(huán)出現(xiàn)安全問(wèn)題都將影響整個(gè)系統(tǒng)的正常運(yùn)轉(zhuǎn)。在邊緣計(jì)算平臺(tái)的全生命周期管理中設(shè)立關(guān)鍵檢查點(diǎn)，通過(guò)安全開(kāi)發(fā)管理、代碼審計(jì)、脆弱性評(píng)估、滲透測(cè)試、安全運(yùn)維和事件響應(yīng)與恢復(fù)等安全措施可以保障平臺(tái)的順利運(yùn)行[35]。

4) 邊緣計(jì)算平臺(tái)同標(biāo)準(zhǔn)化組織之間的合作有待加強(qiáng)。作為邊緣計(jì)算標(biāo)準(zhǔn)化的先行者，ETSI雖然在全球范圍內(nèi)最先給出邊緣計(jì)算參考架構(gòu)，但產(chǎn)業(yè)內(nèi)對(duì)于標(biāo)準(zhǔn)的落實(shí)情況卻極為不佳。雖然一些設(shè)備廠商、互聯(lián)網(wǎng)企業(yè)參考了部分ETSI提出的邊緣計(jì)算框架，但大多接口和平臺(tái)建設(shè)均由企業(yè)自行定義，離標(biāo)準(zhǔn)中所希望達(dá)到的平臺(tái)互通和解耦開(kāi)放等愿景尚有距離。各邊緣計(jì)算平臺(tái)的功能模塊與ETSI參考架構(gòu)的功能實(shí)體之間的映射關(guān)系、如何在現(xiàn)有的邊緣計(jì)算平臺(tái)中使用ETSI MEC標(biāo)準(zhǔn)規(guī)定的API接口等，這些都是后期構(gòu)建一個(gè)標(biāo)準(zhǔn)化邊緣開(kāi)放環(huán)境需要關(guān)注的方向。

6 結(jié)束語(yǔ)

本文主要從研究背景、平臺(tái)架構(gòu)、應(yīng)用場(chǎng)景以及存在的問(wèn)題和挑戰(zhàn)等方面對(duì)邊緣計(jì)算平臺(tái)進(jìn)行了系統(tǒng)性介紹。首先介紹了邊緣計(jì)算的基本概念和本文研究的背景；然后，對(duì)幾個(gè)典型邊緣計(jì)算平臺(tái)做了細(xì)節(jié)的闡述，并從應(yīng)用領(lǐng)域、部署方式、聯(lián)系和區(qū)別這3個(gè)角度比較了它們之間的異同點(diǎn)；隨后，詳細(xì)介紹了以Akraino和KubeEdge為代表的應(yīng)用案例；最后，對(duì)邊緣計(jì)算平臺(tái)中幾個(gè)值得研究的方向做了進(jìn)一步歸納。

[1] YOUSEFPOUR A, FUNG C, NGUYEN T, et al. All one needs to know about fog computing and related edge computing paradigms: A complete survey[J]. Journal of Systems Architecture, 2019, 98: 289-330.

[2] 張星洲, 魯思迪, 施巍松. 邊緣智能中的協(xié)同計(jì)算技術(shù)研究[J]. 人工智能, 2019 (5): 7.

ZHANG X Z, LU S D, SHI W S. Research on collaborative computing technology in edge intelligence[J]. Artificial Intelligence, 2019 (5): 7.

[3] Akraino Edge Stack[EB]. 2020.

[4] SATYANARAYANAN M, BAHL P, RAMóN C, et al. The case for VM-based cloudlets in mobile computing[J]. Pervasive Computing IEEE, 2009, 8(4): 14-23.

[5] DINH H T, LEE C, NIYATO D, et al. A survey of mobile cloud computing: architecture, applications, and approaches[J]. Wireless Communications and Mobile Computing, 2013, 13(18): 1587-1611.

[6] MACH P, BECVAR Z. Mobile edge computing: a survey on architecture and computation offloading[J]. IEEE Communications Surveys & Tutorials, 2017, 19(3): 1628-1656.

[7] DOLUI K, DATTA S K. Comparison of edge computing implementations: fog computing, cloudlet and mobile edge computing[C]//2017 Global Internet of Things Summit (GIoTS). 2017: 1-6.

[8] 張建敏, 楊峰義, 武洲云, 等. 多接入邊緣計(jì)算及關(guān)鍵技術(shù)[M]. 北京: 人民郵電出版社, 2019.

ZHANG J M, YANG F Y, WU Z Y, et al. Multi-access edge computing and key technologies[M]. Beijing: Posts and TeleCommunications Press, 2019.

[9] What edge computing means for infrastructure and operations leaders[EB]. 2020.

[10] Four edge computing market predictions[EB].2020.

[11] WANG X, HAN Y, LEUNG V C M, et al. Convergence of edge computing and deep learning: A comprehensive survey[J]. IEEE Communications Surveys & Tutorials, 2020, 22(2): 869-904.

[12] ZHAO Y, WANG W, LI Y, et al. Edge computing and networking: a survey on infrastructures and applications[J]. IEEE Access, 2019, 7: 101213-101230.

[13] SABELLA D, REZNIK A, FRAZAO R. Multi-access edge computing in action[M]. CRC Press, 2019.

[14] Personalized intrusion detection for internet of things gateway[EB]. 2020.

[15] LIU F, TANG G, LI Y, et al. A survey on edge computing systems and tools[J]. Proceedings of the IEEE, 2019, 107(8): 1537-1562.

[16] ANTONINI M, VECCHIO M, ANTONELLI F. Fog computing architectures: a reference for practitioners[J]. IEEE Internet of Things Magazine, 2019, 2(3): 19-25.

[17] EdgeX Foundry homepage[EB]. 2020.

[18] WANG A, ZHA Z, GUO Y, et al. Software-defined networking enhanced edge computing: a network-centric survey[J]. Proceedings of the IEEE, 2019, 107(8): 1500-1519.

[19] HONG J, KIM W, YOO J H, et al. Design and implementation of container-based M-CORD monitoring system[C]//20th Asia- Pacific Network Operations and Management Symposium (APNOMS). 2019: 1-4.

[20] 梁家越, 劉斌, 劉芳. 邊緣計(jì)算開(kāi)源平臺(tái)現(xiàn)狀分析[J]. 中興通訊技術(shù), 2019(3):8-14.

LIANG J Y, LIU B, LIU F. The present situation of open source platforms for edge computing [J]. ZTE Technology Journal, 2019(3): 8-14.

[21] KubeEdge hompage[EB]. 2020.

[22] TAO Z, XIA Q, HAO Z, et al. A survey of virtual machine management in edge computing[J]. Proceedings of the IEEE, 2019, 107(8): 1482-1499.

[23] 張琦, 賈玄, 張森, 等. 云原生邊緣計(jì)算架構(gòu)分析[J]. 電信科學(xué), 2019, 35(S2): 98-109.

ZHANG Q, JIA X, ZHANG S, et al. Analysis of cloud native edge computing architecture[J]. Telecommunications Science, 2019, 35(S2): 98-109.

[24] KubeEdge源碼分析系列之整體架構(gòu)[EB]. 2020.

KubeEdge source code analysis: overall architecture[EB]. 2020.

[25] 智能邊緣平臺(tái)IEF[EB]. 2020.

Intelligent edge platform IEF[EB]. 2020.

[26] TALEB T, SAMDANIS K, MADA B, et al. On multi-access edge computing: a survey of the emerging 5G network edge cloud architecture and orchestration[J]. IEEE Communications Surveys & Tutorials, 2017, 19(3): 1657-1681.

[27] Kubernetes native infrastructure provider access edge[EB]. 2020.

[28] XU R, JIN W, KIM D. Microservice security agent based on API gateway in edge computing[J]. Sensors, 2019, 19(22): 4905.

[29] CANELLAS F, BONJORN N, KENTIS A M, et al. Build-ship-run approach for a CORD-in-a-Box deployment[C]//9th International Conference on Cloud Computing and Services Science. IEEE, 2019.

[30] SEBA Homepage[EB]. 2020.

[31] CVB Installation Doc forR2[EB]. 2020.

[32] BRUCE L, ROBERT Q, HECHUN Z, et al. An Akraino developer use case[EB]. 2020.

[33] 智能計(jì)算、邊緣計(jì)算環(huán)境下的云原生進(jìn)化之路[EB]. 2020.

Cloud-native evolution path under intelligent computing and edge computing environment [EB]. 2020.

[34] NING H, LI Y, SHI F, et al. Heterogeneous edge computing open platforms and tools for internet of things[J]. Future Generation Computer Systems, 2020, 106: 67-76.

[35] 陶耀東, 徐偉, 紀(jì)勝龍. 邊緣計(jì)算安全綜述與展望[J]. 計(jì)算機(jī)集成制造系統(tǒng), 2019, 25(12): 3043-3051.

TAO Y D, XU W, JI S L. Summary and prospect of edge computing security [J]. Computer Integrated Manufacturing Systems, 2019, 25 (12): 3043-3051.

Survey on open source edge computing platforms

GU Dier1, LU Hua2, XIE Renchao1,3, HUANG Tao1,3

1. State Key Laboratory of Networking and Switching Technology, Beijing University of Posts and Telecommunications, Beijing 100876, China 2.Guangdong Communications & Networks Institute, Guangzhou 510700, China 3. Purple Mountain Laboratories, Nanjing 211111, China

Firstly, the basic concept of edge computing (EC) and its current state of research were introduced. Moreover, the design requirements of edge computing platforms from multiple perspectives were discussed. Then, four typical open source platforms were presented in detail, and their similarities and differences in terms of application areas, deployment methods were analyzed. Later, with regard to two typical use cases, their installations and advantages were summarized and analyzed. Finally, key challenges such as the cooperation among edge computing platforms, security and standardization were discussed.

edge computing, open source platforms, comparative study, use case

TP393

A

10.11959/j.issn.2096?109x.2021020

2020?06?02；

2020?10?03

盧華，luhua@gdcni.cn

國(guó)家重點(diǎn)研發(fā)計(jì)劃基金（2019YFB1804403）

The National Key R&D Program of China (2019YFB1804403)

顧笛兒, 盧華, 謝人超, 等. 邊緣計(jì)算開(kāi)源平臺(tái)綜述[J]. 網(wǎng)絡(luò)與信息安全學(xué)報(bào), 2021, 7(2): 22-34.

GU D E, LU H, XIE R C, et al. Survey on open source edge computing platforms[J]. Chinese Journal of Network and Information Security, 2021, 7(2): 22-34.

顧笛兒（1996? ），女，江蘇鹽城人，北京郵電大學(xué)碩士生，主要研究方向?yàn)檫吘売?jì)算等。

盧華（1976? ），男，江蘇南京人，廣東省新一代通信與網(wǎng)絡(luò)創(chuàng)新研究院副研究員，主要研究方向?yàn)樾滦途W(wǎng)絡(luò)架構(gòu)體系、軟件定義網(wǎng)絡(luò)、P4可編程、虛擬化等。

謝人超（1984? ），男，福建南平人，博士，北京郵電大學(xué)副教授，主要研究方向?yàn)樾畔⒅行木W(wǎng)絡(luò)、移動(dòng)網(wǎng)絡(luò)內(nèi)容分發(fā)技術(shù)、工業(yè)互聯(lián)網(wǎng)、標(biāo)識(shí)解析技術(shù)和移動(dòng)邊緣計(jì)算等。

黃韜（1980? ），男，重慶人，博士，北京郵電大學(xué)教授、博士生導(dǎo)師，主要研究方向?yàn)槁酚膳c交換、軟件定義網(wǎng)絡(luò)、內(nèi)容分發(fā)網(wǎng)絡(luò)等。