邊緣計算節點，位于靠近物或資料源頭的網絡邊緣側，是行業數字化智能系統的核心部分。它負責對實體世界進行感覺，通過邊緣與中心雲的協同，實作對實體世界的數字化模組化、認知、決策，再由邊緣将決策結果以應用互動的方式回報到實體世界，實作整個業務流程的閉環和持續疊代演進。
邊緣場景相對于中心雲的 ICT 場景有着許多非常不同的特征，是以邊緣為核心的原生應用架構（簡稱 Edge Native）所需要考慮的：
»去中心化的，地理分布的體系架構
»資料主要在邊緣實時處理，即計算和智能将跟随資料，動态地進行部署和處理
»以事件驅動（event-driven）、流式資料（streaming）、推理、異步和實時資料處理為主
»邊緣與邊緣的互動，邊緣局部閉環自治
»多樣化、異構形态的資源配置，計算 / 網絡 / 存儲資源深度融合按場景定制，并高度離散的裝置，資源使用率低
»産品生命周期長，多廠商和多代（multi generation）
技術并存
曆史上形成的單計算節點 OS 生态已收斂，如 Windows、Linux、Android、iOS 等，簡稱“端 -OS”。過去十年風起雲湧的以 DC 為中心的雲生态高速發展又形成了“雲 -OS”如 AWS、Azure、GCP、阿裡雲、華為雲等。面向行業數字化轉型場景的邊緣計算的再次興起正在深深影響下一代的 IT 基礎設施的體系架構。僅依靠現有的中心雲架構的簡單延伸是遠遠不夠的，必須從架構角度引入新型跨域分布式的邊雲協同中間層（也可以稱之為“邊雲協同 -OS”），一方面相容廣泛且多樣化的邊緣硬體，一方面将中心雲所擁有的雲服務和雲生态能力适配後用于對邊緣業務的賦能，以實作端、邊、雲之間能夠緊密結合并互相協作，加速邊緣原生的數字化轉型解決方案的建構，并提供有效的資源配置和使用者體驗。
關于邊雲協同的能力内涵，在《邊緣計算與雲計算協同白皮書 (2018 年 )》中總結了資源協同、資料協同、智能協同、服務協同、應用管理協同、業務管理協同等六個協同。
為了更好的理順各個協同之間的層次關系，友善讀者了解，在本次白皮書中将六大協同合并到三大協同，具體來說資源協同保持不變；将原版本的資料協同、智能協同、服務協同合并到新版本的服務協同中；将原版本中的應用管理協同、業務管理協同合并到新版本的應用協同中。合并後三大協同的關鍵能力描述如下：
應用協同
應用協同實作邊緣應用的統一注冊接入，體驗一緻的分布式部署，集中化的全生命周期管理。對于邊緣計算的落地實踐來說，應用協同是整個系統的核心，涉及雲、邊、管、端各個方面。
服務協同
服務協同為邊緣應用的建構，提供了所需的關鍵能力元件以及快速靈活的對接機制，進而有效提升邊緣應用的建構速度。服務協同包括兩個層面：一個層面是平台服務的協同，在平台服務協同中又包括兩個方面，一方面是來源于中心雲的雲服務與雲生态夥伴所提供的能力，包括資料類、智能類、應用使能類的能力。另一方面是通過雲原生架構，提供基于 Operator 架構的服務接入架構，為邊緣服務的分發訂閱、接入、發現、使用、運維提供一整套流程。
另外一個層面，對于雲原生架構中的微服務，提供跨越邊和雲的服務發現和協同機制，使得位置感覺的資料傳輸轉變為位置透明的、基于服務化的業務協同。
資源協同
從單節點的角度，資源協同提供了底層硬體的抽象，簡化上層應用的開發難度。從全局的角度，資源協同還提供了全局視角的資源排程和全域的 Overlay 網絡動态加速能力，使得邊緣的資源能否有效率的使用，邊緣與邊緣、邊緣與中心的互動能夠更實時。
邊緣與中心雲間的三大類協同
應用協同
綜述
應用協同是指使用者通過邊緣計算平台在雲上的管理面将開發的應用通過網絡遠端部署到使用者希望的邊緣節點上運作，為終端裝置提供服務，并且可以在雲上進行邊緣應用生命周期管理。應用協同還規定了邊緣計算平台向應用開發者和管理者開放的應用管理北向接口。對于邊緣計算的落地實踐來說，應用協同是整個系統的核心，涉及雲、邊、管、端各個方面。
相比集中在資料中心的雲計算，邊緣計算的邊緣節點分布較為分散，在很多邊緣場景中，如智能巡檢、智慧交通、智能安防、智能煤礦等，邊緣節點采用現場人工的方式對應用進行部署和運維非常不友善，效率低成本高。邊緣計算的應用協同能力，可以讓使用者很友善地從雲上對邊緣應用進行靈活部署，大大提高邊緣應用的部署效率，降低運維管理成本，為使用者邊緣場景實作數字化、智能化提供了基礎。這也是應用協同對于邊緣計算場景的價值所在。
關鍵挑戰
»傳統邊緣應用部署的實體節點分布可能較為分散，部署過程中存在大量需要人工現場操作的步驟，部署方式不夠靈活友善，效率低下。邊緣應用缺少邊雲協同管理方案，邊緣計算平台也缺少統一的應用管理北向接口。
»邊緣計算複雜場景下應用分發比較困難。使用者應用部署到海量的邊緣節點上，需要大規模分發應用的鏡像。邊緣和中心雲之間一般跨網絡連接配接，網絡的穩定性相對較差。中心鏡像倉庫高并發下載下傳帶來高昂的帶寬成本也是一個非常嚴重的問題。另外，使用者應用日益複雜化，跨越邊雲的分布式應用場景越來越多，但是對應的跨邊雲應用分發機制還比較缺乏。
»邊雲計算場景下邊緣應用管理困難。邊緣節點與雲端通過城域網互聯，漫長的網絡鍊路使得二者連接配接不夠穩定，且易因各種不确定因素導緻邊緣節點整體斷連。在斷連後，邊緣節點及其上的應用執行個體将處于離線狀态，并且缺乏 IT 維護人員及時的管理恢複。此時邊緣應用會出現不可用的問題，邊緣側的業務連續性及可靠性都将受到極大的挑戰。
整體架構
面對上述挑戰，邊緣計算應用協同系統整合邊緣節點資源，通過邊緣管理子產品與雲上控制子產品合作，共同完成應用協同。目前邊緣計算領域多種技術架構并存，其中基于雲原生技術的邊緣計算架構發展迅速，并逐漸成為主流。這裡以基于雲原生技術的邊緣計算為例給出系統參考架構，同時該架構對于邊緣計算領域其他技術也有一定參考價值。邊緣計算邊雲應用協同系統參考架構如下圖所示，整個系統分為雲上和邊緣兩個部分，雲上部分包含雲上控制面和雲端鏡像倉庫，雲上控制面主要用于接收使用者送出的應用部署請求資訊并對邊緣應用進行生命周期管理，雲端鏡像倉庫主要用于對使用者送出的應用鏡像進行分級轉發緩存；邊緣部分主要為邊緣節點和邊緣鏡像倉庫，邊緣節點用于為邊緣應用提供運作環境和資源，邊緣鏡像倉庫為邊緣應用提供具體的鏡像加載服務。
使用者将其開發的應用通過邊緣計算平台下發部署到邊緣節點上運作，是以需要邊緣計算平台提供清晰明确的應用部署接口。應用部署接口定義了使用者與邊緣計算平台之間的互動方式與功能邊界。
邊緣計算平台為使用者提供标準化的北向接口，開放各種應用部署和排程能力，使用者的所有應用部署需求，都以服務請求的形式向邊緣計算平台送出，邊緣計算平台将執行結果以服務響應的形式傳回給使用者。使用者使用邊緣計算平台進行應用部署，應該對應用的目标形态提出需求，以部署配置檔案的形式進行描述，并送出給邊緣計算平台。
邊緣計算平台會根據使用者送出的需求以及既定的排程政策，選擇最能滿足使用者需求的節點進行排程，擷取相關節點資源，建立應用執行個體，建立相關資源如中間件、網絡、消息路由等，完成應用在邊緣節點上的下發部署。使用者通過北向接口送出的應用的部署需求，通常會涉及如下方面：
»工作負載資訊：包括應用的鏡像位址、應用執行個體數量、應用标簽資訊、應用環境變量配置等等。
»排程政策：應用排程政策是邊緣計算平台排程能力的外在呈現方式，使用者隻能在平台既定的架構下選擇、制定符合自己需求的排程政策。更精細、更高效、更靈活的排程政策需要邊緣計算平台自身更強大的排程能力作為内在支援。從使用者的角度來講，應用排程政策可能會包括如下類型：将應用部署到指定邊緣節點或邊緣區域；将應用自動部署到使用者通路最密集的地區；保證一定百分比的應用執行個體所處地區的網絡延遲低于給定值；在給定的節點組上部署并保證各個節點負載均衡；在達到指定服務效果的前提下資源費用最低等等。
邊雲協同應用協同系統架構
資源需求：資源需求代表每個應用執行個體在邊緣節點上運作所需要的資源數量下限值和上限值，當一個節點無法提供滿足下限值的資源時，表示邊緣節點資源不足，應用執行個體不會被平台排程到該節點上執行，當一個應用執行個體運作所占用的資源超過上限值時，表示應用程式可能發生了異常，需要緊急停止。常用資源類型包括 CPU、記憶體、存儲、網絡帶寬、GPU、NPU 等。
»網絡需求：應用對于網絡 QoS 和 QoE 有一定需求，包括網絡抖動、網絡時延、吞吐率等等
»部署模式：應用在邊緣的部署模式，可以分為兩類，一類為根據部署政策和排程結果直接将應用執行個體部署到對應節點，一類為收到用戶端通路請求後觸發應用執行個體的部署。
»中間件需求：未來如資料庫、5GC 等能力會以中間件的形式提供給應用進行使用，使用者可以向平台提出應用對中間件的需求，由平台來将相關中間件進行執行個體化，為使用者應用提供服務，避免使用者自己管理中間件的風險。
關鍵技術
1、應用分發
»應用親和性分發
利用應用親和性特性，可以将有關聯的應用部署到同一個節點以提升應用間互動效率。一個 Pod 裡的多個容器可以共享存儲和網絡，可以看作一個邏輯的主機，共享如 namespace，cgroups 或者其他的隔離資源。一個Pod 裡的多個容器共享 Pod 的 IP 和端口 namespace，這些容器之間可以通過 localhost 來進行通信，所需要注意的是不同容器要注意不要有端口沖突即可。不同的Pod 有不同的 IP，不同 Pod 内的多個容器之間不可以使用 IPC（如果沒有特殊指定的話）通信，通常情況下使用Pod 的 IP 進行通信。一個 Pod 裡的多個容器可以共享存儲卷，這個存儲卷會被定義為 Pod 的一部分，并且可以挂載到該 Pod 裡的所有容器的檔案系統上。
»應用大規模分發技術
邊緣計算場景中，使用者應用需要部署到海量的邊緣節點上，需要大規模分發應用的鏡像。這種應用大規模分發場景的部署速度、部署成功略等性能受制于短時間高并發讀取、網絡穩定性、網絡帶寬等問題。容器應用部署過程中需要下載下傳容器鏡像檔案，如果在大規模邊緣叢集環境中，比如 100K 台邊緣節點，每個應用鏡像按照500MB 計算，如果直接從中心鏡像倉庫下載下傳，資料量是50000GB，這對于鏡像倉庫的沖擊是緻命的。邊緣和中心雲之間一般跨網際網路連接配接，網絡的穩定性相對較差，比如煤礦礦井邊緣、工廠工廠中的房間邊緣、公路邊緣場景，很難保證邊緣與中心雲網絡連接配接的穩定性。中心鏡像倉庫下載下傳帶來高昂的帶寬成本也是一個非常嚴重的問題，這對于提供鏡像倉庫的雲服務提供商來說是不可接受的。邊緣計算平台可以采用鏡像分級緩存、邊緣鏡像站點加速、P2P 分發等方法來提高應用大規模分發性能。
»跨邊雲統一部署技術
使用者應用日益複雜化，跨越邊雲的分布式應用場景越來越多。與雲計算環境相比，應用在邊緣側部署和運作受本地環境的影響非常大，而本地環境自身又是非常不穩定的，充滿了不可預知性和動态性，是以邊緣計算平台需要根據環境資源資訊動态調整業務部署。當邊緣側環境發生重大變故時，包括邊緣節點故障、邊緣側使用者請求飙升等等，邊緣側的資源無法滿足使用者應用的計算需求，此時需要将業務負載遷移回雲上運作，以保障使用者應用的可用性。是以邊緣計算平台需要提供應用跨邊雲統一部署能力，以實作使用者應用的邊雲協同，并且能夠向應用開發者屏蔽這種因部署位置的差異性帶來的特殊設計和開發工作量。
»serverless 技術
邊緣應用的開發者希望能夠專注于應用開發工作，而應 用 的 構 建、 部 署 和 運 行 問 題 則 交 給 平 台 來 自 動 完成。serverless 技術的出現使得使用者隻需要編寫函數代碼（function）和包含函數建構部署資訊的配置檔案（config），将代碼檔案和配置檔案送出給平台就可以自動将代碼建構成應用，并将應用執行個體部署到邊緣側或雲端叢集，無需關注具體建構和部署細節。serverless 技術提供标準化的應用開發流程，為邊緣應用的開發人員節約了大量的時間和精力，大大提升了邊緣應用開發、運維和疊代的效率。以雲原生的 serverless 技術為例，整個系統分為建構系統（Build）、服務系統（Serving）和事件系統（Eventing）。建構系統可以将使用者代碼進行編譯，并且自動化建構應用容器鏡像。服務系統可以将建構好的應用執行個體下發部署，按需對邊緣應用負載規模進行自動化伸縮，并且為邊緣應用配置好相應的流量路由規則和服務通路通路。事件系統可以将事件源進行抽象，并對生産、消費等事件通過消息通道進行有效傳遞，同過訂閱機制進行事件處理。
2、應用管理
»應用離線自治技術
相較于傳統的以雲資料中心為核心的雲服務，邊緣計算所服務的業務領域有着自己的獨有的特點。在邊緣節點與雲端正常連接配接時，邊緣節點及其上的應用的生命周期管理都由雲上的管理元件負責。然而，邊緣節點與雲端通過城域網互聯，漫長的網絡鍊路使得二者連接配接不夠穩定，且易因各種不确定因素導緻斷連。在斷連後，邊緣節點及其上的應用執行個體将處于離線狀态，并且缺乏 IT 維護人員及時的管理恢複。此時，邊緣側的業務連續性及可靠性都将受到極大的挑戰。是以，邊緣節點在離線場景下的管控是邊緣計算服務必不可少的功能之一。邊緣應用離線自治技術通過維護邊緣節點監控關系清單、排程優先級清單及邊緣資訊同步機制，能夠保障邊緣節點在雲端管理面斷開的場景下進行離線自治，維持系統正常運作，直到邊雲連接配接恢複正常。
»多裝置多副本互備
邊緣節點運作狀态和網絡狀态不穩定，可能會出現單個節點運作故障或者網絡斷開，這些問題都會導緻該節點上運作的應用執行個體不可用。對于無狀态應用，可以建立多個副本，同時添加應用部署的反親和性特性，維持預設副本數的同一應用的不同執行個體在不同節點上分散部署運作，可以避免單節點故障導緻所有應用執行個體全部不可用的問題，提升應用的可用性。
服務協同
綜述
服務是指具備明确的業務特征，由一個或多個關聯緊密的微服務組成，可直接面向客戶 / 使用者進行打包、釋出、部署、運維的軟體單元。
服務協同是指通過在邊緣計算平台提供使用者需要的關鍵元件能力，以及快速靈活的服務對接機制，進而提升使用者邊緣應用的建構速度，在邊緣側幫助使用者服務快速接入邊緣計算平台。服務協同主要包括兩個方面，一方面是來源于中心雲的雲服務和雲生态夥伴所提供的服務能力，包括智能類、資料類、應用使能類能力。另一方面是通過雲原生架構，提供一套标準的服務接入架構，為邊緣服務的接入、發現、使用、運維提供一套完整流程。智能類服務是在人工智能場景下，通過使用人工智能服務對海量資料進行預處理及半自動化标注、大規模分布式訓練，生成自動化模型，并支援部署到雲上和邊緣。
利用邊緣服務将其推送到邊緣節點，提供邊緣傳輸通道，關聯邊緣和雲端資料；邊緣 AI 服務實時擷取資料，通過推理進行瑕疵檢測，根據結果調整生産裝置參數，并将資料和結果周期上傳回雲端，用于持續模型訓練和生産分析。
資料類服務按照距離使用者的遠近可以分為雲端資料庫和邊緣資料庫。雲端資料庫即是部署在雲端，負責對雲上服務處理的資料進行存儲，并提供高效的查詢等，雲端資料庫存儲資料量大，查詢響應快，但是邊緣計算場景下，由于和使用者裝置過遠，資料傳輸慢，導緻無法實時響應使用者資料請求，無法很好滿足使用者實際述求。是以邊緣場景下延伸出了邊緣資料庫概念，顧名思義邊緣資料庫是部署在邊緣側的，它的好處是離終端裝置近，終端裝置進行采集資料後上報到邊緣端的服務非常快，而邊緣端的服務經過分析計算後可以持久化存儲在邊緣裝置中，這樣即保證了資料的實時處理，也使得當邊緣網絡端開時，邊緣資料庫儲存的資料可以支援邊緣自治。在邊緣場景下，資料采集頻繁，上報資料量大，會産生大量備援以及不符合規範的資料，對資料的分析挖掘造成了很大的麻煩，需要邊緣側進行資料清洗和資料分析整合使用邊緣時序資料庫等保證資料的時序，當實時處理後，可以根據資料的具體類型和場景，協同上報到雲端資料庫中進行進一步處理，或者在本地存儲待後續使用。
應用服務主要是對一般中間件等有狀态的服務部署場景中，如何部署在邊緣場景進行分布式運作。由于中間件等有狀态服務架構複雜，涉及很多複雜化處理，是以應用服務主要提供的是邊雲分布式開發架構和運作架構，通過提供标準的接入規範和開發架構，可以幫助這類服務快速內建開發，并且能夠友善的部署內建到邊緣計算環境中，同時這種統一的開發架構，可以友善應用服務的改造，幫助不同形态服務的遷移，滿足快速上雲訴求。而運作架構，則提供了規範的運維規範、運作中通信規範等，另外還提供了開箱即用的微服務注冊、發現和通路機制，可以幫助服務進行全生命周期的管理，并且滿足跨邊雲應用協同，在邊緣計算場景中，不同的裝置、不同的邊緣雲設施中，都可以快速無縫協同工作，進而提高服務協同能力，降低使用者使用難度，部署難度以及運維難度。
關鍵挑戰
邊緣計算場景下，服務協同面臨着幾個較為嚴峻的挑戰：
»資料存儲困難，性能可靠性無法保證。随着越來越多的業務連接配接到物聯網，與 IoT 關聯産生的資料量和時序資料越來越多，而邊緣側資源緊張，對資料存儲的成本、響應的性能和可靠性産生了極大的挑戰，随着業務種類不同，資料的上報結構各不相同，對資料的存儲也帶來了極大的不便。
»資料量大，實時性無法得到保證。邊緣智能場景下，大量裝置接入邊緣雲，上報資料量大，采樣類型種類多，導緻資料存在大量備援情況，對于智能化場景産生極大挑戰，而邊緣側場景的高實時要求又是一大難題。
»應用接入不規範，難以統一管控。邊緣服務涉及多種類型服務接入，其中資料服務、智能服務、應用服務等開發架構、語言以及使用方式都不一樣，導緻服務協同部署運維難度增大，跨雲場景也因為接入方式不一緻而無法統一管理。
»服務協同下服務運維困難。由于服務大部分需要部署在邊緣側，而邊緣處的裝置大多數都處于機房、基站等偏遠地點，站點維護人員技能低，導緻裝置資料收集困難甚至無法收集，一旦服務出現問題存在無法自愈或者修複複雜等情況。
微服務的流行，解決了單體式應用不能快速疊代、限制技術棧的選擇、技術債務不斷堆積等問題，但同時也引入了新的問題，那就是微服務化應用之間的互動。
随着業務的發展，部分雲上能力需要下沉到邊緣以提供更低的時延、更少的帶寬占用、更高的網絡安全和更好的隐私保護。但邊緣的資源往往是有限的，應用需要利用雲的海量資源和彈性。微服務需要根據業務需求智能地部署在邊和雲的任何位置。邊邊、邊雲微服務互動中出現的邊雲應用通路困難、缺少服務發現和流量治理機制等問題亟待解決。
整體架構
服務協同架構是為邊緣應用的建構，提供所需的關鍵能力元件以及快速靈活的對接機制，進而提升邊緣應用建構速度而設計。其主要可以分為兩個子產品：服務開發架構和服務市場。
服務開發架構提供了靈活的接入機制，友善使用者服務可以快速接入邊緣計算平台，為邊緣服務的接入、發現、使用、運維提供一套整體流程。
服務市場則對接生态，借力合作夥伴的能力，将不同的智能類、資料類以及應用使能類服務接入到服務市場內建使用，達到快速建構邊緣服務的能力。
邊緣計算服務協同架構
如圖所示，服務協同分為兩個主體角色：服務開發者和服務使用者，開發者作為服務提供者，根據自身業務需要進行代碼開發，然後根據服務接入規範以及服務協同架構中提供的開發架構進行內建打包，封裝出可以部署在邊緣計算平台中的服務，然後上傳到服務市場中對外提供服務；服務使用者則訂購服務市場中的服務，并根據使用場景進行訂購下發部署請求。服務協同架構通過利用應用協同架構能力，将服務下發到對應的雲端或者邊緣節點中去，邊緣節點按照雲端政策實作對應服務，通過邊緣與雲端的協同實作面向客戶的按需的邊緣服務；而雲端則負責其本身需要的服務能力和對邊緣節點的分布政策的控制。
服務開發架構主要包括兩個方面：
1、統一标準的接入規範，由于服務開發的架構、語言使用習慣等的千差萬别，接入規範可以保證在相容使用者的服務并統一服務部署運作運維等能力，保證服務可以無縫接入邊緣計算平台；
2、接入開發架構，提供符合業界标準的開發架構，為邊緣服務的接入、發現、使用、運維提供一整套流程，幫助使用者隻需要專注業務的開發。
服務市場則是對接不同生态服務，發展雲生态夥伴包括智能類、資料類應用使能類服務的接入，并對接開源Operator 架構，将有狀态中間件服務接入提供給使用者使用，幫助使用者邊緣服務的快速建構接入。
關鍵技術
1、邊雲協同資料使能
随着越來越多的事物連接配接到物聯網，與 IoT 裝置相關聯的資料量及其生成的時序資料量（包括裝置狀态、中繼資料和傳感器讀數）呈指數級增長。然而，邊緣側計算資源緊張，對資料庫性能、資料存儲成本、可靠性等都提出了新的挑戰。同時，随着資料源的多樣化和業務發展，要求邊緣資料庫要能靈活存取多種資料模型，降低業務變更難度和運維成本。
時序資料是指帶有時間标簽，按時間順序變化的資料。
通常時序資料有如下幾個特點：
»資料量大，每秒上千、上萬甚至于上億條資料
»時間特性強，資料通常按照時間順序抵達
»主要是寫入和讀取操作，沒有更新操作
»大量的統計查詢要求
時序資料庫作為一種針對時序資料進行高度優化的垂直型資料庫 , 可以很好的解決前面的問題，它提供時序資料的大并發，低延遲時間，高性能，高壓縮，低成本，schemaless 資料存儲，還能提供多種次元的聚合分析和趨勢洞察。
傳統的關系型資料庫并不适用于時序業務的場景，到目前為止，關系型資料庫處理大資料集的效果依舊不理想，且占用存儲空間大，缺少一些共通的對時間序資料分析的功能和操作，比如資料保留政策、連續查詢、靈活的時間聚合等。
下面介紹下時序資料庫的一些基本概念
Metric: 度量，相當于關系型資料庫中的 table。
Point: 資料點，相當于關系型資料庫中的 row。
Timestamp：時間戳，代表資料點産生的時間。
Field: 度量下的不同字段。比如位置這個度量具有經度和緯度兩個 field。一般情況下存放的是會随着時間戳的變化而變化的資料。
Tag: 标簽，或者附加資訊。一般存放的是并不随着時間戳變化的屬性資訊。
Series: 時間線，一個資料源采集的一個名額随着時間的流逝而源源不斷地吐出資料這樣形成的一條資料線稱之為時間線。
邊雲協同的時序資料庫的關鍵技術主要包括：
»輕量級
邊緣節點計算資源有限，相比雲端資料庫而言，邊緣時序資料庫作為雲端資料庫的延伸，保留資料庫的基本功能，去掉了一些不必要的功能，比如分布式，備份恢複等。輕量級資料庫具有對環境的依賴小，占用記憶體空間少的特點。
»資料協同與可靠性
根據圖所示，資料協同由端 - 邊 - 雲共同完成，數采的資料直接接入邊緣中心節點，一般會經過實時分析、資産分析後，再存入邊緣時序資料庫，供邊緣開放 API做時序分析查詢。此時資料庫中的資料會定期與雲端進行彙總。由于資料在存儲時進行了壓縮，為了節省傳輸帶寬和性能，我們常常以資料檔案的方式與雲端進行同步。此外，由于邊緣時序資料庫是一個輕量級資料庫，為保證資料庫的可靠性，中心節點采用雙合主備模式，數采網關采取雙寫。當邊緣主中心節點出現問題時，備中心節點可以馬上接管業務，不會造成資料丢失和業務中斷。
»LSM Tree
傳統資料庫或現在一些 NoSQL 資料庫存儲采用的都是 Btree，這是由于其在查詢和順序插入時有利于減少尋道次數，對于 90% 以上場景都是寫入的時序資料庫，B tree很明顯是不合适的。邊緣時序資料庫采用 LSM Tree，通過将大量的随機寫轉換為順序寫，進而極大地提升了資料寫入的性能。
»列式存儲與向量化
針對時序資料普遍的分析統計查詢場景來看，需要對所有 Filed 進行統計的情況并不多，列式存儲引擎将資料按照基于列的方式進行集中存儲，查詢過程中可以定位到指定列，可有效降低資料庫系統負載，提高整個查詢的吞吐量。同時，列式存儲可以使用一些基于列資料壓縮算法，由于資料類型相同，資料集中，壓縮算法的性能會更好，可以大大的減少資料的存儲成本。
向量化查詢是一種基于列式存儲設計的高效查詢算法，現在已成為建構高效分析查詢引擎流行做法，相比經典的火山模型，向量化查詢大大減少了查詢的疊代次數，能有效提升整個查詢的性能。
»查詢結果緩存（rollup cache）
在資料的分析統計中，我們常常需要計算 Filed 的值在指定時間窗内的和或者平均值等，設定查詢結果緩存可以記錄下每次查詢的時間窗和傳回值，如果需要在更大時間窗内進行統計，則可以依賴已緩存的時間窗和值進行計算就可以快速得到結果，進而省掉再次查詢的時間和資源消耗，能有效提升使用者體驗。
»記憶體配置設定與回收
在計算資源有限的情況下，合理配置設定程式使用記憶體尤為重要，邊緣時序資料庫可以根據實際情況配置程式運作中各種 cache 使用的記憶體大小以及總記憶體大小。記憶體配置設定對應是記憶體回收，當 cache 使用已達到配置上限時，邊緣時序資料庫需要有高效的 cache 回收算法，将過期的或者最近未使用的記憶體進行回收置換，同時還要保證較高的 cache 命中率。
2、邊雲協同 AI 使能
随着 AI 技術在邊緣越來越多的廣泛應用，同時也帶了巨大的挑戰，包括：
»AR、VR、互動直播、視訊監控等場景下非結構化資料為主 , 主要采用深度學習方法，主要挑戰在資料量大 ,資源用量大，實時要求高，标注困難等。
»工業場景下 IoT 結構化資料為主，主要使用傳統機器學習算法，方法多樣，與業務相關性高，主要挑戰是樣本少、冷啟動和要求模型可解釋和可靠性。面對上述問題，通過邊雲協同 AI 的相關技術可以很好解決這些問題。在邊緣計算場景下，AI 類應用占據主流。
由于邊側計算資源緊缺、網絡環境複雜，以及資料量樣本量少、資料樣本分布不均、資料隐私等原因，AI 類應用在邊緣的訓練和推理還存在着訓練收斂時間長、訓練效果差、推理精度低、推理時延高等問題。通過邊雲協同 AI 技術以很好的解決在邊緣訓練和推理的精度、時延、通信量、資料隐私等問題。邊雲協同 AI 架構将會在算法、接口、部署、性能幾個方面帶來了好處：
»算法：內建多種适合邊緣的訓練推理算法，适用場景廣。
»接口：提供邊雲協同的 lib 庫代碼，相容主流架構，tensorflow，pytorch，mindspore；開發簡單，原生架構的訓練代碼經過很少改動可以實作其邊雲協同的。
»性能：針對邊雲協同進行了通訊、存儲的優化，使得邊雲協同的訓練推理更高效。邊雲協同 AI 架構的關鍵技術包括：增量學習、聯邦學習、聯合推理。
1）增量學習：
增量學習真對單個租戶從時間的次元幫助提升模型效果。資料在邊緣側持續産生，傳統的方式是人工定期的收集這些資料，定期的在雲上或邊上的機器進行重新訓練以改進模型效果。這種方式浪費較多的人力，并且模型更新的頻率較慢，不能及時用上最新更優的模型。通過增量學習，可以持續監控這些新産生的資料，并通過配置一些觸發規則來決定是否要啟動訓練、評估、部署，以自動化的持續改進模型效果。
2）聯邦學習：
聯邦學習跨多個租戶從空間的次元幫助提升模型效果。資料天然是在邊側産生的，邊雲協同聯邦學習通過邊緣側的資料聯合訓練得到一個模型，目的是基于不上傳原始資料的前提下，能充分利用分散在不同邊側的資料。
單租戶場景，基于資料不願意上雲的假設下，租戶希望直接利用在邊緣産生的資料就近在邊緣節點進行訓練得到模型，但資料在租戶内部是分散在不同節點的，在租戶内部集中訓練需要另外采購集中訓練的機器會帶來額外的采購成本，是以可以采用邊雲協同聯邦學習，直接使用邊緣節點的計算能力進行訓練，使用雲上的聚合器進行聚合，在保證資料隐私和高效傳輸的前提下，提供更快的收斂速度，精度更高、場景更豐富的聚合算法，以完成模型的聯合訓練。
3）協同推理：
協同推理利用推理性能較強的雲作為推理後端來提升推理效果。
對于推理來說，直接在邊側推理可以有更小的時延和更大的吞吐，而直接在雲側推理可以帶來更好的推理精度。如何在邊側推理資源有限的情況下，使得時延和吞吐不明顯降低的情況下，使得推理精度提高是個問題。協同推理技術通過把把邊側較難的推理樣本檢測出來，将其發送到雲端進行推理。這樣，較簡單的樣本在邊側推理保證了時延和吞吐，而較複雜的樣本在雲上推理使得整體精度得到提升。
Workers:
»執行訓練或推理任務，訓練 / 推理程式，基于現有 AI架構開發。為了使用邊雲協同的能力，worker 中通常會包含 lib 庫。
»按需啟動，docker 容器或 function。
»不同特性對應不同的 worker 組合，可部署在邊上或雲上，進行協同。比如協同推理特性可以是雲上的一個 worker 運作大模型、邊上的一個 worker 運作小模型，協同完成推理任務。
»Worker 可以是使用者基于一個基礎鏡像開發的，或者系統内置一些固定功能的 worker 模闆，比如聯邦學習的聚合器。
Lib:
»面向 AI 開發者和應用開發者 , 暴露邊雲協同 AI 功能給應用
»Lib 庫不是一個新的、也不會取代現有的機器學習架構，更多的是配合主流架構（TensorFlow、Pytorch、Mindspore）以完成邊雲協同能力的擴充。使用者使用此 lib 庫不會對現有的訓練推理代碼帶來較大的改動。
GlobalCoordinator：
»統一邊緣 AI 服務 API，這是使用者使用邊雲協同 AI 的入口，在此建立邊雲協同訓練或協同推理任務。
邊雲協同 AI 架構
»跨邊緣管理：管理 LocalController 的生命周期。
»跨邊緣協同：協調在雲上或邊上的 worker 以共同完成協同訓練或者協同推理任務。
LocalController：
»特性本地流程控制，本地 worker 生命周期的管理。
»本地通用管理 : 模型 , 資料集等
»狀态監控和上報：協同推理和訓練的任務狀态監控，上報到 GlobalCoordinator。
3、平台服務接入
目前雲計算場景下，衍生了非常多的開發語言，Java、Go、C/C++、nodejs 等等，相關的開發架構也有非常多，是以導緻了不同的服務平台中接入的方式互不相同，這也導緻了如果一套服務在一個平台運作後需要遷移到另一套雲平台中，必須進行代碼版本的改造，進而加大了遷移成本，導緻大量人力物力都耗費在無價值的事情中。
随着邊緣計算逐漸興起，使用者的應用服務日益複雜化，跨邊雲的分布式應用場景越來越多，跨雲部署、治理以及管理運維的述求越來越多，而不同平台之間的架構模型差異，接入差異導緻了使用者服務的接入困難，是以需
要一套統一的服務接入标準，通過定義出行業認可的服務接入規範，規範不同平台的接入規則，進而使得一套服務可以無障礙部署在不同平台，保證跨雲管理變得簡單，無需在花費時間在考慮服務遷移改造等問題。接入平台服務需要滿足一下幾個方面：
»支援不同的開發語言、開發架構
»支援目前通用的通信協定
»具有成熟的部署、運維能力
目前服務協同使用了如下技術作為接入規範的參考基準：
1、基于 Operator 概念的 Operator-Framework 架構技術從概念上講，Operator 會收集人類操作知識，并将其編碼成更容易分享給消費者的軟體。
Operator 是一組軟體，可用于降低運作其他軟體的操作複雜程度。它可以被看作是軟體廠商的工程團隊的擴充，可以在 Kubernetes 環境中監控軟體的運作情況，并根據軟體的目前狀态實時做出決策。
從技術上講，Operator 是一種打包、部署和管理 Kubernetes應用程式的方法。
使用 Operator 可以：
»重複安裝和更新。
»持續對每個系統元件執行運作狀況檢查。
»彙總現場工程師了解的情況并傳輸給所有使用者，而非一兩個使用者。
Service Broker 也是朝着實作應用程式的程式設計式發現和部署的目标前進了一步，但是它并非一個長時間運作的程序，無法執行第二天的操作，比如更新、故障轉移或擴充。而 Operator 可以持續監控叢集的目前狀态，這對于邊緣雲服務場景下的叢集形态則更加合适。
開源的 Operator-Framework 則是基于 Operator 概念衍生的一個新技術，其本質是一個開源工具包，用以有效、自動化和可伸縮的方式管理 Kubernetes 原生應用程式。
該架構由 Operator SDK 和 Operator Lifecycle Manager（OLM）兩個部分組成。
OLM 擴充了 Kubernetes，提供了一種聲明式方法來安裝、管理和更新叢集中的 Operator 服務以及其依賴。
它使得 Kubernetes 管理者能夠從目錄中發現并安全安裝Operaotr，并根據使用者需要進行自動或手動式更新。
Operator SDK 提供了進階 API、有用的抽象和用于建構Kubernetes 應用程式的項目腳手架，并使用 controller-runtime（控制器運作時）庫簡化操作器的編寫。
Operator-Framework 是目前業界比較成熟且廣泛接受的技術，服務協同架構基于該技術，同時根據不同場景定義統一規範接入标準，形成使用者界面的統一管控，提高服務的接入、運維等成本，極大的提供使用者體驗。
2、Open Service Broker API
服務代理者（Service Broker）是用來管理服務的生命周期，平台與服務代理者互動以提供、通路和管理他們的服務。OSBAPI（Open Service Broker API）則在此基礎上提出了一種規範，可以允許軟體供應商、SaaS 提供商和開發者輕松運作在 Cloud Foundry、Kubernetes 等雲原生平台上，并為其工作負載提供後備服務。這種規範已經被許多平台和數千個服務提供者采用，用于描述一組簡單的 API endpoints，而這些 endpoints 可用于設定、通路和管理服務産品。OSBA 定義了這些互動，允許軟體提供商向任何人提供服務，而不管這些軟體提供商希望使用什麼技術或基礎設施。基于 OSBA 規範建構的 Service Broker 服務都有相同直覺的生命周期指令集。這些指令集具有以下操作：
»擷取服務代理提供的後續服務
»發放新業務執行個體
»銷毀服務執行個體
采用此模型帶來的好處是：1、開發人員可以将自己的應用程式和容器連接配接到他們需要的背景服務，無論背景服務如何，操作都是一緻的；2、不再需要人工發放和委托服務，隻需要進行配置服務和計劃市場，減少許多管理開銷。
4、跨邊雲服務發現和流量治理
»區域網路内邊邊服務發現和流量治理在該場景下要求互相通路的邊緣節點之間網絡能夠互通，具體見下圖。
區域網路内邊邊服務發現和流量治理
»API Gateway
所有的應用程式都不會運作在一個封閉的環境中，當有使用者或者第三方應用程式接入時，一定會在系統的某個邊界開放部分微服務，這正是 API Gateway 要解決的問題——将微服務在叢集邊界特定端口暴露，供叢集外部應用通路。一個邊緣叢集會被切割為多個邊緣現場，形成多個網絡域，同一現場内的邊緣節點可以互相通信，不同現場間的邊緣節點不能互相通信。具體見下圖。
API Gateway
»跨邊雲的服務發現和流量治理
邊緣計算的初期階段人們會說“我需要把 A 應用部署在邊緣”；随着業務的發展，人們會說：“我邊上的 B 應用需要通路雲上的 C 應用，雲上的 D 應用需要通路邊緣的 E應用”；最後，人們會說：“我的 F 應用需要通路 G 應用，F 和 G 智能的運作在最适合它的地方”。見下圖所示。
應用智能運作在合适位置
跨邊雲服務發現和流量治理是應用智能運作在合适位置的基礎，邏輯模型見下圖所示。
跨邊雲應用的服務發現和流量治理
資源協同
綜述
邊緣基礎設施通常由多個邊緣節點裝置（邊）組成，包括部署在城域網絡側的近場邊緣雲、5G MEC、工廠的現場邊緣節點、工廠的智能裝置如機器人等，提供邊緣計算所需的算力，存儲，網路資源。
為了降低上層應用适配底層硬體的難度，就需要通過一個中間層次來對底層硬體進行抽象，使得上層應用可以用一點接入、一次适配、一緻體驗的方式來使用邊緣的資源。從單節點的角度，資源協同提供了底層硬體的抽象，簡化上層應用的開發難度。從全局的角度，資源協同還提供了全局視角的資源排程和全域的 Overlay 網絡動态加速能力，使得邊緣的資源能否有效率的使用，邊緣與邊緣、邊緣與中心的互動能夠更實時。
挑戰
»裝置異構挑戰：邊緣硬體的計算 / 網絡 / 存儲資源和容量，往往會深度按業務場景進行定制。邊緣硬體的計算架構也呈現出多樣化的趨勢。同時，産品生命周期長，多廠商和多代技術并存。因而在建構邊緣解決方案時，就需要考慮如何能夠更好的對異構和多樣化的邊緣裝置進行抽象、管理和運用。
»資源受限挑戰：單個邊緣節點的資源是受限的，如果應用需要實作彈性伸縮或故障切換，需要由多個邊緣節點組成某種形式的邊緣節點組或叢集，應用在此叢集内進行部署、伸縮和治理。
»邊邊 / 邊雲通信挑戰：典型的實時互動類場景如線上教育、雲遊戲等，對于多個邊緣節點之間、邊緣節點到中心雲之間的通信鍊路，都有比較明确的業務要求。
如何能夠實時建構和維護，低延遲時間、高品質、低成本的邊邊 / 邊雲通信鍊路，是一個關鍵的技術挑戰。
整體架構
資源協同具體來說包括三個方面：
»硬體抽象：通過插件架構的形式，對邊緣硬體的計算、存儲、網絡等資源進行模型抽象，使得不同的硬體廠家可以為自己的産品提供插件化的定義和描述，向應用開發者和運維人員提供了一個統一的資源能力描述、部署、運維管理方式。
邊緣計算資源協協同架構
»全局排程：對于是需要實作廣域化、多節點部署的邊緣業務，實作基于政策的全局資源排程，使得應用可以靈活的按照自定義的政策實作應用執行個體的多節點部署和動态切換。
»全域加速：實作從中心雲到邊緣、邊緣到邊緣之間的互聯互通、高效的消息路由，進一步還可以建構全局的 Overlay 網絡實作各節點的優化尋址和動态加速，為基于服務品質和确定性時延的政策排程打下堅實基礎。
關鍵技術
1、基礎設施服務化
結合場景和應用部署需求的多樣化，邊緣計算節點在資源層面，往往需要提供多類型的計算方案，包括基于裸機、虛拟機、容器甚至函數計算等。其中基于 Docker 和Kubernetes 的容器計算，由于結合了輕量化、易管理、開放性、豐富的能力等多個特點，是面向未來最有潛力的邊緣計算模式。
Docker 疊加 Kubernetes 建構了一個可移植的、可擴充的邊緣計算平台，用于管理容器化的工作負載和服務，可促進聲明式配置和自動化。Kubernetes 擁有一個龐大且快速增長的軟硬體生态系統。基于 Kubernetes 與基 礎 設 施 分 離， 支 持 可 在 Ubuntu、RHEL、CentOS、CoreOS 等主流的 OS，是以可以支援多樣化的硬體部署。
因而，基于 Kubernetes 建構的邊緣計算平台也可以繼承類似的異構多樣化硬體的能力，用來實作對于異構邊緣硬體的發現、監控和排程。
邊緣計算平台，通過提供一個硬體裝置抽象的裝置插件架構（Device Plugin Framework），建立了 Kubernetes和裝置插件子產品之間的橋梁。它一方面負責裝置資訊的上報到 Kubernetes，另一方面負責裝置的排程選擇。
硬體廠商可以為自己的硬體定制實作對應的裝置插件，用來将系統硬體資源和監控資訊釋出到邊緣平台。目标裝置包括 GPU、高性能 NIC、FPGA、InfiniBand 擴充卡以及其他類似的、可能需要特定于供應商的初始化和設定的計算資源。裝置插件可通過手動部署或作為DaemonSet 來部署。如下圖所示。
邊緣硬體裝置抽象架構
邊緣硬體裝置抽象架構包括以下幾個關鍵能力：
»裝置插件的注冊：裝置插件需要以用戶端的身份向邊緣節點代理上報以下幾個資訊：1）裝置插件所管理的裝置名稱；2）裝置插件所監聽的端口；3）互動的API 版本。
»服務啟動：裝置插件會啟動一個背景服務并以這個服務對外提供資訊。
»持續監聽：當裝置插件所關聯的服務啟動之後，邊緣節點代理會建立一個到裝置插件的監聽長連接配接，用來擷取裝置的配置設定情況及裝置的健康狀态。
»更新資訊到管控節點：邊緣節點代理會将這些裝置及相關資訊，上報到邊雲協同 OS 管控平台中，以便後續排程器可以根據這些資訊進行排程。
2、全域排程
很多邊緣應用場景都涉及到區域化多點分布的邊緣基礎設施的使用。比如以熱門的直播應用為例，直播應用的最終使用者是海量的 C 端使用者，而且直播應用的體驗也逐漸向實時互動場景延伸，比如線上連麥、互動遊戲直播等。
這就要求直播應用的提供商能夠在靠近使用者的多個省市的城域邊緣分别部署邊緣業務，滿足業務互動所需的低延遲時間要求。
單個邊緣節點的資源是受限的，且邊緣資源的定價也可能在不同的位置不同時段上有差異，因而邊緣解決方案需要提供一套排程機制，能夠在時延、性能、價格等限制下，擷取最有效的資源配置設定政策。如何根據任務和資源的特性進行合理的全域排程。在保證服務品質的前提下，将使用者從伺服器的管理中解放出來，同時從全局角度優化資源的使用率，是一個非常有挑戰力的課題。
全域排程的排程對象為億級的終端和百萬級的主機（邊緣雲和中心雲），這些裝置以分布式的形态存在，在保證服務品質的前提下，如何高效的打通端、邊、雲的界限，成為全域排程的核心關鍵。全域排程系統的設計會面臨以下挑戰：
»大規模：終端和主機規模龐大，增加管理面的控制難度和算法設計難度。
»異構性：每個裝置的資料存儲和處理能力，網絡時延各不相同。對接口的統一性、傳輸協定和時鐘的同步問題，都提出了巨大的挑戰。
»動态性：網絡品質随着時間變化而變化，同時任務的請求也有随機性，對系統和排程算法的魯棒性提出了挑戰。
全域排程主要涉及兩個次元的資源排程，一類是計算資源、另一類是流量資源。資源排程器根據全局資源的狀态和網絡 QoS 統計資訊，為每個租戶推薦資源分布決策建議。流量排程器根據資源的分布情況，在流量級進行精細化排程。
全域排程方案示意圖
（1）全域資源排程
使用者在使用邊緣計算服務時，由于無法掌握全局的動态資源資訊，目前隻能靠人工經驗指定位置要求固定的資源容量。這樣對于租戶，沒有辦法擷取到最優質的資源改進業務服務品質，同時也缺乏應對業務突發的彈性手段。全域資源排程器，可以幫助使用者即時掌控全域資源狀态資訊，包括動态的邊緣站點可用資源、臨近公有雲資源以及優質的 5G MEC 資源，滿足使用者對服務 ( 例如網絡時延 ) 的要求，同時在保證整體 QoS 最優下，可以針對成本、服務品質、業務波動做針對性優化。典型的應用場景包括：
故障切換場景：邊緣站點故障時，快速向周邊邊緣節點或公有雲申請彈性計算資源，完成故障業務的快速恢複。
»業務彈性場景：區域過載場景，局部業務突發時，可以快速排程周邊可用資源，實作業務彈性擴充，平滑度過業務峰值。
»資源排程的關鍵點是全局資源視圖和資源排程算法。資源視圖包括使用者的位置，資源的成本，網絡的 QoS,接入的地理位置等。全域排程的政策可以支援預置政策或可定義政策，典型的預置政策包括時延優先、成本優先、可靠性優先政策等。
（2）全域流量排程
在給定業務節點已完成部署配置設定的情況下，流量排程為使用者的每一位客戶流量通路請求的配置設定處理節點。流量排程具有與業務高度相關的特點，針對不同業務的類型，流量排程的方法各不相同。例如，CDN 業務中，流量排程要同時支援接入排程和回源排程，且排程算法的設計需要考慮到内容緩存政策的影響。雲遊戲業務中，流量排程隻需要支援接入排程即可。
流量排程基于曆史資料完成流量粗粒度的流量規劃以保障基礎水位均衡，并基于分鐘級的流量特征學習，決策控制周期和配置設定政策，對流量進行全局性的優化。實時排程器負責針對每個區域租戶請求的實時響應，執行、切換排程政策，并當發生故障時，及時完成故障轉移。
3、全域加速
邊緣節點分布比較廣泛，因成本的原因邊緣到中心、邊緣到邊緣之間無法建構專線連接配接。而傳統 Internet 通過OSPF、BGP 等标準路由協定進行實體網絡傳輸（Underlay方式），它通過鍊路 Cost 進行路由選路轉發，路徑擁堵發生丢包率、時延等 QoS 故障，不會流量感覺切換，導緻無法滿足業務應用 QoS 品質訴求。
線上教育，雲遊戲、雲桌面、雲 VR 等邊緣應用場景都涉及邊緣到中心、邊緣到邊緣之間低延時高品質互聯通信的需求。可以在基于傳統 Internet Underlay 網絡的基礎上，建構多點分布的邊緣雲 Overlay 網絡平面，同時實時測量 Overlay Link 的 QoS（時延、丢包率），選擇最佳 QoS Overlay 路徑流量轉發。為上層業務應用屏蔽複雜的網絡環境，提供低延遲時間、低丢包率、價格合适的選路方案。
全域加速的方案包括以下幾點關鍵能力：
»拓撲建構：根據預先定義結合自動發現機制，建立邊緣節點之間 Full-Mesh 鄰居關系，通過探測封包實時測量兩兩鄰居之間時延 / 丢包率。進一步，對于時變路由可預測未來一段時間（如 5~10 分鐘）隧道 QoS品質。
»路徑優化：基于 AI 訓練預測未來時刻流量 QOS 進行路徑選路，結合政策定義的限制，推薦最優化路徑建議；
»Overlay 轉發：基于最優隧道路徑，向源裝置壓入轉發包路徑清單，中間節點根據包路徑層層逐跳快速轉發；轉發過程中實作丢包重傳和 FEC 自适應糾錯轉發優化。
»故障切換：實時探測邊緣節點和網絡路徑的狀态，并實時計算各路徑 QoS。邊緣節點故障或者隧道斷開故障，可以實時上報更改轉發路徑。隧道擁塞 QOS 質差，則需要通過定期（如 5~10 分鐘）全量路徑計算切換。
全域加速方案示意圖
【來源：邊緣計算産業聯盟 、工業網際網路産業聯盟 《邊緣計算與雲計算協同
白皮書2.0》】