2.3　軟件計算架構

軟件架構的作用是將邊緣計算架構中的各個實體有機組合起來，并最終將硬件計算資源轉化為各類計算服務提供給邊緣計算前端用戶和開發者。按照云計算服務模式，由軟件架構提供的計算服務可以分為IaaS、PaaS、SaaS以及更細粒度的FaaS。在邊緣計算中，邊緣資源同樣會轉化為這幾種形式為前端設備提供服務。考慮到邊緣系統架構的特點，實現邊緣計算服務的軟件架構與云計算相比有所不同。

2.3.1　一般邊緣計算軟件架構

邊緣計算的軟件系統架構是將上述介紹的邊緣計算中各類實體硬件有機組織起來，從而以便捷、高效的方式為前端設備提供計算服務。前端用戶通過各類通信標準（移動蜂窩網絡、藍牙/Wi-Fi/ZigBee個域網、NB-IoT/LoRa廣域網等）接入邊緣網絡后，會被分配到各邊緣服務器上進行運算。對于多數兩層或三層的邊緣計算硬件架構，運行其上的軟件架構是類似的，主要包含基礎設施層和平臺管理層（如圖2-8所示）。其中基礎設施層直接負責各類硬件資源和設備的組織與虛擬化，為應用提供通用、統一的資源使用和分配方法。而平臺管理層則是在物理資源之上，提供IaaS、PaaS和SaaS的服務實現。

1. 基礎設施層

基礎設施層主要分為硬件資源和虛擬層兩部分，在這兩部分基礎上，邊緣計算基礎設施管理系統能夠整合所有的硬件資源形成一個穩定、通用的運行環境，使得上層的邊緣服務可以在這個環境中被部署、執行和管理。

硬件資源指各邊緣服務器上配備的計算資源、存儲資源和網絡資源。通用服務器有較好的性能，價格相對低廉。存儲硬件提供存儲能力，存儲節點可以是網絡附加存儲（Network Attached Storage）和存儲區域網絡（Storage Area Network）等存儲方式。網絡通信資源則包括交換機和路由器等設備。這些硬件資源根據采用的硬件架構不同會有不同的配置，一般部署在網絡接入設備以及用戶駐地網絡等，通過虛擬層為邊緣服務提供處理、存儲和數據傳輸功能。

考慮到邊緣服務對硬件需求的多樣性，在通用硬件上直接實現各類邊緣計算服務幾乎是不可能的，而配置大量異構的硬件設備也會帶來難以承受的硬件和維護成本。此外，考慮到用戶的移動性和需求的動態性，專用硬件資源難以滿足動態多變的用戶請求。因此，在邊緣計算的基礎設施層，需要對硬件資源進行抽象，在真實的硬件之上建立虛擬化網絡資源，對邊緣服務所需的軟件和底層硬件進行解耦，保證各類服務可以成功部署在底層物理資源上。虛擬化的典型解決方案包括以操作系統為中心的Hypervisor虛擬化方案和以應用程序為中心的Container虛擬化方案。本書將在第5章展開介紹虛擬化技術。

2. 平臺管理層

邊緣計算平臺管理層建立在虛擬化資源之上，將硬件資源、平臺和軟件轉變為IaaS、PaaS和SaaS服務。具體而言，平臺管理層包含虛擬化資源管理和邊緣應用服務平臺，將網絡中的資源分配給不同的服務，提供邊緣服務的運行和管理。

虛擬化資源管理負責將虛擬化后的硬件資源靈活、高效地分配給邊緣場景中的各個服務用戶。根據邊緣場景中用戶所需服務的類型（如傳輸密集型、計算密集型和存儲密集型）將資源按需分配給不同的應用，同時考慮用戶移動性、需求變化以及網絡環境等多種因素來靈活調度資源。資源的恰當分配直接影響邊緣服務器的資源利用率，這是控制邊緣成本、優化用戶體驗的關鍵環節。

邊緣計算應用服務平臺向上直接為用戶提供計算卸載和服務使用的接口，向下負責注冊、管理邊緣服務。邊緣應用服務平臺通過一系列中間件實現，通常包括通信服務模塊、服務注冊模塊、無線網絡信息服務模塊以及流量卸載模塊。

• 服務注冊模塊：服務注冊模塊整合各個邊緣計算服務的相關信息，包括服務相關接口、版本信息和服務狀態（可用性）等。前端應用程序可以根據計算任務的需求特點選擇調用相應的服務。
• 通信服務模塊：通信服務模塊負責通過事先定義好的API（Application Programming Interface），建立運行在虛擬機上的應用程序與邊緣應用服務平臺之間的相互通信，以支持平臺管理層為應用程序生命周期提供相關支持，如應用程序所需的資源、最大容忍延遲等。
• 流量卸載模塊：該模塊通過監測、分析無線網絡和用戶信息，對用戶請求和數據流量進行優先級排序。該優先級主要用于邊緣服務器對前端用戶的信道資源分配以及邊緣網絡中的鏈路資源分配。
• 無線網絡信息服務模塊：無線網絡信息服務模塊負責記錄無線網絡的實時狀態以及用戶端設備的相關信息。無線網絡實時狀態包括蜂窩網小區ID、小區當前負載、上行和下行可用帶寬等，用戶端設備信息包括用戶位置、用戶吞吐量、用戶相關服務質量、已建立的無線連接等。考慮到邊緣網絡中的前端任務卸載直接受到網絡狀況的影響，無線網絡信息服務對網絡狀態的刻畫有助于用戶做出最恰當的計算卸載決策，節省通信與計算資源。

2.3.2　多接入邊緣計算架構

2016年，歐洲電信標準化協會（European Telecommunications Standards Institute，ETSI）將邊緣網絡的稱謂由移動邊緣計算更名為多接入邊緣計算。在多接入邊緣計算架構中，用戶可以在接入不同網絡的情況下共享邊緣資源，也可以通過切換不同的接入方式提高邊緣計算的服務質量。ETSI給出的多接入邊緣計算架構如圖2-9所示。

與一般邊緣計算架構類似，多接入邊緣計算架構同樣包含基礎設施層和平臺管理層。其中基礎設施層著重強調各個邊緣服務器通過相互之間的鏈接構成邊緣服務網絡，通過大量、密集的邊緣服務器形成的網絡整體為前端的海量用戶提供服務。平臺管理層從應用程序的生命周期出發，為邊緣服務提供基本功能集合并制定應用程序管理規則，在多接入的場景中著重強調服務授權、流量規則、解決沖突和DNS配置等方案。

與一般邊緣計算架構不同的是，多接入邊緣計算架構單獨剝離了多接入邊緣協調器（Multi-Access Edge Orchestrator）。該模塊作為多接入邊緣網絡框架中的核心模塊之一，負責服務器組網、管理及分配硬件資源、邊緣服務實例的部署、協調邊緣用戶請求的服務路徑、卸載任務在多邊緣服務器中的分配等。具體包括以下功能：

①管理終端用戶卸載決策。此模塊作為多接入網絡核心模塊，負責調度用戶請求。主要從兩個方面協調用戶的請求：

• 通過服務部署與請求調度來應對用戶請求。當用戶請求某一特定服務的時候，協調器須將請求路由到相應的服務器上。由于多接入場景存在多個可選的服務器，因此需要根據服務評價指標（如最大容忍的卸載端到端時延）靈活地協調所有用戶的請求。用戶的卸載端到端時延包括無線傳輸時延、邊緣服務器網內傳輸時延和服務器處理時延。因此協調策略可分為三個部分：無線接入節點、邊緣服務網內路由和處理器處理時序。通過協調各請求的接入節點可有效緩解擁塞的通信鏈路，降低無線傳輸時延；通過協調請求的邊緣網內路由，可有效緩解擁塞鏈路和路由器轉發時間；通過協調處理器處理時序，可按照各請求的最早、最晚截止時間，盡量滿足多用戶請求。
• 通過資源分配方案迎合用戶請求。考慮到邊緣用戶的移動性和多變性，一成不變的服務部署方案很難迎合邊緣網絡的這一特點。因此除了協調用戶的請求來迎合邊緣網絡資源，我們也需要主動調整邊緣網絡的資源來滿足用戶多變的請求。具體來說，通過用戶請求的分布來合理部署多個服務實例，以緩解通信時延和處理時延，通過擴容或者新建應用實例來滿足不斷增長變化的用戶需求。

②管理部署的邊緣計算主機，維護計算、存儲、傳輸資源以及服務器間拓撲結構。

③管理邊緣網絡所提供的服務。檢查軟件包的完整性和真實性等相關要求，并在必要時對其進行調整以符合系統要求。

除了與邊緣網絡直接相關的架構設計，邊緣計算的范式對傳統計算模式的關鍵技術均具有重要影響，在編程模型、操作系統、網絡管理、服務管理等方面引領了一系列技術創新。

2.3.3　AIoT軟件架構

考慮到當前AIoT主要面向市場產品的落地，其中的邊緣網關更多的是基于上述一般架構針對場景的定制化產品落地，技術重點強調在邊緣網關與應用平臺兩個關鍵部分。如圖2-10所示，以騰訊IoT EIDP［1］為例展示了典型的AIoT技術架構。其中邊緣網關直接面向前端的物聯網設備應用提供各類服務，這些服務通常由虛擬化引擎（如Docker）提供，包括服務發現、協議轉換、AI中間件、云端連接服務及具體的服務實例化容器。應用平臺部分根據開發及市場需求分為應用與模型發布平臺、應用與模型分發平臺。其中應用與模型發布平臺面向邊緣模型和服務的開發者，提供Docker管理、應用管理、可視化配置應用、應用發布等。而應用與模型分發平臺則可以看作面向各個邊緣網關終端的應用與模型市場，除了模型及應用鏡像倉庫之外，設備管理、應用管理、網絡代理、認證授權等也是應用與模型分發平臺的重要模塊。

2.3.4　衛星邊緣計算架構

微電子技術的蓬勃發展，使得微型衛星成為可能。從傳統的重達500千克的地球觀察者1號衛星（EO-1），到現在的僅重幾千克、體積在10厘米級的立方體衛星，衛星的設備成本及發射成本在一路下降，這使得衛星的大規模部署成為可能。從星鏈計劃［3］到黑杰克計劃［4］，低軌衛星星座逐漸展示出其在軍事、民用領域的重大潛力，獲得政府、企業、學術界各方的廣泛關注和研究。伴隨著云計算、邊緣計算相關技術的發展，低軌衛星星座也需要具備多星協同、自主運行、能力開放的在軌邊緣計算能力。

不同于地面上的邊緣計算架構，運行在低軌道上的衛星時刻處在與地球的相對運動之中，這使得任何一個單一的低軌衛星都不足以給地面上的前端設備提供穩定的邊緣計算能力。因此，直接將前面介紹的邊緣系統架構用于衛星邊緣計算時無法正常運轉。這就要求對邊緣計算的系統架構做出調整，使其能夠適應低軌衛星的系統特點。

目前國內外已針對低軌星座在軌計算的研究開展了一系列工作。如DARPA的黑杰克計劃，期望在550km軌道上建立80～100個衛星節點的低軌星座，能夠協同、自主地進行任務運算，而運維僅需要一個2人小組，其歸功于其中的PitBoss系統（類似于中控平臺）管理衛星軌道、服務管理、任務調度等核心模塊，實現低軌星座的自主運行。歐洲宇航局也提出了OS-SAT計劃，期望利用市面已有的設備建立低成本、高可用的低軌衛星計算系統，并面向第三方開放。英國企業Exodus Orbitals也提出了一項在軌運算服務計劃［5］，并期望在2021年將計算能力開放給普通開發者。此外，卡內基-梅隆大學也提出了Orbital Edge Computing項目，面向典型的衛星遙感任務，提出了初步的星座協同運算方案，并開發了全系統仿真。表2-2展示了在軌衛星邊緣計算近年相關項目的基本情況和預期進度。

①仿真系統地址為http://qaanaaq.andrew.cmu.edu:8080/。

當前關于衛星邊緣計算架構的研究，主要針對衛星與地面的相對移動、衛星本身的能源不穩定等特點。為應對這些問題，多個機構提出了不同的技術路線，并開展了前沿探索。本節將主要介紹計算衛星流水線技術以及動態星團組網技術。

1. 計算衛星流水線技術

地面圖像處理是在軌衛星邊緣計算的主要任務場景之一。由于低軌衛星的覆蓋范圍相比同步衛星較小，且存在衛星與地面之間的相對運動，使得在軌計算的圖像采集難以使用傳統同步衛星現有的技術。對于同一顆衛星，在不同時刻，其所覆蓋的地面區域是不同的，這意味著：

①對于每一顆衛星而言，其面向區域的計算任務是伴隨著軌道運動在發生周期性變化。

②對每一個區域而言，其計算任務在不同時刻會在不同的衛星上執行。

理想狀態中，如果各顆衛星能夠及時處理其對應區域的圖像處理任務，則多顆衛星伴隨軌道移動可以實現軌道圖像處理任務的覆蓋和及時響應。然而，考慮到低軌微型衛星處理能力十分受限，當其移動到新的區域時（即接收到新的任務時），雖然能夠順利采集圖像，但舊區域的任務極可能仍未完成，從而來不及處理新進入區域的計算任務。

為解決此問題，卡內基-梅隆大學提出計算衛星流水線（Computational Nanosatellite Pipeline，CNP）技術，將多顆衛星組織起來，共同處理單一衛星無法完成或來不及完成的圖像處理任務。CNP技術的基本思想是根據任務特點控制衛星陣型及任務分配，將采集到的圖像任務切割并分配到多顆衛星上進行并發運算，從而將多顆衛星有機組織起來。如圖2-11所示，運用CNP技術，圖像首先被分割為多個塊（tile），這些塊被分配到多顆衛星上進行并發運算，之后運算結果再匯聚或發回地面。

除任務分割外，CNP技術根據任務需求對衛星陣型進行調整，可分為幀距陣型和緊湊陣型。在幀距陣型中，每顆衛星相距的空間剛好使得各自采攝的圖像相鄰一幀距離（如圖2-11中的第1、3、5顆衛星）。在緊湊陣型中，衛星之間的距離盡可能被縮短，能夠支持算力的集中，處理實時性要求較高的任務。根據衛星陣型和任務分割策略的不同組合，CNP技術提供四種運算模式：幀距塊并發、緊湊塊并發、幀距幀并發、緊湊幀并發。

①幀距塊并發。CNP技術中相鄰的兩顆衛星之間保持幀距，即兩顆衛星拍攝的地面圖像是正好相鄰的兩幀。每臺設備均拍攝地面圖像，形成連續的區域，并處理其中一部分圖像塊數據，如圖2-12a所示。

②緊湊塊并發。緊湊是指相鄰衛星之間保持盡可能短的距離，每顆衛星并行處理不同的圖像塊數據，如圖2-12b所示。

③幀距幀并發。相鄰兩顆衛星保持幀距，每顆衛星處理各自的圖像幀，從而在整體上完成連續區域的圖像處理，如圖2-12c所示。

④緊湊幀并發。相鄰衛星之間保持盡可能短的距離，每顆衛星處理不同的幀圖像數據，如圖2-12d所示。

顯然，這四種運算模式是為了應對不同的應用場景。幀距塊并發和幀距幀并發兩種模式用于單位圖像的計算負載相對稀疏的情況，允許衛星之間相鄰一定的距離以增加對地面區域的覆蓋。當每幀圖像僅需要處理關鍵信息時，采用塊并發的方式。當每幀圖像需要完整處理時，則使用幀并發的方式。緊湊塊并發和緊湊幀并發則用于單位圖像的計算負載較密集、單一衛星無法完成關鍵幀處理的場景。此時，通過將多顆衛星緊湊排列，能夠集中算力完成一幀圖像中的計算任務處理。如圖2-12所示，當單幀的圖像任務負載較大時，多顆衛星通過塊并發的方式集中處理。當遇到連續幀任務負載較大時，則利用幀并發的方式進行處理。

由CNP技術可以看到，衛星邊緣計算相比一般場景的邊緣計算，對邊緣服務器的移動性和任務分割具有更高的要求，也更接近于D2D和高移動性的泛在邊緣場景。

2. 動態星團組網技術

低軌衛星與地面之間的相對移動不僅影響到任務與衛星間的匹配關系，同時也影響到衛星與地面之間的數據傳輸鏈路。對于地面上的固定位置，一顆衛星在其上方的過頂時間通常在10分鐘到半小時不等，這意味著計算任務需要在這段延遲之內完成。雖然CNP技術可以加速任務處理，但對于復雜度較高的任務而言，在確定其計算量之前依然難以保證任務在時限內處理完成。

與CNP技術形成互補的另一種方式是“動態星團組網架構”，通過考慮計算任務特點、軌道信息以及各衛星節點上的負載，動態地選擇一部分衛星形成“星團”來完成一批計算任務。如圖2-13所示，星團中包含三種角色的衛星節點：協調節點、匯聚節點以及運算子網。其中運算子網是共同形成星團的衛星集合，這些衛星相互協作共同完成批量的計算任務。協調節點是直接與地面設備通信的節點，接收來自地面前端設備的計算請求，判斷該請求對應的計算任務，并分發給計算子網中的衛星節點進行協同處理。待計算任務處理完成之后，各衛星將計算結果傳輸給匯聚節點返回地面。不同于協調節點在接收請求時自然確定，匯聚節點是由協調節點收到計算請求后，根據軌道移動模型和估計計算延遲來選定的。選定的匯聚節點需要在任務完成的時刻移動到地面前端設備的上方，從而保證任務完成后能夠第一時間將計算結果返回。不同于傳統的集群管理方法，動態星團組網中各衛星節點的相對位置、衛星與前端設備的相對位置均處于隨時變化的狀態。這對多邊緣衛星協同、底層尋址、數據可靠傳輸等方面均提出了較高要求。

衛星邊緣計算是一種較為新穎的邊緣計算場景，可以視作一種特殊的泛在移動場景。其中邊緣服務器（低軌衛星節點）與前端設備之間、邊緣服務器相互之間均存在相對移動，這一移動性是伴隨著軌道具有周期性的。如果將衛星邊緣計算中移動的周期性這一條件放寬，則接近于一般意義的泛在移動邊緣場景，對系統架構、底層協議、計算模型等方面會有更高的要求。

2.3.5　編程模型

邊緣計算的普及有望將幾乎所有的智能設備帶入類云環境中，前端設備不需要攜帶計算和存儲資源，可以通過遠程通信使用邊緣設備上的計算與存儲資源。考慮到邊緣設備以及邊緣服務的多樣性，急需提出新的編程模型以支持各類設備接入邊緣網絡和邊緣服務的快速開發迭代。

當前多個機構提出了用于“物聯網+邊緣計算”場景的編程模型，如微軟Azure IoT Edge、AWS Greengrass、EdgeX、百度OpenEdge等。這些邊緣框架普遍沿用了傳統編程模型，邊緣服務開發者在開發過程中需要明確定義數據來源、數據格式、邊緣服務接口、邊緣服務地址等。這樣的編程模型在邊緣計算的環境中面臨以下幾方面的挑戰，有可能嚴重阻礙邊緣服務及相關應用的快速開發迭代。

①邊緣服務訪問的局限性。在基于云的計算框架中，各服務組件需要預先運行在云中心設備或其他參與軟件周期的設備上，從而允許開發者應用通過網絡進行調用。但在邊緣場景當中，邊緣資源往往僅有特定區域或特定用戶能夠訪問。而服務開發者通常無法得知具體服務的訪問區域和訪問權限信息，導致開發邊緣服務時需要大量的服務查找及狀態分支邏輯，甚至導致服務在實際場景中不可用。

②邊緣資源的多樣性。不同于通用云服務器，按照當前對邊緣計算的設想，邊緣設備可以是任意形式，其配備的資源類型、資源數量、通信方式甚至硬件架構均可能存在較大差異。這導致邊緣服務和應用開發者幾乎不可能在開發過程中明確指定邊緣資源及相應資源的調用方式。

③邊緣場景的高度動態性。考慮到邊緣計算場景中的移動性，邊緣設備、邊緣資源均可能處于不穩定的服務狀態，如在車聯網場景中，高速移動的車輛與邊緣服務網絡之間鏈路的不穩定將直接導致邊緣服務無法使用。而現有編程方式通常不考慮服務穩定性和可用性，開發者也難以在開發過程中對各類移動場景進行準確處理。

④固化的邊緣服務方式。針對多樣化的物聯網應用，各邊緣服務之間多采用基于主題的發布/訂閱（topic-based pub/sub）接口進行服務間通信，并且需要手動定義服務間的路由。然而在邊緣場景中，由于移動性、業務需求等因素，邊緣服務時常會面臨遷移、負載波動等問題，這使得預先定義好的服務組合在真實環境中極有可能無法正常運轉。

為解決上述問題，促進邊緣計算生態和產業的快速發展，當前研究界與科研界在編程模式方面展開了一系列前沿探索，如圖2-14所示。如NEC公司歐洲實驗室與日本方案創新部門提出的Fog Function（FogFunc），旨在用Serverless思想建立一個輕量級、動態的事件驅動編程模型。維也納工業大學同樣基于Serverless技術提出“設備無關邊緣計算（Deviceless Edge Computing）”，在開發者與邊緣設施之間建立一個抽象管理層，用于建立自動化的資源配置與應用管理過程。弗吉尼亞理工大學提出了微服務編排語言（Microservice Orchestration LanguagE，MOLE）。MOLE是一種聲明式領域特定語言（Declarative domain-Specific Language，DSL），開發者僅關心如何根據業務定制微服務聲明（Declarative Specifications of Microservices）即可，編譯器會根據微服務聲明產生與平臺無關的執行計劃，該執行計劃進一步由MOLE Runtime在可用的邊緣設備上執行。

圖2-15展示了使用MOLE方式的開發及調用過程，開發者根據業務需求設計服務組合腳本，規定服務間的邏輯流程。組合腳本進入編譯器后，首先會被提取微服務及相應的微服務結構圖，形成微服務執行序列。邊緣網關在接收到編譯完成后的序列后，按照執行圖組織本地的計算資源，并根據前端用戶的服務請求完成微服務的調用過程。

可以看到，面向邊緣環境編程模型的核心思想是將前端應用的多樣性、邊緣設備和資源的多樣性隱藏起來，讓開發者只需要關心其核心的服務組合與編排，不需要了解底層設備標準及開發流程，從而極大地簡化開發過程，加速邊緣服務與應用生態的發展。