韓義波，王 超，郭士加，劉盛加

(南陽理工學(xué)院 河南 南陽 473004)

1 引入

數(shù)字化時代相互聯(lián)結(jié)的設(shè)備數(shù)量急劇增長，移動物聯(lián)網(wǎng)帶動全球聯(lián)網(wǎng)設(shè)備數(shù)量在2020年突破240億，未來在2025年對全球經(jīng)濟增長影響力將達到11.1萬億美元，占全球GDP的11%，這一顛覆性的時代被稱為物聯(lián)網(wǎng)(Internet of Things，IoT)時代，引起了學(xué)術(shù)界和行業(yè)界的廣泛關(guān)注。目前，物聯(lián)網(wǎng)應(yīng)用面臨的最大問題之一是物聯(lián)網(wǎng)設(shè)備在硬件、網(wǎng)絡(luò)和平臺方面的異構(gòu)性，且每個物聯(lián)網(wǎng)設(shè)備通過唯一的地址與其他設(shè)備通信，需要傳輸、處理和存儲這些設(shè)備產(chǎn)生的數(shù)據(jù)；再者，大多數(shù)物聯(lián)網(wǎng)設(shè)備能量、計算能力(如CPU、內(nèi)存)有限[1]，因此，支持設(shè)備數(shù)量日益增長的管理平臺必不可少，以協(xié)調(diào)巨量的物聯(lián)網(wǎng)設(shè)備并處理其產(chǎn)生的數(shù)據(jù)。

物聯(lián)網(wǎng)設(shè)備具備可移動的特性，但計算能力受限。為了解決能源和性能問題，云計算和邊緣計算助力物聯(lián)網(wǎng)設(shè)備，通過任務(wù)卸載來保證物聯(lián)網(wǎng)服務(wù)的提供。卸載將計算從資源有限的移動設(shè)備轉(zhuǎn)移到資源豐富的邊緣結(jié)點或云節(jié)點，以提高物聯(lián)網(wǎng)應(yīng)用的執(zhí)行性能和整體能效。任務(wù)卸載已在許多領(lǐng)域得到應(yīng)用，如運輸、醫(yī)療保健、家庭和工廠等[2]。另外，任務(wù)卸載對于流處理、增強現(xiàn)實、在線游戲和視頻會議等應(yīng)用尤其有效[3]，此類應(yīng)用對延遲非常敏感，需要高質(zhì)量的服務(wù)和用戶體驗。這種場景下，將數(shù)據(jù)從終端設(shè)備傳輸?shù)皆浦芯桶殡S著卸載處理，并且因應(yīng)用而異，如有些應(yīng)用屬計算資源密集性，通信量低；而有些應(yīng)用通信量高，而計算資源需求低，加上終端設(shè)備的移動性特點，部分區(qū)域設(shè)備和用戶數(shù)量可能猛增，這更加劇了任務(wù)卸載的復(fù)雜度[4]。

物聯(lián)網(wǎng)工作負(fù)載牽涉大量需要實時處理與分析的跨區(qū)域數(shù)據(jù)流和控制流。目前應(yīng)對此類問題的有效方法是利用網(wǎng)絡(luò)邊緣小規(guī)模訪問點為云資源的補充，這些訪問點位于鄰近移動用戶的可通信范圍內(nèi)，其提供PC或集群之類的小規(guī)模但資源豐富的中間設(shè)備，例如，包括Cloudlet[5]、CloudAP[6]和其他系統(tǒng)[7]在內(nèi)的獨立多層體系架構(gòu)，旨在支持延遲敏感的應(yīng)用程序，同時最小化總體服務(wù)時間。然而，Cloudlet與云中心缺乏集成和有效協(xié)調(diào)，服務(wù)質(zhì)量無法充分保證。為此，采用編排器(Orchestrator)協(xié)助的物聯(lián)網(wǎng)應(yīng)用通過不同的編排算法改進邊云環(huán)境中的智能任務(wù)卸載[8]。然而，不同的卸載架構(gòu)和策略如何定量地影響物聯(lián)網(wǎng)應(yīng)用和服務(wù)的端到端性能，尤其當(dāng)資源模式和任務(wù)特征的動態(tài)性表現(xiàn)出來時，仍然是一個未知數(shù)。

本文著重分析并實驗證明兩個問題：不同的邊云架構(gòu)如何影響任務(wù)卸載期間的整體IoT服務(wù)時間，以及不同的應(yīng)用參數(shù)(如計算和通信需求)如何影響整體效率。為便于分析，將基本卸載方案分為兩種不同的類型：松散耦合(Loosely-Coupled,LC)三層架構(gòu)、編排器支持(Orchestrator-Enabled)三層架構(gòu)；進而，考慮層間不同層間網(wǎng)絡(luò)連接所產(chǎn)生的通信延遲和計算資源的分配狀況，通過性能驅(qū)動建模，比較兩種架構(gòu)對物聯(lián)網(wǎng)服務(wù)執(zhí)行的影響；此外，考慮到不同的任務(wù)特性，提出了3種卸載策略(靜態(tài)比率策略、最小加載策略和概率策略)以尋求最優(yōu)編排方案。本文的主要內(nèi)容總結(jié)如下：(1)統(tǒng)籌考慮計算、通信資源兩種因素，提出一種性能驅(qū)動的端到端IoT服務(wù)有效性度量方法。(2)深入研究松散耦合和編排器支持的卸載方案的系統(tǒng)行為。(3)為滿足不同IoT應(yīng)用需求并實現(xiàn)最優(yōu)卸載策略，提供了一套模型和算法。(4)提出不同約束條件下IoT任務(wù)卸載策略評價方法，可用于提高邊云環(huán)境下任務(wù)卸載效率、實現(xiàn)資源均衡管理。

2 國內(nèi)外研究現(xiàn)狀

邊云計算環(huán)境下的服務(wù)時間問題受到了研究界的廣泛關(guān)注。關(guān)于服務(wù)時間的現(xiàn)有文獻非常廣泛，但主要集中在計算延遲、通信延遲或兩者兼有，下述文獻研究了服務(wù)時間與其他目標(biāo)，如能耗和代價。Dinh等人[9]提出了一個框架，通過將任務(wù)卸載到多個邊緣結(jié)點來最小化移動設(shè)備的計算延遲和能耗；Du等人[10]提出一種算法來保證霧或云計算系統(tǒng)中可接受的計算延遲；Liu等人[11]考慮排隊和執(zhí)行狀態(tài)情況下，設(shè)計了任務(wù)調(diào)度算法用于減少整體延遲；Rodrigues等人[12]提出一種混合方法，通過加強計算和通信資源的處理來最小化端到端延遲，該方法聚焦于虛擬機的遷移和傳輸延遲。Wei等人[13]提出一種算法，旨在通過同時考慮傳輸功率和處理頻率來減少延遲；Yang等人[14]提出一種通過保證最大化允許時間和降低執(zhí)行代價支持延遲敏感應(yīng)用的方法；Zeng等人[15]提出一種基于負(fù)載均衡和任務(wù)鏡像分配的任務(wù)完成時間最小化算法。

從應(yīng)用程序方面講，邊云支持的IoT應(yīng)用在計算和通信需求及動態(tài)需求方面各不相同，且關(guān)于邊云支持的IoT應(yīng)用類型方面的文獻較少。Fan和Ansari[16]特別考慮應(yīng)用類型提出了一種應(yīng)對計算和通信延遲的方法，該方法將卸載任務(wù)分配給邊云系統(tǒng)中的合適資源。Roy等人[17]提出了一種基于應(yīng)用具體要求選擇目標(biāo)邊緣節(jié)點的策略，以最小化延遲和功耗。盡管上述研究是針對延遲敏感的IoT應(yīng)用進行的，但在最小化整體服務(wù)時間背景下，不同邊云部署策略的影響沒有得到深入的研究。

雖然一些研究集中在服務(wù)時延和一些重要的應(yīng)用規(guī)范上，但對于不同的邊緣架構(gòu)如何影響系統(tǒng)性能，特別是總體服務(wù)時間，仍然缺乏科學(xué)的理解。邊緣計算系統(tǒng)的不同架構(gòu)在文獻中已有描述，這些架構(gòu)都具備將計算資源推向近用戶端的共同特點，不同主要表現(xiàn)在邊緣結(jié)點和邊緣網(wǎng)絡(luò)中，包括部署、網(wǎng)絡(luò)技術(shù)和邊緣結(jié)點特征，如大小、位置及如何與云中心通信等，從服務(wù)提供者和應(yīng)用開發(fā)者角度考慮，這些差異都是最小化整體延遲的重要因素。

3 研究場景和術(shù)語定義

為方便關(guān)鍵問題和目標(biāo)的描述，本節(jié)簡要介紹相關(guān)基本術(shù)語和概念。

3.1 IoT場景中資源與工作負(fù)載

3.1.1 邊云環(huán)境中資源實體

邊云環(huán)境基本實體包括終端設(shè)備(Things)、邊緣結(jié)點(Edge Nodes)和云結(jié)點(Cloud Nodes)。終端設(shè)備包括傳感器和帶內(nèi)置傳感器的設(shè)備，可以監(jiān)控并產(chǎn)生大量數(shù)據(jù)；云結(jié)點提供數(shù)據(jù)存儲和并行計算能力；邊緣結(jié)點定義為駐留在終端設(shè)備和云中心之間的特定設(shè)備，作為代理部署在更靠近終端設(shè)備的地方，提供計算、存儲和網(wǎng)絡(luò)資源，同時，邊緣結(jié)點匯聚一系列傳感器的數(shù)據(jù)并傳輸?shù)奖镜鼐彺鏀?shù)據(jù)、執(zhí)行負(fù)載均衡的中心計算系統(tǒng)中。從功能上看，與云數(shù)據(jù)中心的結(jié)點相比，邊緣結(jié)點具有相對較小的計算能力和地理上分布的特點，其重要意義在于骨干網(wǎng)絡(luò)訪問暫時不可用情況下，也能為終端設(shè)備持續(xù)提供高準(zhǔn)確率和低延遲網(wǎng)絡(luò)服務(wù)。

3.1.2 IoT工作負(fù)載

完整的IoT工作負(fù)載通常由封裝于獨立容器內(nèi)的一組IoT任務(wù)組成。所有容器運行在物理機或虛擬機之上，相互連接形成功能鏈以更好地滿足應(yīng)用需求。從形式上講，IoT應(yīng)用可用有向無環(huán)圖(Direct Acyclic Graph，DAG)工作流描述，其中的每個頂點代表一個IoT任務(wù)，如圖1所示的e-健康應(yīng)用，該應(yīng)用可分為多個獨立但又聯(lián)合工作的微服務(wù)[18]；具體來說，移動健康子系統(tǒng)具有遠程監(jiān)控、實時數(shù)據(jù)分析、緊急報警等功能，數(shù)據(jù)從監(jiān)測病人關(guān)鍵體征的傳感器上收集并持續(xù)發(fā)送給數(shù)據(jù)匯聚結(jié)點，一旦發(fā)現(xiàn)異常狀態(tài)數(shù)據(jù)，醫(yī)務(wù)人員可立即得到通知并采取合適的措施；更一般地說，這些獨立物聯(lián)網(wǎng)任務(wù)的合理組合可用于實現(xiàn)更高級的功能，從而降低成本和改善用戶體驗。

圖1 物聯(lián)網(wǎng)應(yīng)用示例：e-健康系統(tǒng)工作流

3.1.3 IoT部署與任務(wù)卸載

IoT應(yīng)用部署的主要目標(biāo)是把每一個IoT任務(wù)放置在邊云環(huán)境中合適的位置(如IoT設(shè)備、邊緣結(jié)點、云結(jié)點)執(zhí)行。為了比較準(zhǔn)確地獲取延遲并建模，假設(shè)每個任務(wù)具有兩個主要屬性：發(fā)送或接收邊云系統(tǒng)的數(shù)據(jù)量和計算需求量(包括CPU、內(nèi)存、GPU等)，也就是說，資源分配要保證所有的IoT任務(wù)有足夠的資源執(zhí)行其計算邏輯。同時，數(shù)據(jù)可以在不同的任務(wù)之間生成和傳輸。如前所述，邊云組合允許在邊云之間交付卸載任務(wù)和遷移數(shù)據(jù)[19]。

任務(wù)卸載主要負(fù)責(zé)將計算從資源受限的移動設(shè)備上轉(zhuǎn)移到資源豐富的邊緣結(jié)點或云結(jié)點上，以提高移動應(yīng)用的執(zhí)行性能和整體能效。用戶設(shè)備均勻處于網(wǎng)絡(luò)邊緣，可通過WLAN或4G/5Gm網(wǎng)絡(luò)將計算卸載到邊緣或云結(jié)點。一般來說，若單個邊緣結(jié)點資源不足于處理激增的工作負(fù)載，其他邊緣結(jié)點或云結(jié)點隨時可以提供協(xié)助。

3.2 研究問題和挑戰(zhàn)

3.2.1 問題描述

采用移動設(shè)備能夠更好地實現(xiàn)IoT服務(wù)，然而，移動設(shè)備在計算、存儲、電源等方面嚴(yán)重受限，尤其在支持如增強現(xiàn)實(Augmented Reality，AR)和人工智能(Artificial Intelligence，AI)輔助的多媒體應(yīng)用等資源密集型應(yīng)用時。這種情況下，應(yīng)用程序迫切需要低響應(yīng)延遲和高帶寬吞吐量，為實現(xiàn)這一目標(biāo)，提出了不同的跨云、邊云架構(gòu)，以實現(xiàn)移動設(shè)備、邊緣結(jié)點和云資源之間的協(xié)調(diào)機制。

網(wǎng)絡(luò)邊緣側(cè)加入資源是解決協(xié)調(diào)問題的基本和普遍接受的方法，例如為了降低骨干網(wǎng)流量和最小化響應(yīng)延遲，把計算、帶寬和存儲資源移近物聯(lián)網(wǎng)終端設(shè)備。相比之下，計算密集型任務(wù)卸載到云數(shù)據(jù)中心，通過并行處理進行加速。然而，有許多因素會直接或間接影響任務(wù)卸載的有效性和效率，有必要根據(jù)相關(guān)因素對性能的影響進行量化分析和建模，并對不同的卸載策略進行比較。此外，IoT應(yīng)用在計算、通信需求以及當(dāng)前資源的供給上存在著固有的差異，有必要采用不同的任務(wù)卸載模式研究和評價不同IoT工作負(fù)載行為的差異，評估不同方案和不同IoT工作負(fù)載之間的關(guān)系有助于通過減少端到端服務(wù)時間，從而提高服務(wù)質(zhì)量。

3.2.2 新挑戰(zhàn)

隨著IoT應(yīng)用種類和數(shù)量的不斷增加，出現(xiàn)了一些新的挑戰(zhàn)，具體如下。

(1)規(guī)模與復(fù)雜性

隨著IoT制造商開發(fā)的異構(gòu)傳感器和智能設(shè)備數(shù)量和種類的不斷增加，再加上定制化硬件配置和個性化需求，混合云環(huán)境下選擇最優(yōu)資源承載IoT任務(wù)變得更加復(fù)雜。例如，一些任務(wù)只能在特定的硬件架構(gòu)(ARM或Intel)或操作系統(tǒng)下運行，而有高安全要求的任務(wù)可能還需要特定的硬件和協(xié)議才能實現(xiàn)。

(2)動態(tài)性

動態(tài)性是IoT應(yīng)用的主要特征之一，即其拓?fù)浣Y(jié)構(gòu)或多樣性的資源可能會動態(tài)變化，這是因軟件升級和網(wǎng)絡(luò)對象頻繁加入、離開帶來的問題，會引起IoT應(yīng)用內(nèi)部屬性和性能的變化，還存在著整體工作模式改變的可能。具體地說，通信鏈路可能受到帶寬、連接和設(shè)備移動性波動的影響，導(dǎo)致云和邊緣結(jié)點上不可預(yù)測的任務(wù)卸載和資源分配需求。

(3)可伸縮性

可伸縮性是挑戰(zhàn)的另一方面，具體指處理IoT應(yīng)用數(shù)量猛增和動態(tài)資源變化的能力。此外，IoT任務(wù)的屬性會動態(tài)變化，因此每個任務(wù)的處理過程可能有不同的執(zhí)行時間；再者，IoT設(shè)備是移動的，在某些區(qū)域IoT設(shè)備的數(shù)量可能會增加，那么連接的邊緣結(jié)點工作負(fù)載將增加，因此，IoT工作負(fù)載會在邊云系統(tǒng)上動態(tài)的變化，有可能導(dǎo)致服務(wù)性能的下降。

面對不斷增加、動態(tài)變化的工作流，任務(wù)編排可以解決上述挑戰(zhàn)。編排器是由云資源、邊緣結(jié)點和終端用戶設(shè)備等組成的集成系統(tǒng)，同時考慮地理分布和約束，具備正確、高效提供復(fù)雜服務(wù)的能力；更重要的是，編排器還能夠自動預(yù)測、檢測和解決因應(yīng)用規(guī)模增大而可能出現(xiàn)的可伸縮性瓶頸。綜上所述，邊云系統(tǒng)基于中心資源管理器及一定的策略分配物理資源給所有IoT任務(wù)，并根據(jù)運行時系統(tǒng)狀態(tài)卸載任務(wù)到最優(yōu)目的地以明顯提高應(yīng)用程序性能。下文將重點考慮上述挑戰(zhàn)，研究、分析不同的邊云系統(tǒng)架構(gòu)和環(huán)境參數(shù)如何影響任務(wù)卸載的整體有效性和效率。

4 研究方法

通常，邊云系統(tǒng)支持的IoT應(yīng)用包含3層：終端設(shè)備層、邊緣層和云(數(shù)據(jù)中心)層。邊緣層由大量地理上分布、通過核心網(wǎng)連接云層的邊緣結(jié)點組成；相似的，終端用戶設(shè)備直接連接邊緣接點；值得注意的是，邊緣節(jié)點和云節(jié)點之間的網(wǎng)絡(luò)帶寬和通信效率是導(dǎo)致物聯(lián)網(wǎng)設(shè)備性能差異的主要因素之一。本研究的目標(biāo)是衡量邊云系統(tǒng)中任務(wù)卸載對IoT服務(wù)性能的影響，因此，本文分別在兩種架構(gòu)和3種策略中，使用端到端服務(wù)時間作為性能度量標(biāo)準(zhǔn)。

4.1 物聯(lián)網(wǎng)邊云系統(tǒng)主流架構(gòu)

主流的物聯(lián)網(wǎng)邊云系統(tǒng)架構(gòu)可歸結(jié)為兩類：松散模式和編排器支持模式(如圖2所示)。

圖2 兩種代表性跨云IoT服務(wù)注：兩圖分別代表松散耦合三層模式(左)和編排支持三層模式(右)

4.1.1 松散耦合(LC)三層模式

這種架構(gòu)下，IoT應(yīng)用可以部署在連接的邊云結(jié)點上，若移動設(shè)備沒有足夠的執(zhí)行能力，則應(yīng)用生成的任務(wù)可以調(diào)度到邊緣結(jié)點執(zhí)行，調(diào)度決策過程相當(dāng)快，如同路由器的路由一樣，因此，幾乎所有情形下的卸載開銷都可以忽略，這種模式被一些研究工作所采用[16-18]。顯然，這種模式下，只能基于靜態(tài)策略(如固定比例和時間間隔)將任務(wù)卸載到嚴(yán)格限制的結(jié)點中。由于用戶的移動性，任務(wù)處理量的增加或減少是必然的，因此，只有在平衡的場景下，即每個節(jié)點配備性能相近的硬件、處理相似數(shù)量的終端設(shè)備等，該策略能夠以更高的穩(wěn)定性和可用性很好地運行。實際上，運行時移動設(shè)備的工作負(fù)載可以被卸載到僅一個目標(biāo)結(jié)點順序執(zhí)行或多個服務(wù)結(jié)點并行執(zhí)行。

該方案忽視了任務(wù)資源需求的多樣性；缺少邊云基礎(chǔ)設(shè)施間的協(xié)作，由于采用靜態(tài)分區(qū)和交付機制，一旦任務(wù)被卸載到一個結(jié)點上，便失去了根據(jù)任務(wù)的具體特點進行調(diào)整的機會。

4.1.2 編排支持(OE)三層模式

IoT應(yīng)用可以部署到受邊緣編排器控制的多個邊云結(jié)點上，編排器是位于邊緣和云中心之間的中央調(diào)度器。該方案提供靈活界面，用戶可以根據(jù)上層需求或應(yīng)用特點定制任務(wù)調(diào)度的優(yōu)化策略。本文在編排器中引入兩種實用策略：最小負(fù)載策略和概率策略，具體在4.2節(jié)中詳述。

邊緣編排器是一個關(guān)鍵組件，它管理與邊云節(jié)點相關(guān)的資源，并通過將每個任務(wù)與特定資源綁定來分派IoT任務(wù)。一個高效的任務(wù)分配算法決定了任務(wù)卸載的目的地，對任務(wù)再分配的可靠性、可用性和成本效率起著決定性的作用。根據(jù)數(shù)學(xué)模型和優(yōu)化方法，文獻[20]將卸載算法分為5類：0-1整數(shù)線型規(guī)劃、K維裝箱、馬爾科夫決策過程、凸優(yōu)化問題和Lyapunov化問題，由于求解多維裝箱問題算法具有指數(shù)級的時間復(fù)雜度，而上述算法幾乎都是求解NP-hard問題。因此，需要通過考慮各種工作負(fù)載規(guī)模和類型來實現(xiàn)算法精度和時間復(fù)雜度之間的平衡，文獻[21-23]等大量研究利用這種模式支持IoT應(yīng)用。

4.1.3 比較

LC模式僅是將物聯(lián)網(wǎng)設(shè)備與附近的邊云節(jié)點連接起來，以實現(xiàn)任務(wù)卸載。一旦某個任務(wù)被卸載到某個特定的結(jié)點，任務(wù)不能進一步移動，即使該結(jié)點的任務(wù)隊列較長。也就是說，任務(wù)沒有機會利用其他理想邊云結(jié)點的資源，即使該結(jié)點當(dāng)前沒有足夠容量承載全部任務(wù)。LC機制允許任務(wù)等待執(zhí)行，直至足夠的有效資源被釋放，或者基于靜態(tài)策略將任務(wù)卸載至相應(yīng)的云中心結(jié)點。顯然，任務(wù)卸載是單向的，不能在不同邊云基礎(chǔ)設(shè)施間協(xié)作平衡。

相反，OE模式中的任務(wù)卸載過程更具策略性，其中優(yōu)化目標(biāo)可通過之前定義的規(guī)則和策略實現(xiàn)。這種情況下，首先生成IoT任務(wù)，然后通過移動設(shè)備發(fā)送以利用邊云資源到邊緣編排器，之后邊緣編排器接收和路由任務(wù)，以便基于策略(如最小負(fù)載策略和概率策略)將它們分發(fā)到接近最優(yōu)的邊云結(jié)點上。邊緣編排器處于AP(Access Points)、邊緣和云之間，意味著編排器不僅能控制移動終端設(shè)備和邊緣結(jié)點間的通信，而且能控制邊緣結(jié)點與云中心結(jié)點間的流量；接下來，邊緣編排器能夠基于前述指定的卸載算法，考慮諸如資源有效性和預(yù)期延遲等不同約束，將接收到任務(wù)指定給擁有適量資源、接近最優(yōu)的邊緣接點。邊緣編排器中的這些策略能夠在運行時有效地處理動態(tài)任務(wù)卸載，并考慮實時利用率和作業(yè)特征；還提供任務(wù)劃分功能，并通過多個邊云結(jié)點并行運行以加速后續(xù)任務(wù)的執(zhí)行；此外，各個邊緣基礎(chǔ)設(shè)施可通過編排器協(xié)同工作。

4.2 卸載策略

有效的卸載策略是可行的IoT架構(gòu)的關(guān)鍵環(huán)節(jié)之一，它直接影響IoT系統(tǒng)的有效性、可靠性和穩(wěn)定性等。因此，本文引入幾個定制化卸載策略以滿足延遲敏感IoT應(yīng)用的各種需求，這些策略也可以兼容地部署到其他現(xiàn)有的IoT系統(tǒng)中。

4.2.1 靜態(tài)比率策略

這種策略基于靜態(tài)比率做任務(wù)卸載決策，如任務(wù)百分比和時間間隔。由于采用的卸載策略邏輯等同，OE與LC中運行的效果類似。

算法1描述了調(diào)度閾值的固定任務(wù)百分比。代碼第1～3行說明了將新任務(wù)tasknew分派到特定邊緣結(jié)點edgecur的條件，即邊緣結(jié)點的可用資源edgecur.res能夠滿足任務(wù)請求tasknew.req，并且任務(wù)卸載到當(dāng)前選中結(jié)點的百分比edgecur.ratio不能超過之前定義的閾值τratio；否則，任務(wù)需要卸載到云cloudentrance執(zhí)行，即使邊緣結(jié)點當(dāng)前未被占用(第6行)。

算法1:靜態(tài)比率策略要求:edgecur.ratio:已卸載到當(dāng)前邊緣結(jié)點任務(wù)的最新 比率條件:edgecur或cloudentrance

算法1:靜態(tài)比率策略1: if edgecur.res≥tasknew.req and edgecur.ratio≤τratio2: edgecur.res←edgecur.res-tasknew.req3: tasknew.location←edgecur.address //分派任務(wù)tasknew到邊緣結(jié)點edgecur4: return edgecur5: else6: tasknew.location←cloudentrance.address //卸載任務(wù)tasknew到云cloudentrance7: return cloudentrance8: end if

這種背景下，大量的IoT應(yīng)用強調(diào)移動設(shè)備和邊緣結(jié)點中的資源短缺問題，該策略在解決邊云結(jié)點間的資源不平衡量問題發(fā)揮著有效作用，因為它保證每個資源單元處理近似相等的任務(wù)，邊云節(jié)點間的任務(wù)數(shù)量和性能與硬件相當(dāng)，實現(xiàn)資源占用的公平性。同時，該策略開銷相當(dāng)廉價，與原始系統(tǒng)相比可以忽略，因此被廣泛地應(yīng)用于底層基礎(chǔ)設(shè)施。

4.2.2 最小負(fù)載策略

此策略根據(jù)運行時負(fù)載信息決定任務(wù)的分配，以便選擇負(fù)載最小的結(jié)點卸載任務(wù)，同時，邏輯簡單、實施可行，被大多數(shù)系統(tǒng)優(yōu)先完全支持，非常適合于應(yīng)用數(shù)量和任務(wù)執(zhí)行時間都適中的中型場景。

該策略的主要過程可用算法2描述。首先，從當(dāng)前邊緣和云結(jié)點中全部可訪問的虛擬或物理機選擇最小負(fù)載的機器(第2行)，如果選中的最優(yōu)機器mopt具有足夠的資源滿足任務(wù)需求，決策過程分派任務(wù)tasknew到機器mopt(第3～6行)；否則，從全集M(第8行)刪除上述機器mopt并觸發(fā)新一輪選擇(第1～10行)。

算法2:最小負(fù)載策略要求:M:符合負(fù)載度量標(biāo)準(zhǔn)的所有邊云結(jié)點(包括虛擬機)條件:mopt:承載最小負(fù)載的最優(yōu)結(jié)點1: while tasknew.location is null do2: mopt←{m|loadm≤loadmi, mi∈M }3: if mopt.res≥tasknew.req then4: mopt.res←mopt.res-tasknew.req5: tasknew.location ←mopt .address //分派任務(wù)tasknew到機器mopt6: return mopt 7: else8: M← M-mopt9: end if10:end while

然而，該策略嚴(yán)重依賴高性能監(jiān)視器，需要實時跟蹤位于邊云中整個虛擬機或物理機的負(fù)載，一旦監(jiān)視器崩潰或執(zhí)行能力弱，如監(jiān)視數(shù)據(jù)準(zhǔn)確性差，這種策略就不能令人滿意地工作。除此之外，收集不同度量標(biāo)準(zhǔn)的運行時值時注入的過多開銷也是不可接受的。因此，該策略有兩個方面的嚴(yán)格要求：確保監(jiān)控信息數(shù)據(jù)穩(wěn)定傳輸?shù)木W(wǎng)絡(luò)；通過調(diào)用專用硬件的硬件接口，保證以低廉的代價采集度量標(biāo)準(zhǔn)數(shù)據(jù)。

4.2.3 概率策略

該策略中，IoT任務(wù)行為可視為馬爾可夫隨機過程，其中一系列事件的概率僅依賴于前一事件的狀態(tài)，數(shù)學(xué)公式可描述為

P(Xn+1=x|X1=x1,X2=x2,…,Xn=xn)=P(Xn+1=x|Xn=xn)

概率策略旨在根據(jù)每一對IoT任務(wù)間的條件概率優(yōu)化其分配，然而，由于IoT任務(wù)的復(fù)雜性和不確定性，定義一個嚴(yán)格的等式來描述IoT任務(wù)的發(fā)生模型是不可行的。直觀地說，基于大數(shù)定理進行P(Xn+1=x|Xn=xn)建模處理是方法之一，其中P(Xn+1=x|Xn=xn)值可通過觀察值估計，如t1、t2、t3分別代表任務(wù)1、2、3，則建模過程可用任務(wù)t1后緊跟t2來近似P(t1|t2)，表示任務(wù)t2發(fā)生的條件下，任務(wù)t1的出現(xiàn)概率，同理，可用P(t1|t3)、P(t2|t1)、P(t2|t3)、P(t3|t1)、P(t3|t2)表示相應(yīng)任務(wù)發(fā)生的條件概率。

算法3:概率策略要求:Mpt:條件概率矩陣條件:mopt:為新任務(wù)tasknew選擇包括利用率、傳輸?shù)瘸杀咀畹偷淖罴呀Y(jié)點1: Mpt←{P(ti|tj)=Countti|tjCounttj|ti,tj∈T } //根據(jù)ti|tj和tj的計數(shù),輸出由每對任務(wù)的條件概率組成的矩陣2: T′←φ 3: for all P∈Mpt do

算法3:概率策略4: T′←T′∪ {t|P(t|tasknew )≥τprobability}5: end for6: T″← T′∪ tasknew7: multilevel sorting(T″) //按照延遲敏感度、邊緣結(jié)點利用、云結(jié)點利用情況及輸入大小對任務(wù)排序8: for all t∈T″ do9: let mopt←null10: if t is delay-sensitive then11: mopt←edgeleast-cost //為延遲敏感性任務(wù)t分配代價最小的邊緣結(jié)點12: else 13: mopt←cloudleast-cost //為非延遲敏感性任務(wù)t分配代價最小的云結(jié)點14: end if15: if t is tasknew then16: t.location←mopt.address //分派任務(wù)t到mopt結(jié)點 17: return mopt18: else19: Virtually delete allocated resources20: end if21: end for

4.3 性能評估

4.3.1 端到端服務(wù)時間

本研究將整體端到端服務(wù)時間分為獨立的可測量部分。一般邊云系統(tǒng)包括IoT設(shè)備、邊緣結(jié)點和云結(jié)點(如圖2)。計算(如CPU和GPU等)和通信網(wǎng)絡(luò)帶寬是兩個可分配的資源類型。IoT設(shè)備相互連接，通過WAN(Wide Area Network)與邊緣結(jié)點通信。通常每個地點都有一個Wi-Fi訪問點覆蓋，該訪問點連接到相關(guān)的WLAN(Wireless Local Area Network)。移動設(shè)備一旦進入相應(yīng)的Wi-Fi覆蓋區(qū)域，便可持續(xù)向邊緣結(jié)點發(fā)送任務(wù)請求。若某個請求被選中，通過Wi-Fi提供的訪問點使用WAN和MAN(Metropolitan Area Network)將請求傳輸?shù)竭吘壗Y(jié)點或云結(jié)點。由于工作負(fù)載的多樣化且高度依賴于IoT任務(wù)，因此任務(wù)在功能和非功能需求方面牽涉的數(shù)據(jù)傳輸(上傳或下載)或處理(輸入或輸出)可能大小不同且長度不可預(yù)測，如功能需求包括CPU核心數(shù)、功率供應(yīng)、通信帶寬等，非功能需求包括安全和訪問控制等。

4.3.2 評測

本文假設(shè)單個任務(wù)端到端服務(wù)時間可按計算時間和通信時間的總和計算。計算時間可進一步分為任務(wù)排隊時間Q和實際處理時間P。具體來說，任務(wù)排隊時間由邊緣節(jié)點排隊、中間邊緣結(jié)點排隊和云節(jié)點排隊組成，如Q← (Qedge，Qxedge，Qcloud)，實際處理時間用P←(Pedge，Pxedge，Pcloud)表示。同樣的，通信時間由數(shù)據(jù)上傳或下載的傳輸延遲和傳播延遲組成，傳輸延遲是將數(shù)據(jù)推送到鏈路上需要的時間，傳播時間是從發(fā)送者到接收者需要的時間。從上傳和下載角度看，定義通信時間開銷為上傳時間U←(UWLAN,UMAN,UWAN)和下載時間D←(DWLAN,DMAN,DWAN)，用于描述邊云3層架構(gòu)中產(chǎn)生的總體延遲。

直觀上看，邊緣結(jié)點擁有相對受限的計算資源，但可以以最小的網(wǎng)絡(luò)延遲提供網(wǎng)絡(luò)連接。相比之下，云結(jié)點利用云資源池處理大數(shù)據(jù)，從而縮短處理時間。然而，通信時間高度依賴任務(wù)是否卸載到邊緣結(jié)點、協(xié)作邊緣結(jié)點或云結(jié)點進行處理，顯然，卸載任務(wù)到最近的邊緣結(jié)點的通信時間最小，到云計算須經(jīng)歷更長的通信時間。因此，若進行邊云系統(tǒng)中的計算和通信時間建模，需要確定任務(wù)是在連接的邊緣結(jié)點、鄰近的協(xié)作邊緣結(jié)點還是云結(jié)點中處理。以下是使用邊云系統(tǒng)卸載任務(wù)的3種延遲模型。

(1)任務(wù)到本地邊緣服務(wù)器延遲：邊云系統(tǒng)中，卸載任務(wù)到邊緣結(jié)點所需的總服務(wù)時間為發(fā)送任務(wù)數(shù)據(jù)到邊緣結(jié)點、邊緣結(jié)點中排隊等候處理、任務(wù)處理和發(fā)送輸出結(jié)果到IoT設(shè)備的時間總和。假設(shè)終端設(shè)備到本地邊緣的連接在WLAN范圍內(nèi)，總延遲可以用公式(1)表示。

Ledge=∑UWLAN+Qedge+Pedge+DWLAN

(1)

(2)任務(wù)到協(xié)作邊緣服務(wù)器延遲：在協(xié)作邊緣結(jié)點中處理卸載任務(wù)的總服務(wù)時間可通過計算經(jīng)WLAN上傳任務(wù)數(shù)據(jù)到本地邊緣服務(wù)器、經(jīng)MAN上傳數(shù)據(jù)到協(xié)作邊緣服務(wù)器、排隊、處理和經(jīng)MAN、WLAN下載輸出到IoT設(shè)備的時間總和得出，總延遲時間可用公式(2)表示。

Lxedge=∑UWLAN+UMAN+Qxedge+Pxedge+DMAN+DWLAN

(2)

(3)任務(wù)到云計算中心延遲：為了計算云環(huán)境中卸載任務(wù)的總服務(wù)時間，應(yīng)該考慮經(jīng)過WLAN、MAN、WAN的網(wǎng)絡(luò)延遲以及排隊和處理時間，總延遲時間可用公式(3)表示。

Lcloud=∑UWLAN+UMAN+UWAN+Qcloud+Pcloud+DWAN+DMAN+DWLAN

(3)

5 評測

5.1 仿真設(shè)置

實踐中，由于框架的不同、移動終端設(shè)備和應(yīng)用的多樣性、計算服務(wù)的復(fù)雜性、通信協(xié)議的兼容性等原因，獨立邊云架構(gòu)下做實驗不是一個簡單易行的過程，而EdgeCloudSim是一個靈活、實用的仿真實驗平臺，支持各種不同的IoT場景和邊云架構(gòu)，EdgeCloudSim也可通過CloudSim的適當(dāng)調(diào)整而實現(xiàn)。EdgeCloudSim提供豐富的模型來表示某些具體的場景，如引入排隊模型來描述WLAN、MAN和WAN間、移動設(shè)備間、虛擬機CPU間的不同類型延遲。因此，本論文的實驗可以在仿真平臺中實際完成，研究和評測LC和OE三層架構(gòu)針對幾種IoT工作負(fù)載和不同策略的性能。

邊云環(huán)境中，有許多運行著不同應(yīng)用的IoT或移動設(shè)備，這些應(yīng)用由需要在邊云資源中處理的不同任務(wù)組成。邊緣結(jié)點分布于接近于終端設(shè)備的地方，本實驗假設(shè)每個邊緣結(jié)點覆蓋一個特定的區(qū)域，IoT或移動設(shè)備通過WLAN連接到最近的邊緣結(jié)點后，可以發(fā)送要卸載的任務(wù)，還假設(shè)有一個稱為邊緣編排器的結(jié)點管理著所有的邊緣結(jié)點。

表1顯示了仿真實驗的關(guān)鍵參數(shù)，每種架構(gòu)模式有一個云中心，連接3個分布式邊緣結(jié)點，每個邊緣結(jié)點處理位于其區(qū)域內(nèi)一定數(shù)量的IoT終端設(shè)備。對于每一個實驗，為了研究不同架構(gòu)和策略下，邊緣結(jié)點容量與應(yīng)用端到端服務(wù)時間的關(guān)系，移動設(shè)備數(shù)量從100個增加到700個，每次增加200個。IoT設(shè)備以泊松分布方式產(chǎn)生許多任務(wù)(或稱IoT工作負(fù)載)，因此，隨著IoT設(shè)備的增多，IoT工作負(fù)載也將增加。

表1 仿真關(guān)鍵參數(shù)

5.2 實驗方法

通常IoT工作負(fù)載對資源的依賴輕重程度是不同的，也就是說，依賴程度從低計算和通信需求(如醫(yī)療保健應(yīng)用)到高計算和通信需求(在線視頻游戲)變化。資源數(shù)量配置是重要的一步，下述實驗步驟受文獻[6]中討論的工作負(fù)載預(yù)測的不確定性啟發(fā)。

為了應(yīng)對實踐中可能遇到的應(yīng)用程序，定義工作負(fù)載的通信帶寬需求從0.25 MB到1 MB，增加步長為0.25 MB；計算需求從500 MIPS到4000 MIPS，增加步長為一倍，如表2所示。配置結(jié)果有16種不同的組合，標(biāo)記為不同的應(yīng)用或工作負(fù)載。符號App(x,y)表示應(yīng)用需要大約xMB網(wǎng)絡(luò)帶寬、占用大約yMIPS的CPU執(zhí)行。

表2 工作負(fù)載示例及中央處理單元(CPU)速度和帶寬相應(yīng)配置

5.3 服務(wù)時間與資源需求

本節(jié)驗證了不同數(shù)量移動終端設(shè)備情形下，IoT任務(wù)所需資源(CPU和網(wǎng)絡(luò))如何影響整體服務(wù)時間。如圖3所示，無論移動終端設(shè)備有多少，IoT應(yīng)用平均服務(wù)時間隨著CPU需求的增長而相應(yīng)地增加，且終端設(shè)備越少，波動越明顯。如當(dāng)移動終端設(shè)備是100時，App(1,4k)的端到端服務(wù)時間大約是App(1,500)的4倍，而當(dāng)移動設(shè)備終端等于700時，僅為App(1,500)的近2倍。直觀上看，當(dāng)對CPU的需求增加時，任務(wù)在CPU中的等待和處理時間也相應(yīng)增加。此外，隨著設(shè)備數(shù)量的增加，OE架構(gòu)中服務(wù)時間的增加稍微比LC架構(gòu)嚴(yán)重，因為當(dāng)不同資源實體間有更多的IoT任務(wù)等待協(xié)調(diào)時，邊緣編排器需要消耗更多的時間分配和調(diào)度。當(dāng)整個CPU內(nèi)核被承載的IoT任務(wù)固定和利用時，LC和OE架構(gòu)間的差異將大幅擴大。

圖3 不同CPU需求對服務(wù)時間的影響

相反，如圖4所示，當(dāng)任務(wù)的帶寬需求不同時，服務(wù)時間僅稍微增加，因為本試驗中網(wǎng)絡(luò)帶寬對IoT任務(wù)來說不是關(guān)鍵限制。換句話說，網(wǎng)絡(luò)資源或性能明顯足以處理幾乎所有的IoT任務(wù)。值得注意的是，當(dāng)終端設(shè)備數(shù)量接近700時，服務(wù)時間的增加比較明顯，網(wǎng)絡(luò)資源的有效分配將對服務(wù)時間和質(zhì)量發(fā)揮重要作用。

圖4 不同帶寬需求對服務(wù)時間的影響

實際上，LC模式僅僅找到單個結(jié)點實現(xiàn)任務(wù)卸載，一旦任務(wù)被卸載到特定的結(jié)點上，不能進一步移動。此外，如果沒有結(jié)點具備承載任務(wù)的能力，LC架構(gòu)系統(tǒng)不得不等待更多可用資源釋放，為掛起的任務(wù)騰出空間。與LC架構(gòu)系統(tǒng)相比，此過程在OE架構(gòu)系統(tǒng)需要較少的時間，因為OE模式能夠在運行時輕松地處理動態(tài)任務(wù)卸載，并執(zhí)行任務(wù)劃分，進而并行卸載到多個目標(biāo)結(jié)點。

綜上所述，與通信需求相比，計算需求對IoT應(yīng)用性能的影響更大；然而，當(dāng)系統(tǒng)規(guī)模擴大以容納更多的IoT設(shè)備時，通信帶寬將轉(zhuǎn)變成為主導(dǎo)性資源并成為直接影響整體性的基礎(chǔ)因素；另一方面，對于小任務(wù)和小規(guī)模卸載場景，LC卸載方法可以順利處理任務(wù)再分配需求；然而，當(dāng)物聯(lián)網(wǎng)任務(wù)在資源請求方面變得更大或卸載頻繁發(fā)生時，編排成為不同條件約束下優(yōu)化解決方案以實現(xiàn)最優(yōu)卸載部署的必要過程。

5.4 可擴展性和可用性

本節(jié)驗證兩種架構(gòu)和3種卸載策略下，服務(wù)時間如何隨IoT設(shè)備數(shù)量變化。從圖5中可以看出，當(dāng)源于IoT任務(wù)的資源請求相對較小時(如App(0.25,500))，即使在不同架構(gòu)和策略下，整體服務(wù)時間對終端設(shè)備數(shù)量的增加也不敏感。原因是在卸載過程對整體服務(wù)時間影響不大的情況下，無論卸載的最終目標(biāo)結(jié)點在哪里，邊云結(jié)點的當(dāng)前資源都足以處理這些被卸載的輕量任務(wù)。

圖5 不同卸載策略下不同應(yīng)用特征的服務(wù)時間

邊緣編排器通過考慮IoT任務(wù)具體特征，能夠基于定義的策略有效地為到來的任務(wù)尋找卸載結(jié)點；相比之下，對于有最大資源請求的App(1,4k)，不管是LC還是OE，服務(wù)時間都會伴隨終端設(shè)備數(shù)量的增加而急劇增加。顯然，OE架構(gòu)中的邊緣編排器需要花費稍長的時間協(xié)調(diào)邊云結(jié)點之間的資源，并隨之做出任務(wù)部署決策，比較App(1,500) 和App(1,4k)時，可以觀察到與圖5類似的現(xiàn)象。上述分析表明，不同的應(yīng)用對設(shè)備規(guī)模具有不同的敏感性，IoT服務(wù)提供者需要根據(jù)IoT應(yīng)用的邊云基礎(chǔ)設(shè)施配置的變化協(xié)調(diào)和指定合適的資源。

卸載策略作為核心階段，對任務(wù)卸載整體性能起著至關(guān)重要的影響。如圖6所示，采用概率策略的服務(wù)時間波動明顯，但大致徘徊在最小負(fù)載策略附近，有時介于靜態(tài)策略和最小負(fù)載策略之間。這種趨勢表明概率策略的穩(wěn)定性比最小負(fù)載策略的穩(wěn)定性要弱，在任務(wù)調(diào)度方面還需進一步改進。

圖6 超參數(shù)調(diào)整

最小負(fù)載策略完全依賴于運行時的負(fù)載信息，因此執(zhí)行穩(wěn)定、有效。CPU負(fù)載是任務(wù)執(zhí)行的最關(guān)鍵指標(biāo)之一，因此，該策略為什么能在端到端的服務(wù)時間中表現(xiàn)出優(yōu)勢是可以理解的。相比之下，概率策略需要根據(jù)過去事件的發(fā)生率求解后續(xù)任務(wù)的發(fā)生概率，并為可能到來的工作負(fù)載引入資源預(yù)留方式。因此，這種方法導(dǎo)致任務(wù)調(diào)度時，當(dāng)前任務(wù)的部署不是最優(yōu)或接近最優(yōu)的，更不幸的是，如果下一個任務(wù)的預(yù)測是錯誤的，那么資源預(yù)留就成為一種資源浪費。

總之，隨著終端設(shè)備數(shù)量的增加和IoT任務(wù)資源需求的提高，OE架構(gòu)變得越來越有效和高效，卸載策略開始為任務(wù)調(diào)度做出更多的貢獻；LC架構(gòu)(包括靜態(tài)比率策略)更適合于簡單的IoT場景，其中IoT設(shè)備數(shù)量相對較少；然而，當(dāng)資源請求變得更大(如App(1,4k)或更大)，LC架構(gòu)忽略邊云結(jié)點當(dāng)前狀態(tài)和IoT任務(wù)的個體需求，會因任務(wù)卸載到單個結(jié)點的靜態(tài)過程而增加時間消耗，只有考慮復(fù)雜約束的邊緣編排，即OE架構(gòu)，才有助于解決此問題。

6 研究局限性與展望

對于一個給定的IoT應(yīng)用需求，研究如何自主決定最優(yōu)部署機制是未來的一個研究方向。首先，本文僅研究了獨立任務(wù)的卸載策略，然而，任務(wù)依賴性是影響任務(wù)卸載決策的重要因素，因此，需拓展考慮調(diào)度卸載任務(wù)過程中的任務(wù)依賴；其次，為了最小化服務(wù)時間，從任務(wù)的數(shù)量、用戶移動性等方面預(yù)測延遲敏感性應(yīng)用的行為，進而有利于資源管理器提前準(zhǔn)備所需資源，避免任何方面的性能下降；最后，為處理基于CPU速度和帶寬的IoT延遲敏感應(yīng)用的不同需求，本文考慮了3種定制的卸載策略，由于大量AR/VR及視頻游戲需要密集性計算，為了在邊云環(huán)境中處理該類任務(wù)，需擴展考慮GPU和FPGA等計算資源。

7 結(jié)論

IoT時代，邊緣計算非常適合優(yōu)化和保障實時應(yīng)用程序性能。本文旨在利用高效的協(xié)調(diào)機制和任務(wù)卸載算法，使得移動設(shè)備和邊云能夠協(xié)同工作?；谘舆t模型和性能評測揭示IoT應(yīng)用程序的內(nèi)在本質(zhì)和性能干擾的根源。分析了當(dāng)IoT設(shè)備數(shù)量和請求資源變化時，不同架構(gòu)方案和卸載策略對IoT應(yīng)用性能的影響，并檢驗了它們的有效性。IoT應(yīng)用程序的所有者可從本研究中理解應(yīng)用程序如何在不同的IoT部署方案下執(zhí)行，并根據(jù)給定的具體應(yīng)用場景選擇合適的架構(gòu)方案和卸載策略以提高應(yīng)用程序性能。