本文首發(fā)于《物聯(lián)網(wǎng)學(xué)報(bào)》2021年3月第5卷第1期,，邊緣計(jì)算社區(qū)經(jīng)過(guò)物聯(lián)網(wǎng)學(xué)報(bào)授權(quán)，發(fā)布本文,。

本文是國(guó)家自然科學(xué)基金資助項(xiàng)目（No.61772480，No.61972171）,；之江實(shí)驗(yàn)室開放課題（No.2021KE0AB02）,。

本文作者：曾德澤，陳律昊,，顧琳,，李躍鵬．

以下為正文，總共14600多字,，預(yù)計(jì)閱讀36分鐘,，建議收藏保存！

摘 要：云原生計(jì)算基于低開銷容器化的運(yùn)行方式非常契合邊緣計(jì)算,，因此,，提出將云原生技術(shù)應(yīng)用于邊緣計(jì)算， 發(fā)揮云原生的優(yōu)勢(shì),，使資源管控對(duì)應(yīng)用開發(fā)部署透明化,。考慮相較于云計(jì)算,，邊緣計(jì)算具有資源廣分布,、高異構(gòu)、 多碎片特征,，亟需算網(wǎng)協(xié)同的資源管控,。根據(jù)云原生相關(guān)技術(shù)的發(fā)展現(xiàn)狀，整合軟件定義網(wǎng)絡(luò)與網(wǎng)絡(luò)功能虛擬化等未來(lái)網(wǎng)絡(luò)技術(shù),，提出全棧式云原生邊緣計(jì)算架構(gòu),。在此基礎(chǔ)上，考慮容器的層次化特性,，提出適用于有限邊緣計(jì)算資源的低開銷容器部署方法,，分析探討云原生邊緣計(jì)算所面臨的挑戰(zhàn),。

關(guān)鍵詞：云原生；邊緣計(jì)算,；容器,；微服務(wù)

1 引 言

為了應(yīng)對(duì)海量終端快速增長(zhǎng)的高算力需求，通過(guò)計(jì)算卸載等方法利用云計(jì)算的海量計(jì)算資源被廣泛認(rèn)可,。但“端－云”間高時(shí)延難以滿足諸多實(shí)時(shí)應(yīng)用的低時(shí)延要求,，邊緣計(jì)算概念應(yīng)運(yùn)而生。邊緣計(jì)算通過(guò)將計(jì)算需求轉(zhuǎn)移至靠近用戶的一側(cè),，利用網(wǎng)絡(luò)邊緣的計(jì)算資源承載云計(jì)算服務(wù),，利用“數(shù)據(jù)上行、計(jì)算下行”的方式,，突破了“終端＋數(shù)據(jù)中心”兩級(jí)架構(gòu)的局限性,，可以滿足應(yīng)用對(duì)時(shí)延與帶寬的需求[1-3]。

邊緣計(jì)算利用其獨(dú)特的地理位置優(yōu)勢(shì)以低時(shí)延,、高帶寬的方式提供信息技術(shù)服務(wù)環(huán)境和云計(jì)算能力,，被視為物聯(lián)網(wǎng)、5G,、大數(shù)據(jù),、人工智能等領(lǐng)域的關(guān)鍵支撐技術(shù)之一，共同促進(jìn)著工業(yè)互聯(lián)網(wǎng),、車載網(wǎng)絡(luò),、智能駕駛、虛擬現(xiàn)實(shí)/增強(qiáng)現(xiàn)實(shí)（VR/AR,virtual reality/augmented reality）,、智慧醫(yī)療等行業(yè)產(chǎn)業(yè)的變革[4-5],。特別是隨著6G被提上日程，利用邊緣計(jì)算發(fā)展邊－端融合系統(tǒng),，通過(guò)算網(wǎng)融合調(diào)度優(yōu)化來(lái)發(fā)揮6G的超低時(shí)延優(yōu)勢(shì),，被視為未來(lái)計(jì)算的新興發(fā)展趨勢(shì)[6]。計(jì)算優(yōu)先網(wǎng)絡(luò)[7],、算力網(wǎng)絡(luò)[8]、多接入邊緣計(jì)算[9]等邊緣計(jì)算相關(guān)概念與技術(shù),，說(shuō)明了邊緣計(jì)算在未來(lái)網(wǎng)絡(luò)與計(jì)算中的重要性,，引發(fā)了各行各業(yè)的廣泛關(guān)注,。

從產(chǎn)業(yè)現(xiàn)狀看,，阻礙邊緣計(jì)算發(fā)展的主要因素之一是邊緣服務(wù)的開發(fā)、管控以及邊緣應(yīng)用生態(tài)的構(gòu)建,。盡管邊緣計(jì)算資源管理與任務(wù)調(diào)度優(yōu)化已經(jīng)得到廣泛研究和關(guān)注[9-10]，截至目前,，業(yè)界尚未有一套統(tǒng)一標(biāo)準(zhǔn)的資源管理與任務(wù)管理框架,。

盡管邊緣計(jì)算與云計(jì)算具有高度的相似性，但由于其資源異構(gòu),、設(shè)備分布廣、資源碎片等特點(diǎn),，傳統(tǒng)云計(jì)算解決方案（如OpenStack）在應(yīng)用于邊緣計(jì)算過(guò)程中存在諸多不適與局限,，包括：

1)復(fù)雜性,，邊緣設(shè)備能力差異大,、網(wǎng)絡(luò)接入方式多、類型多樣的終端設(shè)備和服務(wù)需求的不同導(dǎo)致復(fù)雜性大,；

2)難預(yù)測(cè)性,，終端設(shè)備的移動(dòng)性和隨時(shí)間變化的任務(wù)需求使得難以預(yù)測(cè)；

3) 不確定性,，邊緣設(shè)備的資源異構(gòu)性和任務(wù)負(fù)載的動(dòng)態(tài)變化造成服務(wù)需求的不確定性,；

4) 高動(dòng)態(tài)性，云數(shù)據(jù)中心內(nèi)在的數(shù)據(jù)和服務(wù)按需下行需求造成高動(dòng)態(tài)性,。

通過(guò)上述分析表明,，打造邊緣計(jì)算平臺(tái)的“操作系統(tǒng)”勢(shì)在必行。

盡管存在差異,，云計(jì)算的發(fā)展歷程仍為邊緣計(jì)算提供了參考與借鑒,，諸多解決方案已嘗試將云計(jì)算相關(guān)框架與技術(shù)遷移至邊緣計(jì)算，并根據(jù)邊緣計(jì)算特點(diǎn)進(jìn)行定制改進(jìn),，如針對(duì)邊緣計(jì)算資源廣分布的特征對(duì)OpenStack 進(jìn)行定制化改進(jìn)[11],。近年來(lái),，云原生正逐漸成為云計(jì)算的發(fā)展主流。以Kubernetes為代表的云原生編排系統(tǒng),，被廣泛認(rèn)為將成為分布式系統(tǒng)的核心操作系統(tǒng),。云原生通過(guò)容器化、微服務(wù)化,、松耦合化服務(wù),，實(shí)現(xiàn)基于服務(wù)的快速按需應(yīng)用編排構(gòu)建，滿足快速迭代的需求驅(qū)動(dòng)應(yīng)用開發(fā)模式,，成為軟件開發(fā)的主導(dǎo)力量[12],。

邊緣計(jì)算作為云計(jì)算的拓展，也可有類似的發(fā)展思路,。硬件低耦合的輕量級(jí)云原生支撐技術(shù)（如容器）較契合邊緣計(jì)算的資源特征,，容器（如Docker）能夠輕量級(jí)地實(shí)現(xiàn)多個(gè)用戶之間的隔離,，進(jìn)而實(shí)現(xiàn)資源的彈性伸縮管理以及應(yīng)用的注冊(cè),、發(fā)現(xiàn),、編排、發(fā)布,，提升應(yīng)用開發(fā)運(yùn)行效率,。此外，相較于云計(jì)算,，邊緣計(jì)算的異構(gòu)性更高,，其資源形態(tài)多樣、網(wǎng)絡(luò)接入多樣,、訪問(wèn)特征多樣,，由應(yīng)用開發(fā)運(yùn)行維護(hù)人員直接管理物理資源，挑戰(zhàn)大,、效率低,。

因此,，通過(guò)容器抽象資源,，讓資源管控對(duì)應(yīng)用開發(fā)運(yùn)行維護(hù)人員透明，具有十分重要的意義,，將云原生應(yīng)用拓展至邊緣計(jì)算平臺(tái),，已經(jīng)得到了學(xué)術(shù)界和業(yè)界的認(rèn)可?，F(xiàn)在已有一些針對(duì)邊緣環(huán)境的解決方案，如Kubernetes的簡(jiǎn)化版K3s和華為技術(shù)有限公司于2018年發(fā)布的Kubernetes原生邊緣計(jì)算平臺(tái)KubeEdge等框架,，迅速得到了業(yè)界的廣泛認(rèn)可,。

云原生邊緣計(jì)算通過(guò)容器等支撐技術(shù)實(shí)現(xiàn)了底層物理計(jì)算資源的抽象與軟化，解耦軟件開發(fā)運(yùn)行維護(hù)與底層資源管控,。事實(shí)上,，除了計(jì)算資源以外，網(wǎng)絡(luò)資源管控也是邊緣計(jì)算需要考慮的另一個(gè)重要方面,。相較于云計(jì)算,，邊緣計(jì)算網(wǎng)絡(luò)異構(gòu)性更強(qiáng)，表現(xiàn)在接入方式（有線與無(wú)線并存）異構(gòu),、帶寬異構(gòu),、可靠性異構(gòu)等多個(gè)方面。同時(shí),，邊緣計(jì)算具有非規(guī)則的網(wǎng)絡(luò)拓?fù)?。邊緣?jì)算是移動(dòng)互聯(lián)網(wǎng)的重要支撐，移動(dòng)互聯(lián)網(wǎng)的蓬勃發(fā)展對(duì)邊緣計(jì)算的資源管控提出了更高的要求,。

從網(wǎng)絡(luò)角度看,，鄔江興院士指出：互聯(lián)網(wǎng)的多元化發(fā)展，導(dǎo)致當(dāng)前僵化的網(wǎng)絡(luò)運(yùn)行機(jī)制下傳輸控制,、資源管理,、配置維護(hù)等復(fù)雜性倍增，網(wǎng)絡(luò)效率低下,，用戶體驗(yàn)差[13]。針對(duì)該問(wèn)題,，以軟件定義網(wǎng)絡(luò)和網(wǎng)絡(luò)功能虛擬化為代表的未來(lái)網(wǎng)絡(luò)技術(shù)以網(wǎng)絡(luò)開放為目標(biāo),，打破傳統(tǒng)剛性的網(wǎng)絡(luò)架構(gòu)和基線技術(shù)對(duì)網(wǎng)絡(luò)多元化發(fā)展、個(gè)性化服務(wù),、創(chuàng)新應(yīng)用發(fā)展的制約,。軟件定義網(wǎng)絡(luò)和網(wǎng)絡(luò)功能虛擬化事實(shí)上實(shí)現(xiàn)了網(wǎng)絡(luò)層的軟化，通過(guò)軟化實(shí)現(xiàn)開放,，進(jìn)而支撐定制創(chuàng)新,，在云計(jì)算中已得到了廣泛認(rèn)可與應(yīng)用。

綜合當(dāng)前邊緣計(jì)算的發(fā)展困境以及云計(jì)算的前沿發(fā)展趨勢(shì),，本文認(rèn)為軟化是推動(dòng)邊緣計(jì)算發(fā)展的潛在思路,。本文將云原生技術(shù)以及未來(lái)網(wǎng)絡(luò)技術(shù)融合，提出了全棧式云原生邊緣計(jì)算架構(gòu),，實(shí)現(xiàn)算網(wǎng)融合的資源管控,。針對(duì)邊緣資源有限特征,，通過(guò)發(fā)掘利用容器的分層結(jié)構(gòu)特征，研究了低開銷的邊緣服務(wù)部署優(yōu)化方法,。最后,，對(duì)云原生邊緣計(jì)算將面臨的發(fā)展挑戰(zhàn)進(jìn)行展望。

2 云原生計(jì)算的發(fā)展現(xiàn)狀與趨勢(shì)

2.1 云原生架構(gòu)：微服務(wù)和無(wú)服務(wù)器計(jì)算

云原生計(jì)算[14]通過(guò)引入靈活的網(wǎng)絡(luò)資源調(diào)度方式,，實(shí)現(xiàn)動(dòng)態(tài)的資源編排,，成為云計(jì)算網(wǎng)絡(luò)開發(fā)和軟件部署最快速有效的方式，得到了業(yè)界的廣泛認(rèn)可,。云原生計(jì)算基金會(huì)定義云原生計(jì)算的特征屬性為：面向微服務(wù),、基于容器化封裝和自動(dòng)化管理。在云原生的架構(gòu)中,，應(yīng)用程序被開發(fā)為無(wú)狀態(tài)和松散耦合的微服務(wù),，從而提高服務(wù)的重用性和可靠性。

以云原生的方式對(duì)應(yīng)用進(jìn)行運(yùn)行維護(hù)具有諸多優(yōu)勢(shì),，能夠適應(yīng)DevOps模式,、持續(xù)集成等應(yīng)用研發(fā)需求。如當(dāng)一個(gè)服務(wù)實(shí)例在運(yùn)行中失效時(shí),，另一個(gè)服務(wù)實(shí)例可以快速生成并立即頂替其功能,；當(dāng)服務(wù)請(qǐng)求劇烈變化時(shí)，能夠靈活地實(shí)現(xiàn)服務(wù)實(shí)例的縮放,，提高資源利用率,，保障用戶服務(wù)質(zhì)量。接下來(lái),，簡(jiǎn)要介紹云原生計(jì)算的架構(gòu)與支撐技術(shù),。目前，云原生計(jì)算主要有微服務(wù)和無(wú)服務(wù)器計(jì)算兩種主流架構(gòu)[15],。

微服務(wù)通過(guò)將一個(gè)大型單體應(yīng)用分解為多個(gè) 小型模塊來(lái)進(jìn)行部署,，這種方法的好處是可以構(gòu)建、測(cè)試和部署單個(gè)服務(wù),，不會(huì)對(duì)整個(gè)產(chǎn)品或其他服務(wù)產(chǎn)生不良影響[12],。微服務(wù)能夠?qū)崿F(xiàn)更便捷的發(fā)布，開發(fā)者可以在最初只向子集發(fā)布新特性,，然后在該特性達(dá)到目標(biāo)期望后轉(zhuǎn)向整個(gè)用戶群發(fā)布新特性,。微服務(wù)所具有的敏捷性、可靠性和可伸縮性很契合應(yīng)用開發(fā)運(yùn)行維護(hù)的需求,。

無(wú)服務(wù)器計(jì)算是將基礎(chǔ)設(shè)施服務(wù)器層抽象出來(lái)的概念[16],，這樣可以幫助開發(fā)人員專注于構(gòu)建應(yīng)用，不必考慮硬件服務(wù)器的可伸縮性、可用性和安全性,。從使用的角度來(lái)看,，應(yīng)用程序應(yīng)盡可能多地使用網(wǎng)絡(luò)和存儲(chǔ)，這意味著當(dāng)程序沒(méi)有被使用時(shí),，硬件資源不會(huì)被閑置,；當(dāng)使用量激增時(shí)，基礎(chǔ)設(shè)施可以在任何程度上擴(kuò)展,，而不必立即手動(dòng)提供新服務(wù)器[12],。

微服務(wù)體系結(jié)構(gòu)允許小團(tuán)隊(duì)的開發(fā)人員專注 于單獨(dú)的服務(wù)，每個(gè)團(tuán)隊(duì)提供一個(gè)特定的任務(wù),，而無(wú)服務(wù)器計(jì)算則幫助團(tuán)隊(duì)以最少的精力啟動(dòng)和運(yùn)行這些微服務(wù),。微服務(wù)仍涉及一定量的計(jì)算資源集群管理[12,17-18]，而無(wú)服務(wù)器計(jì)算使得應(yīng)用開發(fā)者可以專注于代碼編寫并定義應(yīng)該觸發(fā)代碼執(zhí)行的事件,，并將其留給云來(lái)處理其余的事,。

2.2 云原生支撐技術(shù)

云原生的出現(xiàn)需要開發(fā)者提出新的協(xié)議及架 構(gòu)，一些比較成熟的技術(shù)如容器[12],、微服務(wù)調(diào)度工具（如Kubernetes）,、服務(wù)網(wǎng)格等，為云原生的實(shí)現(xiàn)提供了巨大的技術(shù)支持與經(jīng)驗(yàn),。云原生的關(guān)鍵支撐技術(shù)如下,。

1)容器

容器的本質(zhì)是一個(gè)進(jìn)程，通過(guò)對(duì)該進(jìn)程進(jìn)行隔離和資源控制,，使得其在運(yùn)行時(shí)不會(huì)相互干擾,。同時(shí)，容器具有良好的移植性,，可以在不同的操作系統(tǒng)中良好運(yùn)行,。以前，開發(fā)者通常會(huì)使用虛擬機(jī)來(lái)完成某些功能,，但是虛擬機(jī)的系統(tǒng)開銷較大,，并且不利于程序的移植與部署。與虛擬機(jī)相比,，容器更加輕量化,，打包下載都更方便,，其中最著名的容器是Docker,。Docker是一個(gè)開源容器引擎，可以讓開 發(fā)者打包其應(yīng)用以及依賴包到一個(gè)輕量級(jí),、可移植的容器中,，然后發(fā)布到任何流行的操作系統(tǒng)中。在運(yùn)行時(shí),，Docker的性能開銷幾乎可以忽略不計(jì),。Docker占用資源少,、部署快，每個(gè)應(yīng)用可以被打包 成一個(gè)Docker鏡像,。Docker容器中每個(gè)應(yīng)用不需 要與其他應(yīng)用組合,，也不依賴于生產(chǎn)環(huán)境基礎(chǔ)結(jié)構(gòu)，能在研發(fā),、測(cè)試,、生產(chǎn)過(guò)程中為應(yīng)用提供一致的環(huán)境。Docker使用客戶端—服務(wù)器模式,，利用遠(yuǎn) 程應(yīng)用程序接口（API,application programming interface）來(lái)管理和創(chuàng)建Docker容器,。Docker容器通過(guò)Docker鏡像來(lái)創(chuàng)建，鏡像就像容器的模板,，每次創(chuàng)建容器都依賴于已有的鏡像,。

2) 容器管理器

僅依靠容器并不能滿足開發(fā)者的需求。現(xiàn)在,，一個(gè)集群中有上萬(wàn)個(gè)容器鏡像是很普遍的,，為了管理這些容器，如控制容器的生存周期,，對(duì)容器進(jìn)行遷移,，對(duì)這些容器間的流量進(jìn)行調(diào)度等，開發(fā)者需要一個(gè)完備的治理框架,，目前Kubernetes是應(yīng)用較廣泛的治理框架,。Kubernetes簡(jiǎn)稱K8s，是一個(gè)可移植,、可擴(kuò)展的開源平臺(tái),，用于管理基于容器的微服務(wù)集群。在 Kubernetes 中,，可以創(chuàng)建多個(gè) Pod（Kubernetes的基本單元）,，每個(gè)Pod中可以部署多 個(gè)容器，每個(gè)容器中可以部署一個(gè)服務(wù),，然后通過(guò)內(nèi)置或自定義的負(fù)載均衡策略,，實(shí)現(xiàn)對(duì)一組微服務(wù)的管理、注冊(cè)和訪問(wèn),。開發(fā)者可以使用Kubernetes的kubectl組件對(duì)其下的各個(gè)服務(wù)進(jìn)行管控,。

3) 服務(wù)網(wǎng)格

盡管在很多情況下Kubernetes能夠完成微服務(wù)治理功能，但開發(fā)者仍然會(huì)遇到其他問(wèn)題,。在實(shí)際生產(chǎn)環(huán)境中,，由于微服務(wù)的實(shí)現(xiàn)方式不同，如果要使微服務(wù)之間進(jìn)行通信，開發(fā)者需要預(yù)先協(xié)調(diào)通信接口和方式,。此外,，流量的管控與調(diào)度由于要考慮環(huán)境中的各種因素，所以開發(fā)過(guò)程并不簡(jiǎn)單,。因此,， 服務(wù)網(wǎng)格應(yīng)運(yùn)而生[19]。Kubernetes與服務(wù)網(wǎng)格對(duì)比如圖1 所示,，作為服務(wù)之間通信的基礎(chǔ)設(shè)施層,，服務(wù)網(wǎng)格可以分離微服務(wù)中的通用功能，如服務(wù)注冊(cè)發(fā)現(xiàn),、負(fù)載均衡,、熔斷降級(jí)、流量管理,、監(jiān)控等功能,，極大地補(bǔ)充了Kubernetes使用時(shí)的一些不足。

在服務(wù)網(wǎng)格中,，每個(gè)微服務(wù)通過(guò)邊車代理其服務(wù)間通信,，因而大量的微服務(wù)與對(duì)應(yīng)的邊車會(huì)表現(xiàn)出網(wǎng)格的形式，這就是服務(wù)網(wǎng)格名稱的由來(lái),。服務(wù)網(wǎng)格可以在多種環(huán)境中部署,，最常用的是Kubernetes。服務(wù)網(wǎng)格（如Istio框架）與Kubernetes 有較好的兼容性,，Kubernetes對(duì)應(yīng)用進(jìn)行生命周期管理,，服務(wù)網(wǎng)格提供應(yīng)用間的流量、安全管理以及可觀察性,。

云原生支撐技術(shù)框架對(duì)比如圖2所示,，Kubernetes的Kube-proxy組件實(shí)現(xiàn)了流量在Kubernetes服務(wù)中多個(gè)Pod實(shí)例間的負(fù)載均衡，但是Kube-proxy的設(shè)置是全局的,，無(wú)法對(duì)單獨(dú)的Pod 進(jìn)行精細(xì)的管理,。而服務(wù)網(wǎng)格將Kubernetes中的這 一功能分離出來(lái)，部署在邊車中,，不再需要Kubernetes的Kube-proxy組件支持,，通過(guò)更接近微 服務(wù)應(yīng)用層的部署來(lái)管理服務(wù)之間的通信、流量管理,、負(fù)載均衡和可觀察性,。總體來(lái)講,，Kubernetes使用Docker容器技術(shù)來(lái)部署和管理微服務(wù),，實(shí)現(xiàn)微服務(wù)的自動(dòng)部署、自動(dòng)重啟,、自動(dòng)復(fù)制,、自動(dòng)擴(kuò)展等功能，服務(wù)網(wǎng)格則可以部署于Kubernetes上,，負(fù)責(zé)提供應(yīng)用間更靈活的流量控制,、安全管理以及可觀察性。

4)Unikernel

Unikernel是一個(gè)特殊的,、單地址空間的機(jī)器鏡像,，它實(shí)現(xiàn)了底層硬件資源的直接取用，免去了不必要的硬件抽象,。Docker是一種有效的應(yīng)用管理容 器技術(shù),，它解決了應(yīng)用的可移植性問(wèn)題。相比于虛擬機(jī),，Docker的鏡像已經(jīng)小了很多,，但還是有好幾百兆。Unikernel則進(jìn)一步減小了自身的體積,，只需要幾十兆甚至幾兆,。Unikernel在構(gòu)架中去除了操作系統(tǒng)，其應(yīng)用直接運(yùn)行在hypervisor或者硬件上,，由于不包含許多應(yīng)用不需要的包和依賴,，從而有效改善了資源的利用情況。Unikernel具有以下優(yōu)勢(shì)：

①體積小,，Unikernel只需要包含應(yīng)用所必須的依賴和包,，大大減小了自身的體積；②速度快,，由于Unikernel中沒(méi)有其他不必要的程序,，有效減少了多進(jìn)程之間的任務(wù)切換和啟動(dòng)，使得中央處理器（CPU,central processing unit）能夠高效運(yùn)行,，啟動(dòng)速度也非?？欤ǔＶ挥?0mm甚至幾毫秒,，使它在用戶需要時(shí)進(jìn)行啟動(dòng)響應(yīng),。Unikernel也由此被視為實(shí)現(xiàn)云原生的重要支撐技術(shù)之一。

2.3 云原生邊緣計(jì)算

云原生助力邊緣計(jì)算,，已經(jīng)得到了工業(yè)界的認(rèn)可,，出現(xiàn)了一些應(yīng)用較廣泛的框架，如阿里云開源的項(xiàng)目OpenYurt,。OpenYurt是基于原生Kubernetes構(gòu)建的框架,，用戶可以使用OpenYurt在 邊緣環(huán)境中管理運(yùn)行的微服務(wù),。它克服了一些邊緣場(chǎng)景的限制，例如,，如何最小化設(shè)備和工作負(fù)載之間的長(zhǎng)距離網(wǎng)絡(luò)流量,，如何解決邊緣場(chǎng)景中的可靠性，如何進(jìn)行安全驗(yàn)證,，如何降低傳送時(shí)延等,。OpenYurt提供了完全的Kubernetes API兼容性，支持Kubernetes的所有特性,，它也提供了一種工具可以讓本機(jī)的Kubernetes轉(zhuǎn)化為邊緣狀態(tài),，還能提高集群在邊緣場(chǎng)景中的穩(wěn)定性。

KubeEdge是云原生在邊緣計(jì)算中拓展的典型架構(gòu),，其基于Kubernetes架構(gòu)提供了許多邊緣場(chǎng)景的功能支持,，如離線運(yùn)行能力、邊云協(xié)同能力等,。該架構(gòu)分為云端組件和邊緣組件,。在云端組件中，用戶通過(guò)kubectl命令行對(duì)目標(biāo)對(duì)象的預(yù)期狀態(tài)發(fā)出命令,，并由Kubernetes的API服務(wù)器進(jìn)行接收并使用調(diào)度器對(duì)對(duì)象進(jìn)行調(diào)度,；在邊緣組件中，所有組件設(shè)計(jì)的原則為“簡(jiǎn)單至上”,，以降低邊緣組件的資源占用,、發(fā)生故障的概率以及維護(hù)的難度。

K3s是另一種經(jīng)典的被運(yùn)用在邊緣計(jì)算中的架構(gòu),，傳統(tǒng)的Kubernetes其組件很臃腫復(fù)雜,，導(dǎo)致其在邊緣設(shè)備性能不足的背景下工作較困難，而K3s僅作為單一的二進(jìn)制文件進(jìn)行打包和部署,，安裝迅速便捷,。同時(shí)，K3s刪除了很多對(duì)于運(yùn)行最低限度的集群來(lái)說(shuō)不重要的組件,，加入了一些新的必要元素,，使得其可以適用于邊緣計(jì)算場(chǎng)景。

盡管現(xiàn)在已經(jīng)有一些架構(gòu)可以幫助開發(fā)者應(yīng)對(duì)邊緣場(chǎng)景,，但這些架構(gòu)仍然存在一些問(wèn)題,，它們大多只考慮了邊緣環(huán)境的一部分，如只考慮了服務(wù)治理,，而忽略了網(wǎng)絡(luò)協(xié)議等也是可以融合的,。因此，本文將進(jìn)一步地將服務(wù)網(wǎng)格,、軟件定義網(wǎng)絡(luò),、網(wǎng)絡(luò)功能虛擬化等技術(shù)融合,，提出全棧式架構(gòu)。

03

全棧式云原生邊緣計(jì)算架構(gòu)

云原生計(jì)算變革了應(yīng)用開發(fā)與運(yùn)維模式,，通過(guò)底層物理計(jì)算資源的抽象與軟化,，使得應(yīng)用開發(fā)運(yùn)行維護(hù)人員集中關(guān)注應(yīng)用自身，不需要考慮底層物理資源,。同時(shí)，針對(duì)傳統(tǒng)網(wǎng)絡(luò)架構(gòu)剛性基線技術(shù)對(duì)網(wǎng)絡(luò)靈活管控的局限,、對(duì)網(wǎng)絡(luò)資源與計(jì)算資源協(xié)同調(diào)度的制約,，以軟件定義網(wǎng)絡(luò)與網(wǎng)絡(luò)功能虛擬化為代表的未來(lái)網(wǎng)絡(luò)技術(shù)提供了新的解決途徑。融合云原生計(jì)算與未來(lái)網(wǎng)絡(luò)技術(shù),，本文提出了面向邊緣計(jì)算的全棧式云原生計(jì)算架構(gòu),，實(shí)現(xiàn)邊緣網(wǎng)絡(luò)資源、 計(jì)算資源的協(xié)同管理,，全棧式云原生邊緣計(jì)算架構(gòu)如圖3 所示,。當(dāng)前分布式計(jì)算系統(tǒng)結(jié)構(gòu)的發(fā)展趨勢(shì)是數(shù)據(jù)層與控制層的分離，如軟件定義網(wǎng)絡(luò)通過(guò)解耦并集中控制層面,，極大地提升了計(jì)算機(jī)網(wǎng)絡(luò)的靈活性和可定制性,；服務(wù)網(wǎng)格提供控制器管理邊車所代理的服務(wù)的流量。因此,，本文認(rèn)為,，解耦數(shù)據(jù)層與控制層是未來(lái)分布式系統(tǒng)架構(gòu)的發(fā)展趨勢(shì)之一。圖3中所提出架構(gòu)的最上層為控制層,，包含面向多個(gè)不同功能組件的控制器,；控制層的各個(gè)控制器組件管控其下各層的不同組件。

圖3 全棧式云原生邊緣計(jì)算架構(gòu)

1) 物理層

物理層是整個(gè)系統(tǒng)的最底層,，包含各種邊緣計(jì)算物理資源,，如計(jì)算機(jī)、網(wǎng)絡(luò)設(shè)備,、通信設(shè)備,、傳感設(shè)備、存儲(chǔ)設(shè)備等,。從資源類型來(lái)看,，邊緣計(jì)算與支撐云計(jì)算的數(shù)據(jù)中心類似。但從資源特征來(lái)看,，邊緣計(jì)算與云計(jì)算有很大區(qū)別,，主要表現(xiàn)在資源高異構(gòu)與廣分布兩個(gè)方面。云計(jì)算數(shù)據(jù)中心一般由單一的主體運(yùn)行,，其物理設(shè)備相對(duì)比較統(tǒng)一,。由于邊緣計(jì)算接入門檻低,，各類主體均可提供基礎(chǔ)物理設(shè)施接入邊緣計(jì)算平臺(tái)。如移動(dòng)運(yùn)營(yíng)商可通過(guò)靠近蜂窩網(wǎng)通信基礎(chǔ)設(shè)施的計(jì)算設(shè)備接入邊緣計(jì)算提供物理資源,，城市中的小區(qū)也可建設(shè)小型數(shù)據(jù)中心,。各基礎(chǔ)設(shè)施提供商的物理資源難以統(tǒng)一，不僅表現(xiàn)在資源容量方面,，同時(shí)表現(xiàn)在資源架構(gòu)方面,。如計(jì)算機(jī)可能為X86架構(gòu)，也可能為ARM（advanced RISC machine）架構(gòu),，且同時(shí)可能部署不同的硬件加速器,，如圖形處理器（GPU,graphics processing unit）、現(xiàn)場(chǎng)可編程邏輯門陣列（FPGA,field programmable gate array）等,。

此外,，由于邊緣計(jì)算靠近終端用戶，其網(wǎng)絡(luò)接入方式更多樣,，不僅包括有線網(wǎng)絡(luò)接入,，還包括各類無(wú)線網(wǎng)絡(luò)接入（如4G、5G,、Wi-Fi 等）,。多元化基礎(chǔ)設(shè)施的提供，不僅引發(fā)了邊緣計(jì)算的高異構(gòu),，同時(shí)也導(dǎo)致了資源分布廣的特征,。因此，邊緣計(jì)算不具備云計(jì)算數(shù)據(jù)中心相對(duì)規(guī)則的網(wǎng)絡(luò)拓?fù)洌ㄈ鏔atTree,、Bcube等）,，其網(wǎng)絡(luò)拓?fù)溆捎诘乩矸植际降挠?jì)算資源供給具有非規(guī)則屬性。因此,，物理資源的高異構(gòu)與廣分布對(duì)資源管控帶來(lái)了極大的挑戰(zhàn),，阻礙了邊緣計(jì)算的發(fā)展。抽象廣分布的異構(gòu)物理資源,，使得邊緣計(jì)算物理資源特征對(duì)應(yīng)用開發(fā)運(yùn)行維護(hù)透明,，對(duì)邊緣計(jì)算的發(fā)展有重要推動(dòng)作用。

2) 網(wǎng)絡(luò)層

由于物理層資源的廣分布特征,，使得網(wǎng)絡(luò)成為串聯(lián)各類異構(gòu)資源的核心,。同時(shí)，如前所述,，傳統(tǒng)封閉剛性的網(wǎng)絡(luò)技術(shù)阻礙了邊緣計(jì)算應(yīng)用的開放式發(fā)展,。因此，在本文提出的全棧式網(wǎng)絡(luò)架構(gòu)中,， 為實(shí)現(xiàn)算網(wǎng)協(xié)同的資源調(diào)度,，單獨(dú)抽象一層獨(dú)立的網(wǎng)絡(luò)層,。網(wǎng)絡(luò)層不僅包括交換機(jī)、路由器等基礎(chǔ)通信物理設(shè)施,，還包括驅(qū)動(dòng)軟件定義網(wǎng)絡(luò)功能實(shí)現(xiàn)的各類基礎(chǔ)軟件（如Open vSwitch等）以及各類虛擬網(wǎng)絡(luò)功能,。

軟件定義網(wǎng)絡(luò)通過(guò)將控制平面從數(shù)據(jù)平面中分離出來(lái)，使開發(fā)者在不改變硬件設(shè)備的前提下,，可以更靈活地進(jìn)行網(wǎng)絡(luò)管理,，從而實(shí)現(xiàn)對(duì)上層應(yīng)用（或服務(wù)）間的開放式流量管理與個(gè)性化定制。同時(shí),，通過(guò)網(wǎng)絡(luò)功能虛擬化技術(shù)為應(yīng)用間的流量管理提供各類網(wǎng)絡(luò)服務(wù),。通過(guò)將傳統(tǒng)基于硬件實(shí)現(xiàn)的各類虛擬網(wǎng)絡(luò)功能軟化，使網(wǎng)絡(luò)設(shè)備功能不再依賴于專用硬件,，從而實(shí)現(xiàn)對(duì)各類網(wǎng)絡(luò)服務(wù)的靈活管理,、新業(yè)務(wù)的快速開發(fā)和部署,。

3) 服務(wù)層

服務(wù)層直接采用云原生計(jì)算架構(gòu),，其核心是在物理計(jì)算資源上抽象出各種服務(wù)構(gòu)建邊緣應(yīng)用。因此,，服務(wù)層同時(shí)涉及容器與虛擬機(jī)兩種虛擬化技術(shù),。首先，與云計(jì)算數(shù)據(jù)中心類似,，以虛擬機(jī)的形式抽象物理計(jì)算資源,，提升物理資源利用率。在虛擬機(jī)中,，可進(jìn)一步地部署容器用于服務(wù)實(shí)例的實(shí)現(xiàn)與部署,。通常情況下，一個(gè)容器不能滿足一個(gè)微服務(wù)的所有需求,，因此主流的容器管理器（如Kubernetes）會(huì)將一些容器聯(lián)合起來(lái),，將其稱為Pod， 并將Pod 作為最基礎(chǔ)的處理單元,，即服務(wù)實(shí)例,。

此外，在邊緣計(jì)算場(chǎng)景中,，由于資源限制,，并非所有計(jì)算設(shè)備都適合部署虛擬機(jī)進(jìn)行物理資源共享。因此,，Pod及其所包含的各類容器也可以直接部署在物理服務(wù)器上,。無(wú)論P(yáng)od 部署在虛擬機(jī)上還是物理 服務(wù)器上，均對(duì)應(yīng)用的開發(fā)與運(yùn)行維護(hù)透明,。也就是說(shuō),，邊緣應(yīng)用開發(fā)運(yùn)行維護(hù)人員的關(guān)注對(duì)象為Pod或由Pod提供的基礎(chǔ)服務(wù),，不需要關(guān)注物理資源的管控，后者由邊緣設(shè)施提供商進(jìn)行運(yùn)行維護(hù),。

特別注意的是,，在本文提出的全棧式架構(gòu)中，引入了服務(wù)網(wǎng)格實(shí)現(xiàn)異構(gòu)服務(wù)間的標(biāo)準(zhǔn)化流量通信管理,。如前所述,，每個(gè)服務(wù)將對(duì)應(yīng)一個(gè)邊車，邊車與軟件定義網(wǎng)絡(luò)的數(shù)據(jù)平面融合,，共同構(gòu)成本文框架中的數(shù)據(jù)層部分,。通過(guò)融合，使得網(wǎng)絡(luò)層的軟件定義交換機(jī)中的流表能夠根據(jù)服務(wù)的屬性信息（如服務(wù)名,、端口號(hào)等）進(jìn)行定制,，如基于P4進(jìn)行網(wǎng)絡(luò)數(shù)據(jù)平面編程，而不需要僅按照傳統(tǒng)軟件定義網(wǎng)絡(luò)中指定的屬性信息進(jìn)行網(wǎng)絡(luò)流管控,，加強(qiáng)網(wǎng)絡(luò)管理的縱深與融合程度,，從而通過(guò)全棧式的方式提供開放、靈活,、可定制的網(wǎng)絡(luò)流管理服務(wù),。

4) 控制層

控制層集成了面向各層的管理組件，包括容器編排管理模塊,、服務(wù)網(wǎng)格控制器,、軟件定義網(wǎng)絡(luò)控制器和虛擬網(wǎng)絡(luò)功能編排管理模塊MANO。通過(guò)控制層與服務(wù)層的剝離,，實(shí)現(xiàn)全棧式便捷靈活的邊緣應(yīng)用編排管理,。容器編排管理模塊能夠根據(jù)應(yīng)用需求、訪問(wèn)需求,、物理資源動(dòng)態(tài)變化,，基于設(shè)定的規(guī)則實(shí)現(xiàn)容器全生命周期的管理，包括服務(wù)注冊(cè),、部署,、擴(kuò)容、銷毀等,。Kubernetes主節(jié)點(diǎn)組件可用于實(shí)現(xiàn)這一功能,。與之相配合的是服務(wù)網(wǎng)格管理器（如Istio Controller），通過(guò)管理各個(gè)服務(wù)對(duì)應(yīng)邊車中 的網(wǎng)絡(luò)流,，實(shí)現(xiàn)面向服務(wù)的負(fù)載均衡,、安全監(jiān)測(cè)、 熔斷等運(yùn)行時(shí)操作。軟件定義控制器通過(guò)南向接口（如Openflow）向軟件定義交換機(jī)注入流表項(xiàng),，管控?cái)?shù)據(jù)流在網(wǎng)絡(luò)層中的行為,。服務(wù)網(wǎng)格控制器與軟件定義控制器能夠相互配合，從不同層面對(duì)網(wǎng)絡(luò)流進(jìn)行管理,。前者主要從服務(wù)的角度,，從邏輯上管控服務(wù)間流量；后者是對(duì)前者邏輯管控的物理實(shí)現(xiàn),。網(wǎng)絡(luò)功能管理模塊與容器管理模塊類似,，但兩者的管理對(duì)象不同，網(wǎng)絡(luò)功能管理模塊針對(duì)各個(gè)虛擬網(wǎng)絡(luò)功能的生命周期進(jìn)行管理,?？刂茖拥母鱾€(gè)模塊通過(guò)相互配合，能夠?qū)崿F(xiàn)算網(wǎng)融合的高效調(diào)度,，符合當(dāng)下分布式計(jì)算的發(fā)展趨勢(shì),。

04面向邊緣計(jì)算的低開銷微服務(wù)部署

與資源相對(duì)豐富的云計(jì)算數(shù)據(jù)中心不同，邊緣計(jì)算資源容量匱乏,。在應(yīng)用云原生技術(shù)于邊緣計(jì)算時(shí),，資源開銷是需要考慮的一個(gè)重要方面。微服務(wù)部署是實(shí)現(xiàn)云原生應(yīng)用的重要基礎(chǔ),，高效地部署微服務(wù)對(duì)云原生邊緣計(jì)算具有重要意義,。

云原生的支撐技術(shù)之一——容器也為實(shí)現(xiàn)低開銷微服務(wù)部署提供了新的優(yōu)化點(diǎn),，盡管邊緣計(jì)算中的微服務(wù)部署優(yōu)化研究已被廣泛關(guān)注[20-21],，但現(xiàn)有的研究一般將容器視為輕量級(jí)的虛擬機(jī)，往往忽略了其分層屬性,。因此,，本節(jié)將探討如何發(fā)掘利用容器的分層屬性實(shí)現(xiàn)低開銷的微服務(wù)部署優(yōu)化。

4.1 容器分層與問(wèn)題陳述

容器在實(shí)現(xiàn)時(shí)不是一個(gè)整體,，而是按照分層結(jié)構(gòu)組織,。如加入某容器基于Ubuntu系統(tǒng)實(shí)現(xiàn)，且需要MySQL數(shù)據(jù)庫(kù)的支持,?？梢岳斫鉃椋萜鞯牡讓邮且粋€(gè)Ubuntu 鏡像,，其上疊加了一個(gè)MySQL層,，再在上面疊加所需的操作，這樣便能組成一個(gè)完整的服務(wù)功能,。顯然,，當(dāng)在同一臺(tái)物理機(jī)上部署多個(gè)容器時(shí)，如果容器間進(jìn)行層共享，就能夠有效降低開銷,。一方面,，在鏡像拉取時(shí)，層共享使得不需要拉取冗余的層,，不僅降低了網(wǎng)絡(luò)開銷還有利于服務(wù)的快速啟動(dòng),；另一方面，邊緣服務(wù)器也不需要冗余存儲(chǔ)容器的層,，能夠有效降低存儲(chǔ)資源開銷,。

邊緣計(jì)算環(huán)境中的分布式服務(wù)器的資源有限， 同時(shí)需要部署的容器具有不同的計(jì)算與存儲(chǔ)資源需求,，如何綜合考慮容器的分層特性,，實(shí)現(xiàn)邊緣計(jì)算環(huán)境中的低開銷容器部署，對(duì)云原生邊緣計(jì)算具有重要意義,。首先構(gòu)建分層敏感的低開銷容器部署優(yōu)化理論模型,，為便于讀者理解,，總結(jié)了模型中涉及的數(shù)學(xué)符號(hào)與其定義，數(shù)學(xué)符號(hào)與定義如表1所示。

4.2 層共享敏感的低開銷容器部署優(yōu)化

圖4 主要考慮容器數(shù)量的增多對(duì)部署開銷（以存儲(chǔ)占用為衡量）的影響,。從圖4中可以看出，隨著容器數(shù)量的增加,，3個(gè)算法所需要的總存儲(chǔ)空間也逐漸增加,。對(duì)比3個(gè)算法可以看出，考慮層共享的部署方案在存儲(chǔ)資源占用上均優(yōu)于無(wú)層共享的方案,。此外,，本文所提的松弛算法可以取得逼近最優(yōu)解的結(jié)果。

如4 圖所示,，當(dāng)容器數(shù)量較少時(shí),，能夠共享的層數(shù)量有限導(dǎo)致規(guī)劃空間有限，松弛算法幾乎可以得到與最優(yōu)解相同的結(jié)果,。隨著容器數(shù)量的增加,，占用的空間也越來(lái)越多，因此總消耗呈上升趨勢(shì),。但是由圖4可以看出,，采用層共享方法存儲(chǔ)的方式可以使開銷得到明顯降低，容器數(shù)量越多,，優(yōu)勢(shì)越明顯,。這是因?yàn)椋S著容器數(shù)量的增加,，可共享的層越來(lái)越多,，層共享的優(yōu)勢(shì)也越來(lái)越明顯。

圖5展示了服務(wù)器資源的提升對(duì)部署開銷的影響，將資源大小隨倍數(shù)增加,，隨著存儲(chǔ)空間,、計(jì)算資源和通信資源的增加，同一個(gè)服務(wù)器上可部署的容器數(shù)量也會(huì)逐漸增加,，越來(lái)越多的容器可以被部署在同一個(gè)服務(wù)器上,，潛在地能夠共享更多的層，從而降低容器的總部署開銷,，而無(wú)層共享的方案則一直需要相同的部署開銷,。實(shí)驗(yàn)結(jié)果證明了層共享在部署開銷上的優(yōu)勢(shì)，當(dāng)存儲(chǔ)空間,、計(jì)算資源和通信資源增加到一定程度時(shí),，所有容器可以部署在一個(gè)或少數(shù)幾個(gè)服務(wù)器上，此時(shí)松弛算法和最優(yōu)解取得了相同結(jié)果,。

05展望與挑戰(zhàn)

盡管云原生對(duì)推動(dòng)邊緣計(jì)算發(fā)展具有極大的 潛力,，工業(yè)界也相繼推出了相關(guān)解決方案，但仍處于該方向研究的初始階段,。由于邊緣計(jì)算環(huán)境與云計(jì)算數(shù)據(jù)中心的本質(zhì)區(qū)別,，云原生邊緣計(jì)算還存在諸多挑戰(zhàn)。本節(jié)將展望并分析可能存在的挑戰(zhàn),。

1) 廣分布高異構(gòu)資源管理

邊緣計(jì)算資源分散在不同地理分布的地方,，如用戶終端設(shè)備、通信基站,、智能路由器,、邊緣服務(wù)器等。而云計(jì)算中的資源都是集中式的管理,，因此云計(jì)算的資源管理方式和框架（如OpenStack）不適用于管理邊緣計(jì)算分散的資源,，亟需發(fā)展新的適應(yīng)廣分布高異構(gòu)邊緣資源管理的解決方案,。目前,，關(guān)于邊緣計(jì)算資源的管控研究大多集中在算法層面，容易忽略在具體部署實(shí)踐中的某些細(xì)節(jié),。

此外,，CPU架構(gòu)差異（如X86與ARM）、硬件加速器并存（如FPGA,、GPU等）,、有線與無(wú)線共在等特性， 均對(duì)邊緣資源管理帶來(lái)了極大的挑戰(zhàn),。盡管云原生使應(yīng)用開發(fā)運(yùn)行維護(hù)人員能夠遠(yuǎn)離這些細(xì)節(jié),，但對(duì)基礎(chǔ)設(shè)施管理人員提出了要求，需要其能夠設(shè)計(jì)出上層應(yīng)用透明，但又對(duì)上層應(yīng)用特征敏感（如本文所述容器的分層結(jié)構(gòu)）的高效解決方案,。

2) 分布式服務(wù)狀態(tài)管理

云原生計(jì)算中的微服務(wù)或者函數(shù)功能自身均 不保留狀態(tài),，但實(shí)際上并非所有服務(wù)或函數(shù)都沒(méi)有狀態(tài)，狀態(tài)管理因此成為云原生必須討論的一個(gè)問(wèn)題,。在云原生邊緣計(jì)算中,，這一問(wèn)題變得更突出，主要由于前述邊緣計(jì)算平臺(tái)環(huán)境自身的特征所致,。此外,，邊緣計(jì)算中的服務(wù)請(qǐng)求可能具有高度移動(dòng)性，以及由此導(dǎo)致的時(shí)空異構(gòu)性,。這都對(duì)云原生邊緣計(jì)算的狀態(tài)管理帶來(lái)了新的挑戰(zhàn),。

顯然，集中式的狀態(tài)管理不適用于云原生邊緣計(jì)算,，亟需發(fā)展分布式服務(wù)狀態(tài)管理方法,。由于邊緣計(jì)算環(huán)境的高時(shí)空異構(gòu)動(dòng)態(tài)性，服務(wù)會(huì)高速動(dòng)態(tài)部署,、銷毀,、擴(kuò)容， 相應(yīng)的分布式服務(wù)狀態(tài)的存儲(chǔ)位置（一份或多份拷貝）,、存儲(chǔ)方式（如內(nèi)存或硬盤）,、同步方式（若存 在多份狀態(tài)拷貝）、更新方式（增量更新或全覆蓋 更新）等均需要與服務(wù)的生命周期管理耦合匹配,，實(shí)現(xiàn)高效的服務(wù)狀態(tài)管控,。

3) 邊緣智能的應(yīng)用

邊緣智能隨著邊緣計(jì)算的發(fā)展逐漸成為一個(gè)熱點(diǎn)話題。盡管邊緣智能主要指在邊緣計(jì)算平臺(tái)上部署的各類人工智能應(yīng)用,，本文認(rèn)為邊緣智能的一個(gè)重要應(yīng)用對(duì)象就是邊緣計(jì)算平臺(tái)自身,。云計(jì)算數(shù)據(jù)中心需要自動(dòng)化、智能化運(yùn)行維護(hù)方案,，廣分布高異構(gòu)且資源供需動(dòng)態(tài)性高的邊緣計(jì)算平臺(tái)更需要智能化運(yùn)行維護(hù),。

然而，相較于云數(shù)據(jù)中心,，基于邊緣智能的邊緣平臺(tái)運(yùn)行維護(hù)面臨著環(huán)境復(fù)雜和算力有限兩方面挑戰(zhàn),。如海量的微服務(wù)需要在拓?fù)浞且?guī)則、資源高異構(gòu)的邊緣平臺(tái)上進(jìn)行部署,、擴(kuò)容,、縮容等操作，同時(shí)伴隨著服務(wù)請(qǐng)求的高度時(shí)空動(dòng)態(tài)性,，需觀測(cè)的數(shù)據(jù)不僅數(shù)量大而且維度大,，并且對(duì)數(shù)據(jù)處理的時(shí)效性要求高,。這都與算力有限的邊緣服務(wù)器構(gòu)成矛盾，通過(guò)云邊端融合構(gòu)建分布式的邊緣智能環(huán)境,，通過(guò)智能體協(xié)作共同完成云原生邊緣計(jì)算運(yùn)行時(shí)的智能管控是潛在的發(fā)展途徑,。強(qiáng)化學(xué)習(xí)（包括深度強(qiáng)化學(xué)習(xí)）、聯(lián)邦學(xué)習(xí),、遷移學(xué)習(xí)等都是潛在的支撐技術(shù),。

4) 云原生邊緣應(yīng)用安全與隱私

云原生的核心支撐技術(shù)是容器。相較于虛擬機(jī),，容器的不足之處是其低隔離性,。低隔離性導(dǎo)致部署在同一物理機(jī)或虛擬機(jī)上的不同容器不僅存在資源競(jìng)爭(zhēng)，并且存在安全與隱私風(fēng)險(xiǎn),。然而,，云原生難于擯棄低隔離性的容器在于其輕便性，兩者很難兼得,。因此,，在可能有多邊緣計(jì)算設(shè)施提供商以及多邊緣服務(wù)提供商共存的云原生邊緣計(jì)算環(huán)境中，保障邊緣應(yīng)用的安全與隱私勢(shì)在必行,。

本文認(rèn)為,，利用可信執(zhí)行環(huán)境（TEE,trust execution environment）是潛在的解決方案之一。當(dāng)前各個(gè)主流的CPU廠商均推出了自己的TEE 產(chǎn)品,，如Intel公司的SGX,、ARM公司的TrustZone等。然而,，TEE為了保障業(yè)務(wù)的安全保密執(zhí)行,，也引來(lái)了諸多 必須考慮的因素。如SGX的安全內(nèi)存空間有限,，而TrustZone 的CPU要求獨(dú)占,。容器（包括安全容器與非安全容器）的編排調(diào)度，如何與TEE的特征相適應(yīng),，是亟待研究的一個(gè)方向,。

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

云原生技術(shù)在云計(jì)算中的應(yīng)用為邊緣計(jì)算的發(fā)展指明了新的潛在發(fā)展方向。本文首先簡(jiǎn)要介紹了云原生的相關(guān)概念與關(guān)鍵技術(shù),。在此基礎(chǔ)上,，針對(duì)邊緣計(jì)算的場(chǎng)景特征，融入軟件定義網(wǎng)絡(luò)與網(wǎng)絡(luò)功能虛擬化,，提出了全棧式的云原生邊緣計(jì)算架構(gòu)。該架構(gòu)通過(guò)控制層面與服務(wù)層面的抽象剝離,，能夠?qū)崿F(xiàn)高效的算網(wǎng)協(xié)同邊緣資源管理與應(yīng)用運(yùn)行維護(hù),。

進(jìn)一步地,，針對(duì)云原生的技術(shù)特征，本文研究了容器分層特性敏感的低開銷容器部署優(yōu)化方案,。通過(guò)該實(shí)例研究表明,，云原生邊緣計(jì)算中的資源管控必須考慮云原生自身所引入的新特征。最后,，展望了云原生邊緣計(jì)算發(fā)展所面臨的新挑戰(zhàn),。總之,，云原生非常契合邊緣計(jì)算,，盡管它是一個(gè)新興的概念與技術(shù)，隨著研究的不斷深入,，未來(lái)一定能夠得到巨大的發(fā)展,，期待這個(gè)領(lǐng)域內(nèi)部的技術(shù)突破。

參考文獻(xiàn)

參考文獻(xiàn)：

[1] XU J, CHEN L X, ZHOU P. Joint service caching and task offloading for mobile edge computing in dense networks[C]//IEEE INFOCOM 2018 - IEEE Conference on Computer Communications. IEEE, 2018: 207-215.

[2] CHEN X, JIAO L, LI W Z, et al. Efficient multi-user computation offloading for mobile-edge cloud computing[J]. IEEE/ACM Transactions on Networking, 2016, 24(5): 2795-2808.

[3] DAI Y Y, XU D, MAHARJAN S, et al. Joint computation offloading and user association in multi-task mobile edge computing[J]. IEEE Transactions on Vehicular Technology, 2018, 67(12): 12313-12325.

[4] ZHOU Y Q, TIAN L, LIU L, et al. Fog computing enabled future mobile communication networks: a convergence of communication and computing[J]. IEEE Communications Magazine, 2019, 57(5): 20-27.

[5] QI Y L, TIAN L, ZHOU Y Q, et al. Mobile edge computing-assisted admission control in vehicular networks: the convergence of communication and computation[J]. IEEE Vehicular Technology Magazine, 2019, 14(1): 37-44.

[6] ZHOU Y Q, LIU L, WANG L, et al. Service-aware 6G: an intelligent and open network based on the convergence of communication, computing and caching[J]. Digital Communications and Networks, 2020, 6(3): 253-260.

[7] KRóL M, MASTORAKIS S, ORAN D, et al. Compute first networking: distributed computing meets ICN[C]//The 6th ACM Conference on Information-Centric Networking. ACM, 2019: 67-77.

[8] 劉澤寧, 李凱, 吳連濤, 等. 多層次算力網(wǎng)絡(luò)中代價(jià)感知任務(wù)調(diào)度算法[J]. 計(jì)算機(jī)研究與發(fā)展, 2020, 57(9): 1810-1822.

LIU Z N, LI K, WU L T, et al. CATS: cost aware task scheduling in multi-tier computing networks[J]. Journal of Computer Research and Development, 2020, 57(9): 1810-1822.

[9] PORAMBAGE P, OKWUIBE J, LIYANAGE M, et al. Survey on multi-access edge computing for Internet of Things realization[J]. IEEE Communications Surveys & Tutorials, 2018, 20(4): 2961-2991.

[10] 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.

[11] LEBRE A, PASTOR J, SIMONET A, et al. Revising OpenStack to operate fog/edge computing infrastructures[C]//2017 IEEE International Conference on Cloud Engineering (IC2E). IEEE, 2017: 138-148.

[12] NIU Y P, LIU F M, LI Z P. Load balancing across microservices[C]//IEEE INFOCOM 2018 - IEEE Conference on Computer Communications. IEEE, 2018: 198-206.

[13] 鄔江興. 新型網(wǎng)絡(luò)技術(shù)發(fā)展思考[J]. 中國(guó)科學(xué): 信息科學(xué), 2018, 48(8): 1102-1111.

WU J X. Thoughts of the development of novel network technology[J]. SCIENTIA SINICA Informationis, 2018, 48(8): 1102-1111.

[14] 朱建軍, 方琰崴. 面向服務(wù)的5G云原生核心網(wǎng)及關(guān)鍵技術(shù)研究[J]. 數(shù)字通信世界, 2018(2): 111.

ZHU J J, FANG Y W. Research on service oriented 5g cloud native core network and its key technologies[J]. Digital Communication World, 2018(2): 111.

[15] 王全. 云原生Cloud Native核心網(wǎng)方案及關(guān)鍵技術(shù)[J]. 中國(guó)新通信, 2018, 20(9): 61-62.

WANG Q. Cloud native core network scheme and key technologies[J]. China New Telecommunications, 2018, 20(9): 61-62.

[16] 胡聰叢. 無(wú)服務(wù)器計(jì)算的現(xiàn)狀以及所面臨的挑戰(zhàn)[J].網(wǎng)絡(luò)安全技術(shù)與應(yīng)用,2019(12):84-85.

HU C C. The current situation and challenges of serverless computing[J]. Network Security Technology & Application, 2019(12): 84-85.

[17] HUNG Y H, WANG C Y. Fog micro service market: Promoting fog computing using free market mechanism[C]//2018 IEEE Wireless Communications and Networking Conference (WCNC). IEEE, 2018: 1-6.

[18] YU R, KILARI V T, XUE G, et al. Load balancing for interdependent IoT microservices[C]//IEEE Conference on Computer Communications. IEEE, 2019.

[19] LI W B, LEMIEUX Y, GAO J, et al. Service mesh: challenges, state of the art, and future research opportunities[C]//2019 IEEE International Conference on Service-Oriented System Engineering (SOSE). IEEE, 2019: 122-1225.

[20] VILLARI M, CELESTI A, TRICOMI G, et al. Deployment orchestration of microservices with geographical constraints for Edge computing[C]//2017 IEEE Symposium on Computers and Communications (ISCC). IEEE, 2017: 633-638.

[21] Wang Y, Zhao C, Yang S, et al. MPCSM: Microservice Placement for Edge-Cloud Collaborative Smart Manufacturing[J]. IEEE Transactions on Industrial Informatics, 2020.

作者簡(jiǎn)介

曾德澤（1984?）,，男,，中國(guó)地質(zhì)大學(xué)（武漢）教授、博士生導(dǎo)師,，主要研究方向?yàn)檫吘売?jì)算,、未來(lái)網(wǎng)絡(luò)技術(shù)、物聯(lián)網(wǎng)等,。

陳律昊（1996?）,，男，中國(guó)地質(zhì)大學(xué)（武漢）碩士生,，主要研究方向?yàn)檫吘売?jì)算,、微服務(wù)部署等。

顧琳（1985?）,，女,，華中科技大學(xué)副教授，主要研究方向?yàn)檫吘売?jì)算,、未來(lái)網(wǎng)絡(luò)技術(shù)等,。

李躍鵬（1994?），男,，中國(guó)地質(zhì)大學(xué)（武漢）博士生,，主要研究方向?yàn)檫吘売?jì)算、任務(wù)調(diào)度,、可信執(zhí)行環(huán)境等,。

關(guān)于物聯(lián)網(wǎng)學(xué)報(bào)

《物聯(lián)網(wǎng)學(xué)報(bào)》是由工業(yè)和信息化部主管，人民郵電出版社主辦的中文學(xué)術(shù)期刊,，辦刊宗旨是“服務(wù)科學(xué)發(fā)展,，傳播科學(xué)知識(shí),，促進(jìn)科技創(chuàng)新，培養(yǎng)科技人才”,。