吳夢穎 夏令明 張 晨

1 東南大學(xué) 南京 210096

2 網(wǎng)絡(luò)通信與安全紫金山實驗室 南京 211111

引言

隨著物聯(lián)網(wǎng)和5G的發(fā)展以及應(yīng)用落地，在萬物互聯(lián)的時代中產(chǎn)生的數(shù)據(jù)量將增長到ZB級別，而這部分?jǐn)?shù)據(jù)中的45%都會在邊緣設(shè)備進(jìn)行處理，在這種情形下，以云計算為核心的模型難以滿足大帶寬、隱私性、低延時的業(yè)務(wù)要求[1]。邊緣計算是在網(wǎng)絡(luò)邊緣執(zhí)行計算的一種新型計算模型，它的提出順應(yīng)了當(dāng)前的業(yè)務(wù)開發(fā)需求。邊緣計算模型與云計算模型并不是競爭的關(guān)系，云計算需要邊緣設(shè)備對隱私性進(jìn)行保護(hù)并承擔(dān)對局部數(shù)據(jù)計算的壓力，而邊緣計算只能處理局部數(shù)據(jù)，不能形成全局認(rèn)知，在實際應(yīng)用中還需要云計算平臺來實現(xiàn)信息融合。所以兩者之間的配合在生產(chǎn)實際中尤為關(guān)鍵，云邊協(xié)同正逐漸成為邊緣計算發(fā)展中的重要支撐[2-3]。

在目前的邊緣計算平臺中，邊緣節(jié)點往往以原生Node的方式加入到kubernetes集群中，但是并沒有通過CNI實現(xiàn)網(wǎng)絡(luò)平面的統(tǒng)一。應(yīng)用以微服務(wù)的形式下沉在邊緣節(jié)點，由于邊緣節(jié)點的特性，以往云計算平臺的服務(wù)訪問方案并不能遷移到邊緣計算平臺上使用，從而在云端無法訪問邊緣服務(wù)是目前云邊協(xié)同業(yè)務(wù)發(fā)展應(yīng)用的瓶頸。

1 相關(guān)工作

網(wǎng)絡(luò)接入多樣性、邊緣設(shè)備異構(gòu)性、物理設(shè)備的數(shù)量眾多等導(dǎo)致應(yīng)用開發(fā)運維人員直接管理物理設(shè)備效率低、難度大。因此通過容器化技術(shù)把物理設(shè)備抽象成資源，讓資源管控對應(yīng)用開發(fā)運維人員透明十分重要[4]。目前將云原生擴(kuò)展到邊緣計算，已經(jīng)得到學(xué)術(shù)界和工業(yè)界的廣泛認(rèn)可。

邊緣計算在生產(chǎn)實踐的過程中，并不只是將應(yīng)用部署在邊緣，支持自動的監(jiān)控和運維。還需要支持云邊應(yīng)用數(shù)據(jù)傳輸，邊緣和云上的應(yīng)用和用戶需要進(jìn)行數(shù)據(jù)傳輸。例如在智能家居場景中，云端應(yīng)用需要能訪問到邊緣設(shè)備采集的數(shù)據(jù)。在云邊協(xié)同推理中，邊緣節(jié)點負(fù)責(zé)終端數(shù)據(jù)的采集，按照一定的規(guī)則對數(shù)據(jù)進(jìn)行初步處理，云端模型基于邊緣節(jié)點采集的數(shù)據(jù)訓(xùn)練。

主流的云邊一體化開源邊緣計算平臺有OpenYurt、KubeEdge、SuperEdge等[5]。目前，OpenYurt和SuperEdge的云邊信道只支持作為云邊之間的控制信道，只能承載應(yīng)用的管控流量，可以從云端獲取邊緣應(yīng)用的運維監(jiān)控數(shù)據(jù)，云邊之間的業(yè)務(wù)流量無法通過云邊信道傳輸[6-7]。KubeEdge能支持用戶自定義邊云消息傳輸，使用過程需要部署多個yaml文件[8]。Kubeedge雖然支持自定義邊云消息傳輸，但建議只用來傳輸用戶控制數(shù)據(jù)，因為數(shù)據(jù)信道和控制信道的復(fù)用會帶來系統(tǒng)不穩(wěn)定的風(fēng)險，影響系統(tǒng)控制信息的傳輸，KubeEdge對用戶自定義消息的大小做了限制，不能超過12M，傳輸數(shù)據(jù)量過大會導(dǎo)致其他控制信息的阻塞[9]。

邊緣計算場景下，性能問題至關(guān)重要，即保證低時延和高穩(wěn)定性。邊緣節(jié)點常常處于邊緣云機(jī)房、移動站點，也有可能在露天環(huán)境下，例如高速公路上的etc設(shè)備。邊緣與云端的網(wǎng)絡(luò)并不像中心云那樣可靠，網(wǎng)絡(luò)質(zhì)量參差不齊。例如，在車聯(lián)網(wǎng)和遠(yuǎn)程醫(yī)療場景下，對時延要求極高。如何應(yīng)對云邊之間的弱網(wǎng)環(huán)境，在網(wǎng)絡(luò)不穩(wěn)定的情況下如何盡可能的抵消網(wǎng)絡(luò)傳輸帶來的影響為用戶提供可用的服務(wù)是云端訪問邊緣服務(wù)的重要需求。

2 邊緣服務(wù)網(wǎng)關(guān)架構(gòu)設(shè)計

邊緣計算平臺并不僅僅是將應(yīng)用部署在邊緣并對應(yīng)用進(jìn)行自動化的運維和管理。在很多實際的應(yīng)用場景里，應(yīng)用需要在云端訪問邊緣的服務(wù)。由于邊緣節(jié)點的位置往往處于內(nèi)網(wǎng)環(huán)境下，與云端節(jié)點并不處于同一網(wǎng)絡(luò)平面，所以kubernetes CNI的方案并不能遷移到邊緣計算平臺上。為了滿足生產(chǎn)過程中的實際需求，研究并設(shè)計了邊緣服務(wù)網(wǎng)關(guān)組件，可以和邊緣計算平臺結(jié)合，幫助平臺打通云端向邊緣服務(wù)訪問的通道，其需要具備的功能如圖1所示。一是能夠與邊緣計算平臺的服務(wù)注冊中心數(shù)據(jù)交互，發(fā)現(xiàn)服務(wù)；二是能夠為邊緣計算平臺建立訪問邊緣服務(wù)的通道。

圖1 引入邊緣服務(wù)網(wǎng)關(guān)的邊緣計算平臺圖

2.1 架構(gòu)設(shè)計

邊緣服務(wù)網(wǎng)關(guān)需要解決邊緣計算平臺如何在云端訪問邊緣節(jié)點的服務(wù)以及在弱網(wǎng)環(huán)境下保持連接的高效穩(wěn)定問題，通過以下設(shè)計完成上述目標(biāo)。雖然目前的云原生邊緣計算平臺均有邊云傳輸信道，但控制信道和數(shù)據(jù)信道的復(fù)用會影響控制信息的傳輸，影響系統(tǒng)的穩(wěn)定性。所以我們在邊云之間新建立一條云邊傳輸信道用于業(yè)務(wù)流量的傳輸。邊緣服務(wù)網(wǎng)關(guān)的架構(gòu)如圖2所示，由云端的邊緣網(wǎng)關(guān)(edgegateway)、隧道服務(wù)器(tunnel server)和邊緣的服務(wù)流(edge stream)組成。

圖2 邊緣服務(wù)網(wǎng)關(guān)架構(gòu)圖

由于邊緣節(jié)點可能處于內(nèi)網(wǎng)環(huán)境下，云端不能直接向邊緣節(jié)點發(fā)起訪問。所以本方案設(shè)計了edge stream組件，edge stream組件在邊緣節(jié)點加入集群后主動發(fā)起QUIC連接，加入集群期間保持連接，使得云端隨時能夠向此邊緣節(jié)點發(fā)送消息。edge stream負(fù)責(zé)把在云邊數(shù)據(jù)信道接收的消息轉(zhuǎn)發(fā)到對應(yīng)的pod實例上，并把pod的響應(yīng)轉(zhuǎn)發(fā)至云端。一個邊緣節(jié)點和云端只存在一個連接，連接建立后，云端對邊緣服務(wù)的請求都復(fù)用此通道。

數(shù)量眾多的邊緣節(jié)點與云端保持QUIC連接，Tunnel Serve負(fù)責(zé)存儲和管理所有邊緣節(jié)點連接到云端的QUIC連接，把邊緣節(jié)點的IP、Hostname和對應(yīng)的連接存儲進(jìn)長連接池。此連接即云邊數(shù)據(jù)信道，邊緣服務(wù)網(wǎng)關(guān)通過云邊數(shù)據(jù)信道發(fā)送用戶發(fā)起的請求和接收邊緣節(jié)點對用戶請求的響應(yīng)。當(dāng)其他組件需要發(fā)送消息時，Tunnel Server根據(jù)IP地址和hostname把對應(yīng)數(shù)據(jù)信道返回給發(fā)送方。

edgegateway負(fù)責(zé)接收用戶發(fā)起的請求，支持用戶自定義的負(fù)載均衡策略，根據(jù)負(fù)載均衡策略，從服務(wù)眾多pod實例中選擇其一，獲取pod實例的IP地址和端口號，根據(jù)pod實例的IP地址，從tunnel server獲取到對應(yīng)的數(shù)據(jù)信道，轉(zhuǎn)發(fā)用戶請求至邊緣，并把邊緣服務(wù)的響應(yīng)轉(zhuǎn)發(fā)給用戶。

2.2 方案功能實現(xiàn)

2.2.1 數(shù)據(jù)信道傳輸協(xié)議選擇

由于邊緣節(jié)點的網(wǎng)絡(luò)環(huán)境可能信號不佳，為了在弱網(wǎng)環(huán)境下也能保持邊緣服務(wù)的高效穩(wěn)定，邊緣服務(wù)網(wǎng)關(guān)選擇QUIC協(xié)議作為云邊信道的傳輸協(xié)議。

互聯(lián)網(wǎng)數(shù)據(jù)最常用的傳輸協(xié)議有TCP和UDP。UDP不需要建立連接，效率高，資源消耗少，但UDP可靠性不高。TCP協(xié)議可靠穩(wěn)定，但需要三次握手，建立連接時延高，系統(tǒng)資源消耗高。TCP/IP使用五元組(源IP、源PORT、目的IP、目的PORT、協(xié)議標(biāo)記符)來標(biāo)識一條連接，連接時如果連接一方的網(wǎng)絡(luò)狀態(tài)改變，如網(wǎng)絡(luò)競爭導(dǎo)致端口改變，或者用戶從無線網(wǎng)絡(luò)切換至蜂窩網(wǎng)絡(luò)，都需要重新建立連接。而QUIC協(xié)議為了支持網(wǎng)絡(luò)的移動性，它使用隨機(jī)生成的ID來標(biāo)識一條連接鏈路，所以QUIC協(xié)議不受網(wǎng)絡(luò)狀態(tài)的影響，支持網(wǎng)絡(luò)的無縫平滑遷移，減少了由于網(wǎng)絡(luò)中斷導(dǎo)致邊緣服務(wù)業(yè)務(wù)邏輯的中斷的發(fā)生[10]。

QUIC協(xié)議的優(yōu)勢還在于在一條連接上可以包含多個流，各個流共享連接信息，共同參與擁塞控制、數(shù)據(jù)加密，但并不存在依賴關(guān)系，解決了TCP的隊頭阻塞問題。QUIC還改善了擁塞控制，建立連接的時延也比TCP更短，加快了QUIC協(xié)議的傳輸速度。Choffnes D[11]等人用軟件模擬網(wǎng)絡(luò)環(huán)境，設(shè)定不同的帶寬、丟包率和時延，對比了QUIC和TCP在這些網(wǎng)絡(luò)下的網(wǎng)頁加載時間。實驗結(jié)果表明，在各種不同的網(wǎng)絡(luò)環(huán)境下，QUIC協(xié)議的網(wǎng)頁加載時間都比TCP更短。

2.2.2 方案流程實現(xiàn)

云端邊緣服務(wù)網(wǎng)關(guān)啟動時，先啟動edgegateway組件和tunnel serve組件，用戶可以自定義edgegateway和tunnel server監(jiān)聽的端口號，分別監(jiān)聽用戶請求和邊緣節(jié)點發(fā)起的QUIC請求。

每個邊緣節(jié)點加入集群時，啟動service stream組件，創(chuàng)建QUIC連接，云端的tunnel server監(jiān)聽到此QUIC連接，會把host IP和hostname為key保存這個連接。service stream會持續(xù)監(jiān)聽該連接，并根據(jù)接收到的消息，轉(zhuǎn)發(fā)該消息。

在邊緣服務(wù)網(wǎng)關(guān)啟動這三個組件之后，用戶可以通過邊緣服務(wù)網(wǎng)關(guān)訪問邊緣服務(wù)，其流程如圖3所示。

圖3 邊緣服務(wù)網(wǎng)關(guān)流程圖

1)用戶發(fā)起一個對邊緣服務(wù)的http訪問請求，http url的結(jié)構(gòu)為http://host:port://rest/of/path，主機(jī)為云端節(jié)點IP的地址，端口號為edgegateway監(jiān)聽的端口號。查詢路徑需要包括邊緣服務(wù)的命名空間和服務(wù)名稱，以及邊緣服務(wù)資源路徑。

2)edgegateway接收用戶發(fā)起的請求，通過連接請求中包含的服務(wù)命名空間和服務(wù)名稱，向kubernetes API server發(fā)起請求，發(fā)現(xiàn)服務(wù)實例，獲取到服務(wù)實例pod的IP地址和端口，通過IP地址向tunnel server查詢到QUIC連接。

3)edgegateway為當(dāng)前請求生成一個會話id，將http請求提取轉(zhuǎn)換成可序列的消息，并把這個消息寫入到查詢到的QUIC連接中。

4)邊緣側(cè)的service stream接收到請求后，根據(jù)步驟2獲得的端口號轉(zhuǎn)發(fā)請求到對應(yīng)的pod上。此pod為邊緣服務(wù)的實例。

5)edge stream把訪問pod請求結(jié)果寫回到對應(yīng)的QUIC連接發(fā)送給云端。

6)云端的tunnel server向edgegateway轉(zhuǎn)發(fā)響應(yīng)消息，edgegateway將此響應(yīng)消息轉(zhuǎn)發(fā)給用戶。

3 邊緣服務(wù)網(wǎng)關(guān)測試

3.1 試驗環(huán)境

測試環(huán)境為某公有云廠商位于蘇州的公有云節(jié)點，帶寬為2M，公網(wǎng)IP地址為106.12.88.113，在云端節(jié)點部署了kubernetes v1.20.6，kubeedge v1.6.1以及邊緣服務(wù)網(wǎng)關(guān)的云端部分。邊緣節(jié)點為樹莓派，地處南京，位于內(nèi)網(wǎng)環(huán)境下IP地址為192.168.3.78，在邊緣端部署了kubeedge v1.6.1和邊緣服務(wù)網(wǎng)關(guān)的邊緣部分。通過kubernetes和kubeedge為平臺提供容器化應(yīng)用編排能力，能在云端部署應(yīng)用并將應(yīng)用下發(fā)到邊緣節(jié)點。

表1 節(jié)點信息

3.2 測試用例

為了驗證所設(shè)計的邊緣服務(wù)網(wǎng)關(guān)的功能和性能，以在云端實時操控處于內(nèi)網(wǎng)的小車運行為例：通過邊緣服務(wù)網(wǎng)關(guān)，在公有云節(jié)點上能實時操控小車的運行，并查看小車返回的實時監(jiān)控畫面。

3.2.1 測試實現(xiàn)

應(yīng)用微服務(wù)架構(gòu)，分為兩個服務(wù)：一是用戶訪問界面服務(wù)(pmlcarweb)，二是操控小車服務(wù)(pmlcaredge)。用戶訪問界面服務(wù)部署在云端節(jié)點，通過kubernetes網(wǎng)絡(luò)方案暴露服務(wù)，為用戶提供小車的監(jiān)控畫面和用戶操控小車的操作界面，用戶能在界面操作小車，并把參數(shù)下發(fā)到小車。用戶訪問界面服務(wù)需要從小車獲取監(jiān)控畫面返回給用戶。操控小車服務(wù)部署在邊緣節(jié)點小車上，實時接收用戶指揮小車的操控數(shù)據(jù)，并實時拍攝小車的運行畫面，以微服務(wù)的形式暴露出來。小車有兩條路徑，/picture負(fù)責(zé)處理請求拍攝的運行畫面的get請求，/drivingData負(fù)責(zé)接收post請求發(fā)送的行駛數(shù)據(jù)。

3.2.2 測試應(yīng)用參數(shù)選擇

pmlcarweb通過kubernetes的NodePort形式暴露出來。端口選擇為32500，用戶可以通過http://106.12.88.113:32500訪問此web服務(wù)。用戶操作界面上傳的數(shù)據(jù)會被下發(fā)到邊緣節(jié)點小車上。

用戶訪問界面服務(wù)可以通過邊緣服務(wù)網(wǎng)關(guān)的數(shù)據(jù)信道訪問到小車的拍攝畫面，以及將用戶上傳的操作數(shù)據(jù)下載到邊緣節(jié)點小車上。邊緣服務(wù)網(wǎng)關(guān)的tunnel server和edgegateway分別需要監(jiān)聽兩個端口，端口由用戶配置。此應(yīng)用選擇為tunnel server監(jiān)聽9090，edgegateway監(jiān)聽8080端口，所以URL為http://106.12.88.113:8080/default/pmlcarEdge/picture，get請求獲取小車運行畫面。http://106.12.88.113:8080/default/pmlcarEdge/drivingData發(fā)起post請求。default為服務(wù)的命名空間，pmlcarEdge為服務(wù)名稱，實施方案如圖4所示。

圖4 實驗方案描述圖

3.3 功能測試

用戶在瀏覽器發(fā)起http://106.12.88.113:31500/drive的請求，運行結(jié)果如圖5所示。用戶界面能夠顯示出在內(nèi)網(wǎng)的小車的拍攝畫面，云端服務(wù)平均每秒從邊緣服務(wù)獲取3張3 500字節(jié)的圖片，云端服務(wù)運行過程中能保持與邊緣服務(wù)不斷連，服務(wù)運行穩(wěn)定。應(yīng)用運行結(jié)果表明此邊緣服務(wù)網(wǎng)關(guān)能結(jié)合目前的邊緣計算平臺，幫助邊緣平臺實現(xiàn)云端用戶和服務(wù)訪問邊緣服務(wù)的功能。

圖5 應(yīng)用運行畫面

3.4 性能測試

目前，云邊通信常用的兩種全雙工傳輸協(xié)議為websocket和QUIC，比較邊緣服務(wù)網(wǎng)關(guān)分別選用兩種傳輸協(xié)議在網(wǎng)絡(luò)良好環(huán)境和極端弱網(wǎng)環(huán)境下的性能比較。

測試方案為在云端向小車發(fā)送100次小車拍攝圖像請求，比較數(shù)據(jù)信道使用websocket和QUIC協(xié)議的響應(yīng)時間。

網(wǎng)絡(luò)良好環(huán)境的測試如表2所示，在網(wǎng)絡(luò)良好的環(huán)境下，使用websocket和QUIC協(xié)議的性能幾乎沒有明顯差別。

表2 良好網(wǎng)絡(luò)環(huán)境

弱網(wǎng)環(huán)境是指網(wǎng)絡(luò)狀況欠佳、網(wǎng)絡(luò)延時高、丟包率高等。本測試使用工具tc來模擬弱網(wǎng)環(huán)境。tc是Linux系統(tǒng)的流量控制工具。tc通過對Network Emulator組件實現(xiàn)模擬丟包、延時。Network Emulator直接添加在網(wǎng)卡上，所有從網(wǎng)卡發(fā)送出去的包都會收到配置參數(shù)的影響。

使用tc模擬出一個丟包率40%的極端弱網(wǎng)環(huán)境，在此環(huán)境的基礎(chǔ)上測試邊緣服務(wù)網(wǎng)關(guān)使用QUIC和websocket，訪問邊緣服務(wù)的性能表現(xiàn)，如表3所示，兩種協(xié)議在弱網(wǎng)環(huán)境下的性能表現(xiàn)差異較大，QUIC有著比websocket更快的響應(yīng)時間和更高的響應(yīng)成功率。和良好網(wǎng)絡(luò)環(huán)境相比，QUIC協(xié)議的響應(yīng)時間僅增加19.45%，而websocket的響應(yīng)時間增加204%。

表3 弱網(wǎng)環(huán)境

測試顯示，在網(wǎng)絡(luò)狀況不好的情況下，使用QUIC是更好的選擇。

4 結(jié)語

文章分析了目前云原生邊緣計算平臺的邊云通信的研究現(xiàn)狀，分析得出邊緣計算平臺的邊云通信均支持管控流量的傳輸，但邊云協(xié)同并不只是簡單對應(yīng)用進(jìn)行部署和管理，云端需要具備對邊緣服務(wù)訪問的能力。針對此問題，文章提出了基于QUIC協(xié)議的邊緣服務(wù)網(wǎng)關(guān)的系統(tǒng)實現(xiàn)方案，實現(xiàn)方案具有通用性，不依賴于任何特定的邊緣計算平臺，可以實現(xiàn)從云端訪問邊緣服務(wù)，填補目前的邊緣計算平臺的此功能的空白，并對邊緣服務(wù)網(wǎng)關(guān)進(jìn)行相關(guān)的功能測試與性能測試。對測試結(jié)果進(jìn)行分析發(fā)現(xiàn)，邊緣服務(wù)網(wǎng)關(guān)能夠解決實際應(yīng)用的云端訪問邊緣服務(wù)問題，基于QUIC協(xié)議實現(xiàn)的服務(wù)訪問方案在網(wǎng)絡(luò)良好的環(huán)境與websocket實現(xiàn)的方案沒有明顯區(qū)別，在弱網(wǎng)環(huán)境下明顯優(yōu)于websocket協(xié)議實現(xiàn)的方案，相關(guān)性能指標(biāo)在2倍以上，在弱網(wǎng)環(huán)境下，依然具有良好的表現(xiàn)。