下一代雲原生邊緣裝置管理標準DMI的設計與實現

　　了很多行業業務的創新，越來越多的裝置、應用執行在端側，併產生大量的資料。如何更好地解耦業務應用開發和裝置資料訪問，為裝置提供完整的生命週期資料管理，釋放裝置資料的價值？如何在保證叢集可用性的同時，高效管理和傳輸裝置資料，獲得更為方便、靈活的資料訪問方式？雲原生邊緣計算的方案選擇可以幫助使用者更好地應對這類問題。

　　KubeEdge裝置管理架構的設計實現，有效幫助使用者處理裝置數字孿生程式中遇到的場景。使用者可以透過KubeEdge，將物理裝置抽象成數字孿生，用雲原生的方式對裝置和資料進行管理。

　　一、KubeEdge裝置管理框架

　　圖 1 KubeEdge裝置管理架構設計

　　KubeEdge裝置管理架構設計如圖1所示，具體流程如下：

　　1. 使用者呼叫Kubernetes API介面，建立Device CRD例項到KubeEdge

　　2. KubeEdge雲上元件CloudCore watch到Kubernetes中Device CRD例項建立訊息

　　3. 此時CloudCore會做兩件事情，一方面CloudCore透過雲邊websocket通道下發Device Twin資訊到EdgeCore，另一方面CloudCore會生成一份包含Device Profile資訊的Configmap，該Configmap是以Node名稱為索引，掛載到對應Mapper的Pod中的

　　4. Mapper透過讀取掛載的Configmap中的Device Profile資訊，更新本地維護的Device list列表

　　5. EdgeCore把接收到的Device Twin資訊傳送到指定的mqtt topic

　　6. 該節點上的所有Mapper都會收到該Device Twin訊息，並根據Device名稱來匹配是否是自己維護的list中的Device

　　7. Mapper根據Device Profile資訊，透過對應的協議與裝置建立連線

　　8. Mapper透過mqtt topic上報裝置狀態和採集的資料Device Twin到EdgeCore

　　9. EdgeCore透過雲邊websocket通道上報Device Twin資料到CloudCore

　　10. CloudCore更新裝置Device Twin資料到Kubernetes

　　二、DMI框架設計

　　在此基礎上，KubeEdge團隊也對框架不斷更新迭代。為幫助使用者應對未來更大規模裝置場景、更高的可用性需求、更靈活的功能支援以及更優的使用者體驗，KubeEdge 設計了更最佳化的裝置管理框架——DMI。

　　DMI整合裝置管理介面，最佳化邊緣計算場景下的裝置管理能力，打造基於雲原生技術的，覆蓋裝置管理、裝置資料的裝置數字孿生管理平臺；同時定義了EdgeCore與Mapper之間統一的連線入口，並分別由EdgeCore和Mapper實現上行資料流和下行資料流的服務端和客戶端，承載DMI具體功能。

　　DMI框架設計中解耦了裝置管理面與裝置業務面資料，讓Device CRD只承載裝置本身的生命週期管理，而裝置業務面資料則直接透過微服務的方式為資料消費者應用提供出來。在這樣的架構下，裝置就不再是單純的資料來源，而是一種雲原生的裝置微服務，裝置資料消費應用的開發者就可以不再關心如何獲取裝置資料，而是以更雲原生的方式來聚焦應用本身的業務邏輯開發。DMI框架還提供多種資料推送方式，讓資料消費者可以更靈活地獲取裝置資料，使用者體驗更優。

　　由於DMI的裝置管理面與業務面資料分離的特點，業務面資料可以透過業務面通道更靈活地在雲端或邊端被處理，而管理面的雲邊通道中只會傳輸少量管理面資訊，大大降低了雲邊通道擁塞的可能，提高了KubeEdge系統的可用性。另外，DMI提供了統一的裝置管理相關介面，無論是裝置應用開發者還是裝置應用的使用者，都可以以更統一、更靈活、更標準化的方式來開展裝置相關工作，不拘泥於具體形式，只要能夠實現DMI介面，就能夠享受KubeEdge邊緣計算平臺帶來的雲原生裝置管理體驗。

　　▍2.1 DMI框架定位

　　圖 2 DMI 在 KubeEdge 架構中的定位

　　DMI在KubeEdge架構中的定位如圖2所示。DMI類似Kubernetes的CNI、CSI、CRI等介面，定義了一組EdgeCore與Mapper之間的內部API介面以及外部應用訪問Mapper的統一的API介面。其中內部介面底層由gRPC結合UDS的方式來實現，外部API介面支援mqtt和REST兩種接入方式。Mapper不論是何種承載、實現方式，只要實現了DMI中所定義的上行、下行資料介面，即可接入KubeEdge雲原生邊緣計算平臺，使用雲原生的方式對裝置進行管理。

　　▍2.2 DMI裝置管理與資料管理

　　DMI框架架構設計如圖3所示，其中黃色線條為裝置管理面資料流管理，藍色部分為業務面資料流管理。

　　在DMI的架構設計中，將裝置的管理面資料與業務面資料進行分離。其中管理面資料主要包括裝置的後設資料、裝置屬性、配置、狀態、生命週期等，其特點是相對比較穩定，建立後除狀態上報外的資訊更新較少，更貼近Pod型別資源所產生的資料，在保證使用者可以透過雲端Kubernetes API像訪問Pod一樣維護Device的生命週期的同時，儘量減少裝置管理產生的額外資料傳輸開銷。

　　圖 3 DMI裝置管理與資料管理架構

　　在DMI框架設計下，裝置不再是單純的資料來源，而是被抽象為微服務，以雲原生的方式為裝置資料消費者提供資料服務。DMI框架下的裝置資料訪問支援多種場景，更加靈活。圖3中列出了幾種主要的資料訪問方式，包括推資料和拉資料等，具體情況如下：

　　1. 邊緣側應用透過REST Service訪問裝置資料

　　2. 雲側應用透過REST Service訪問裝置資料

　　3. Mapper透過配置REST目的地址，將資料推送到邊緣側應用

　　4. Mapper透過配置REST目的地址，將資料推送到雲側應用

　　5. Mapper透過配置目的地址，將資料推送到邊緣側資料庫

　　6. Mapper透過配置目的地址，將資料推送到mqtt broker

　　7. 邊緣側應用透過mqtt broker topic訂閱裝置資料

　　8. 雲側應用透過mqtt broker topic 訂閱裝置資料

　　9. 邊緣側應用處理資料後將處理結果傳上雲

　　▍2.3 DMI工作流程

　　圖 4 DMI裝置管理工作流程示例

　　在DMI框架下，裝置管理工作的流程有一定的變化。如圖4所示，在安裝KubeEdge的時候，雲端CloudCore會註冊DeviceController元件用於監聽Device和DeviceModel的CRD資源。DeviceController中存在兩個模組，Downstream Controller和Upstream Controller，其中Downstream Controller用於監聽雲端的Device、DeviceModel事件，並透過Cloudhub下發至邊緣，Upstream Controller用於接收從Cloudhub轉發來的EdgeHub上報的Device狀態和訊息，並更新Kubernetes中的Device狀態。在邊緣側，Mapper初始化的時候，需要呼叫DMI中的Mapper註冊介面，將Mapper的相關資訊註冊至Device Manager，並接收介面返回的已下發至該節點的且協議匹配的裝置資訊。EdgeHub在接收到雲端下發的裝置訊息時，會將其轉發到DeviceManager元件，DeviceManager會根據該裝置的協議選擇對應的Mapper驅動程式，傳送建立裝置的請求，並且本地資料庫也會儲存該裝置的資訊，後續Mapper會將裝置孿生訊息轉化為裝置協議格式，跟實際的物理裝置進行通訊。

　　三、DMI介面定義

　　▍3.1 DMI 介面分類

　　DMI介面實現了EdgeCore與Mapper之間的通訊，支援REST和mqtt的通訊方式，並以標準化的形式呈現，降低了Mapper開發、適配難度。在資料訪問方面，DMI可以實現邊緣側和雲側的應用都可以透過REST Service的方式訪問裝置資料。

　　圖 5 DMI介面定義

　　如圖5所示，DMI有六類介面，Mapper管理是針對邊緣側各類裝置協議驅動程式，Device管理和Device資料管理對管理面和業務面進行了資料拆分，Device升級管理和Device命令管理為具有升級和命令執行功能的裝置提供相關的介面，Device事件管理可以監控Mapper及其納管的各個裝置的執行狀態。

　　▍3.2 DMI 介面定義示例

　　圖 6 DMI裝置管理部分介面定義示例

　　如圖6所示，為DMI裝置管理部分介面定義，v1版本以gRPC proto的方式定義，可使用make dmi命令建立對應的gRPC-go程式碼。

　　▍3.3 DMI 裝置相關 CRD 定義

　　如圖7所示，是DMI裝置相關CRD定義，主要分為Device和DeviceModel。其中DeviceModel與裝置型號是一一對應的關係，代表同一類裝置型號的共有屬性，主要包含裝置產生資料屬性Properties和裝置支援命令屬性Commands。Device為裝置例項，與真實的物理裝置為一對一的關係，每個DeviceModel可以對應統一型號的多個Device例項。Device型別資源主要包含裝置型號對應關係資訊、裝置協議配置資訊、裝置部署節點資訊、裝置狀態資訊以及裝置資料Property採集配置資訊。

　　圖 7 DMI 裝置相關 CRD 定義

　　四、釋出計劃

　　DMI釋出計劃分為三個版本，Alpha版本提供裝置管理相關功能實現，以及提供一個支援DMI介面的Mapper Demo。Beta版本支援裝置命令管理、裝置升級管理以及裝置資料管理的能力，此外還會對接第三方平臺，並提供相關對接Demo。GA版本會對多平臺、多協議進行對接支援，另外會把裝置安全以及事件管理的功能補全。

　　圖 8 DMI釋出計劃

　　目前 KubeEdge Device IoT SIG 專注於第一階段的裝置管理和 Mapper Demo 的開發工作。歡迎大家透過下方聯絡方式聯絡我們，一起參與到方案設計和特性開發的工作當中。