目前邊緣計算已經得到了各行各業的廣泛重視，并且在很多應用場景下開花結果。根據邊緣計算領域特定的特點，本文認為6個方向是未來幾年迫切需要解決的問題：編程模型、軟硬件選型、基準程序與標準、動態調度、與垂直行業的緊密結合以及邊緣節點的落地。

[[256413]]

1. 編程模型

編程模型可以使開發者快速上手開發應用產品，從而快速推動領域的發展.在云計算場景中，用戶程序在目標平臺上編寫和編譯，然后運行到云服務器，基礎設施對于用戶是透明的，例如亞馬遜基于此編程模型推出的 Lambda 計算服務，可使用戶無需預配置或者管理服務器即可運行代碼，極大地方便了用戶的使用。然而，邊緣計算模型與云計算模型存在較大的區別，從功能角度講，邊緣計算是一種分布式的計算系統，具有彈性管理、協同執行和環境異構的特點，如圖4所示：

從圖4可知，邊緣計算包含3個關鍵內容：

• 應用程序/服務功能可分割。邊緣計算中的一個任務可以遷移到不同的邊緣設備去執行，任務可分割包括僅能分割其自身或將一個任務分割成子任務，任務的執行需要滿足可遷移性，即任務可遷移是實現在邊 緣設備上進行數據處理的必要條件。
• 數據可分布。數據可分布既是邊緣計算的特征也是邊緣計算模型對待處理數據集合的要求。邊緣數據的可分布性是針對不同數據源而言的，不同數據源來源于數據生產者所產生的大量數據。
• 資源可分布。邊緣計算模型中的數據具有一定的可分布性，從而要求處理數據所需要的計算、存儲和通信資源也具有可分布性.只有當邊緣計算系統具備數據處理和計算所需要的資源，邊緣設備才可以對數據進行處理。

因此，傳統的編程模型并不適合邊緣計算。邊緣計算中的設備大多是異構計算平臺，每個設備上的運行時環境、數據也不相同，且邊緣設備的資源相對受限，在邊緣計算場景下部署用戶應用程序會有較大的困難。Li等人針對邊緣設備資源受限的特性設計了一種輕量級的編程語言EveryLite，該工作將計算遷移任務中主體為接口調用的、時間和空間復雜度受限的計算任務稱為微任務(micro task)， EveryLite能夠在物端設備上處理邊緣計算場景中微任務，經過實驗對比可以發現EveryLite的執行時間分別比JerryScript和Lua低77%和74%，編譯后內存占用量分別是JerryScript和Lua的18. 9% 和1. 4%。因此，針對邊緣計算場景下的編程模型的研究具有非常大的空間，也十分緊迫。

2. 軟硬件選型

邊緣計算系統具有碎片化和異構性的特點。在硬件層面上，有CPU，GPU，FPGA，ASIC等各類計算單元，即便是基于同一類計算單元，也有不同的整機產品，例如基于英偉達GPU的邊緣硬件產品，既有計算能力較強的DRIVEPX2，又有計算能力較弱 的Jetson TX2；在軟件系統上，針對深度學習應用， 有 TensorFlow, Caffe, PyTorch 等各類框架.不同的軟硬件及其組合有各自擅長的應用場景，這帶來了一個問題：開發者不知道如何選用合適的軟硬件產品以滿足自身應用的需求。

在軟硬件選型時，既要對自身應用的計算特性做深人了解，從而找到計算能力滿足應用需求的硬件產品，又要找到合適的軟件框架進行開發，同時還要考慮到硬件的功耗和成本在可接受范圍內。因此，設計并實現一套能夠幫助用戶對邊緣計算平臺進行性能、功耗分析并提供軟硬件選型參考的工具十分重要。

3. 基準程序和標準

隨著邊緣計算的發展，學術界和工業界開始推出越來越多的針對不同邊緣計算場景設計的硬件或軟件系統平臺，那么我們會面臨一個緊迫的問題，即如何對這些系統平臺進行全面并公平的評測。傳統的計算場景都有經典基準測試集(benchmark)，例如并行計算場景中的PARSEC、高性能計算場景中的 HPCC、大數據計算場景中的BigDataBench。

由于邊緣計算仍然是較新的計算場景，業界仍然沒有一個比較權威的用于評測系統性能的Benchmark出現，但是學術界已經開始有了一些探索工作SD-VBS和MEVBench均是針對移動端設備評測基于機器視覺負載的基準測試集。SD-VBS選取了28個機器視覺核心負載，并提供了C和Matlab的實現；MEVBench則提供了一些列特征提取、特征分類、物體檢測和物體追蹤相關的視覺算法負責，并提供單線程核多線程的C++實現。SLAMBench是一個針對移動端機器人計算系統設計的基準測試集，其使用RG&D SLAM作為評測負載，并且針對不同異構硬件提供C++，OpenMP， OpenCL 和 CUDA 版本的實現。CAVBench是第1個針對智能網聯車邊緣計算系統設計的基準測試集，其選擇6個智能網聯車上的典型應用作為評測負責，并提供標準的輸人數據集和應用-系統匹配指標。

由于邊緣計算場景覆蓋面廣，短期來看不會出現一個統一的基準測試集可以適應所有場景下的邊緣計算平臺，而是針對每一類計算場景會出現一個經典的基準測試集，之后各個基準測試集互相融合借鑒，找出邊緣計算場景下的若干類核心負載，最終形成邊緣計算場景中的經典基準測試集。

4. 動態調度

在云計算場景下，任務調度的一般策略是將計算密集型任務遷移到資源充足的計算節點上執行。但是在邊緣計算場景下，邊緣設備產生的海量數據無法通過現有的帶寬資源傳輸到云計算中心進行集中式計算，且不同邊緣設備的計算、存儲能力均不 相同，因此，邊緣計算系統需要根據任務類型和邊緣設備的計算能力進行動態調度。調度包括2個層面：

• 云計算中心和邊緣設備之前的調度;
• 邊緣設備之間的調度。

云計算中心與邊緣設備間的調度分為2種方式：自下而上和自上而下。自下而上是在網絡邊緣處將邊緣設備采集或者產生的數據進行部分或者全部的預處理，過濾無用數據，以此降低傳輸帶寬;自上而下是指將云計算中心所執行的復雜計算任務進行分割，然后分配給邊緣設備執行，以此充分利用邊緣設備的計算資源，減少整個計算系統的延遲和能耗。2017年，Kang等人設計了一個輕量級的調度器 Neurosurgeon,它可以將深度神經網絡不同層的計算任務在移動設備和數據中心間自動分配，使得移動設備功耗最多降低了 94.7%，系統延遲最多加快了40.7倍，并且數據中心的吞吐量最多增加了6. 7倍。邊緣設備間也需要動態調度。邊緣設備的計算、存儲能力本身是不同的，并且會隨著時間的變化而變化，而它們承擔的任務類型也是不一樣的，因此需要動態調度邊緣設備上的任務，提高整體系統性能，防止出現計算任務調度到一個系統任務過載情況下的設備.Zhang等人針對延遲敏感性的社會感知任務設計了一個邊緣任務調度框架C〇GTA，實驗證明該框架可以滿足應用和邊緣設備的需求。

綜上所述，動態調度的目標是為應用程序調度邊緣設備上的計算資源，以實現數據傳輸開銷最小化和應用程序執行性能的較大化。設計調度程序時應該考慮：任務是否可拆分可調度、調度應該采取什么策略、哪些任務需要調度等.動態調度需要在邊緣設備能耗、計算延時、傳輸數據量、帶寬等指標之間尋找平衡.根據目前的工作，如何設計和實現一種有效降低邊緣設備任務執行延遲的動態調度策略是一個急需解決的問題。

5. 和垂直行業緊密合作

在云計算場景下，不同行業的用戶都可將數據傳送至云計算中心，然后交由計算機從業人員進行數據的存儲、管理和分析。云計算中心將數據抽象并提供訪問接口給用戶，這種模式下計算機從業人員與用戶行業解耦和，他們更專注數據本身，不需對用戶行業領域內知識做太多了解。

但是在邊緣計算的場景下，邊緣設備更貼近數據生產者，與垂直行業的關系更為密切，設計與實現邊緣計算系統需要大量的領域專業知識。另一方面，垂直行業迫切需要利用邊緣計算技術提高自身的競爭力，卻面臨計算機專業技術不足的問題.因此計算 機從業人員必須與垂直行業緊密合作，才能更好地完成任務，設計出下沉可用的計算系統.在與垂直行業進行合作時，需要著重解決3個問題：

• 減少與行業標準間的隔閡。在不同行業內部有經過多年積累的經驗與標準，在邊緣計算系統的設計中，需要與行業標準靠近，減少隔閡。例如，在針對自動駕駛汽車的研究中，自動駕駛任務的完成需要使用到智能算法、嵌人式操作系統、車載計算硬件等各類計算機領域知識，這對于計算機從業人員而言是一個機遇，因此許多互聯網公司投人資源進行研究。然而，若想研制符合行業標準的汽車，僅應用計算機領域知識是完全不夠的，還需要對汽車領域專業知識有較好的理解，例如汽車動力系統、控制系統等，這就需要與傳統汽車廠商進行緊密合作。同樣，在智能制造、工業物聯網等領域，同樣需要設計下沉到領域內、符合行業標準的邊緣計算系統。
• 完善數據保護和訪問機制。在邊緣計算中，需要與行業結合，在實現數據隱私保護的前提下設計統一、易用的數據共享和訪問機制.由于不同行業具有的特殊性，許多行業不希望將數據上傳至公有云，例如醫院、公安機構等。而邊緣計算的一大優勢是數據存放在靠近數據生產者的邊緣設備上，從而保證了數據隱私.但是這也導致了數據存儲空間的多樣性，不利于數據共享和訪問.在傳統云計算中，數據傳輸到云端 ，然后通過統一接口來訪問，極大地方便了用戶的使用.邊緣計算需要借助這種優勢來設計數據防護和訪問機制。
• 提高互操作性。邊緣計算系統的設計需要易于結合行業內現有的系統，考慮到行業現狀并進行利用，不要與現實脫節。例如在視頻監控系統中，除了近些年出現的智能計算功能的攝像頭，現實中仍然有大量的非智能攝像頭，其每天仍然在采集大量的視頻數據，并將數據傳輸至數據中心。學術界設計了A3系統，它利用了商店或者加油站中已有的計算設備。然而實際情況下，攝像頭周邊并不存在計算設備。因此，在邊緣計算的研究中需要首先考慮如何部署在非智能的攝像頭附近部署邊緣計算設備. 在目前的解決方案中，多是采用建立更多的數據中心或AI—體機來進行處理，或者采用一些移動的設備，如各種單兵作戰設備，來進行數據的采集.前者耗費巨大，且從本質來說，仍然是云計算的模式;后者通常使用于移動情況下，僅作為臨時的計算中心，無法和云端進行交互。在視頻監控領域，Luo等人提出了一個尚屬于前期探討的EdgeBox方案，其同時具備計算能力和通信能力，可以作為中間件插人到攝像頭和數據中心之間，完成數據的預處理. 因此，如何與垂直行業緊密合作，設計出下沉可用的邊緣計算系統，實現計算機與不同行業間的雙贏是邊緣計算面臨的一個緊迫問題。

6. 邊緣節點落地問題

邊緣計算的發展引起了工業界的廣泛關注，但是在實際邊緣節點的落地部署過程中，也涌現出一些急需解決的問題，例如應該如何建立適用于邊緣計算的商業模式、如何選擇參與計算的邊緣節點和邊緣計算數據、如何保證邊緣節點的可靠性等。

1)新型商業模式.在云計算場景下，云計算公司是計算服務的提供者，它們收集、存儲、管理數據并且負責軟硬件、基礎設施的建設和維護，用戶付費購買服務，不需要關注計算節點本身的成本，也無需關注服務質量的升級換代過程.這種商業模式為用戶使用云服務帶來了便利，也讓云計算公司具備盈利能力，從而更好地提高服務質量。

而在邊緣計算場景下，邊緣節點分布在靠近數據生產者的位置，在地理位置上具有較強的離散性，這使得邊緣節點的統一性維護變得困難，同時也給軟硬件升級帶來了難度。例如提供安全服務的攝像頭，在使用過程中需要進行軟硬件的升級，軟件的升級可以通過網絡統一進行，而硬件的升級需要親臨現場。依賴于服務提供者去為每一個邊緣節點(攝像頭)進行硬件的升級和維護會帶來巨大的成本開銷，而服務的使用者一般不關注也不熟悉硬件設備的維護工作。又如，在CDN服務的應用中，需要考慮 CDN服務器是以家庭為單位還是以園區為單位配置，不同的配置方式會帶來成本的變化，也為服務質量的穩定性增加了不確定因素，而維護CDN所需的開銷，需要考慮支付者是服務提供者還是使用者。

因此工業界需要尋求一種或多種新的商業模式來明確邊緣計算服務的提供者和使用者各自應該承擔什么責任，例如誰來支付邊緣節點建立和維護所需的費用、誰來主導軟硬件升級的過程等。

2) 邊緣節點的選擇。邊緣計算是一個連續統，邊緣指從數據源到云計算中心路徑之間的任意計算和網絡資源。(在實際應用中，用戶可以選擇云到端整個鏈路上任意的邊緣節點來降低延遲和帶寬.由于邊緣節點的計算能力、網絡帶寬的差異性，不同邊緣節點的選擇會導致計算延遲差異很大.現有的基礎設施可以用作邊緣節點，例如使用手持設備訪問進行通信時，首先連接運營商基站，然后訪問主干網絡。這種以現有基礎設施當做邊緣節點的方式會加大延遲，如果手持設備能夠繞過基站，直接訪問主干網絡的邊緣節點，將會降低延遲.因此，如何選擇合適的邊緣節點以降低通信延遲和計算開銷是一個重要的問題.在此過程中，需要考慮現有的基礎設施如何與邊緣節點融合，邊緣計算技術會不會構建一個新興的生態環境，給現有的基礎設施發生革命性的變化?

3)邊緣數據選擇。邊緣節點眾多，產生的數據數量和類型也眾多，這些數據間互有交集，針對一個問題往往有多個可供選擇的解決方案。例如在路況實時監控應用中，既可以利用車上攝像頭獲得數據，也可以利用交通信號燈的實時數據統計，還可以利用路邊計算單元進行車速計算。因此如何為特定應用合理地選擇不同數據源的數據，以最大程度地降低延遲和帶寬，提高服務的可用性是一個重要問題。

4)邊緣節點的可靠性。邊緣計算中的數據存儲 和計算任務大多數依賴于邊緣節點，不像云計算中心有穩定的基礎設施保護，許多邊緣節點暴露于自 然環境下，保證邊緣節點的可靠性非常重要.例如， 基于計算機視覺的公共安全解決方案需要依賴智能攝像頭進行存儲和計算，然而在極端天氣條件下，攝像頭容易在物理上收到損害，例如暴風天氣會改變攝像頭的角度，暴雪天氣會影響攝像頭的視覺范圍， 在此類場景中，需要借助基礎設施的配合來保證邊緣節點的物理可靠性。同時，邊緣數據有時空特性，從而導致數據有較強的唯一性和不可恢復性，需要設計合理的多重備份機制來保證邊緣節點的數據可靠性.因此，如何借助基礎設施來保障邊緣計算節點的物理可靠性和數據可靠性是一個重要的研究課題。

在邊緣節點落地過程中，已經有了不少嘗試，例如聯通提出了建設邊緣云，其規劃至2020年建設6000~7000個邊緣節點，將高帶寬、低時延、本地化業務下沉到網絡邊緣，進一步提高網絡效率、增強服務能力。因此針對如何選擇邊緣節點，處理好邊緣節點與現有基礎設施的關系，保證邊緣節點的可靠性的研究非常緊迫。