EdgeXFoundry裏都有啥

概述

​ EdgeXFoundry最開始是由Dell公司運行IOT網關上構建的系統，後來開源出來。EdgeXFoundry就像是硬件與軟件之間的一箇中間件，南向鏈接各類設備和傳感器，北向鏈接應用程序。EdgeXFoundry框架有四個服務層和兩個基礎系統服務，分別是設備服務層（Device Service），核心服務層(Core Service)，支持服務層(Supporting Service)還有應用服務層(Application Services)；以及安全服務（Security）和系統管理服務(Management)。

EdgeXFoundry系統架構圖

Device Service（設備服務層）

​ Device Service在系統架構圖中位於最底層的位置，是與硬件（設備和傳感器）交互的一層。南向的設備如機房服務器、精密空調、路由器等等，傳感器如溫溼度計、煙感器等等。

Device Service設備服務能夠經過與每一個設備之間的協議進行通訊，設備服務將友IoT對象生成和通訊的數據轉換爲通用的EdgeXFoundry數據結構，並將轉換後的數據發送到核心服務層（Core Service）以及其餘層的微服務。簡單來講，Device Service負責採集設備數據，完事將數據發送給其餘層或其餘服務；設備服務充當EdgeX與實際設備和傳感器的接口

Device Service（設備服務）在首次啓動的時候會作這些事情：

1. 創建有關設備服務和設備的參考消息
2. 讓EdgeX其餘部分知道DeivceService

3. 設置設備服務（Device Service）將經過Edgex管理設備

   這時候我問各位bro一個問題，Device Service能夠單獨運行嗎，若是能要怎麼單獨運行？單獨運行以後如何跟Core Service進行數據傳輸？答案是確定的。EdgeX的微服務的單個實例能夠分佈在多個主機平臺上。一個或多個EdgeX微服務的主機平臺稱爲節點。
   
   #### Core Service（核心服務層）

​ 核心服務是EdgeX的核心部分，是南北橋的中介。Core Service包含 核心數據（coreData），命令（Command）,元數據（Metadata），註冊表和配置（Registry ＆ Config) 等這些微服務。

元數據（metadata）

​ 元數據會存儲鏈接到EdgeX對象的元數據存儲庫和相關的管理服務。 元數據提供新設備與設備服務配對的能力。簡單來講設備配置文件Device Profile就是上傳到元數據中存儲。能夠經過GET向metadata獲取全部的Device Profile，PUT和ID更新配置文件，經過POST建立一個全新的DeviceProfile文件。（DeviceProfile設備配置文件記錄了設備的名稱描述版本生產商，有哪些屬性和方法等等）

​ 元數據微服務知道該如何與傳感器、其餘服務（核心數據coredata ,核心命令core command）進行通訊。元數據能管理鏈接到EdgeX的設備、知道設備報告的數據以及知道如何向設備發送命令；但元數據就好像幕後大BOSS，老闆吩咐員工去作事；元數據不會經過Device Service和core Data進行數據採集；一樣元數據不會向設備直接發送命令，命令由核心命令（core Command）和設備服務（Device Service）執行。

核心數據（coreData）

​ 核心數據微服務爲採集回來的數據提供持久化的服務。Device Service採集來的數據流到coreData，coreData會將數據存儲到系統邊緣（如網關）並提供必定的安全性性和保護，直到數據向北移動。說到核心數據，繞不開的還有Event/Readings。Event表明一個或多個傳感器讀數的集合，傳感器採集到數據後發送的EdgeX是一個事件。Reading表明設備或傳感器的響應。

命令（Command）

​ 命令是通用的，標準化的。通常發送兩類指令給設備——GET&PUT。GET命令從設備請求數據，這經常使用於請求設備獲取最新的傳感器數據。PUT指令則會發送指令給設備，使其開關機或做出一些調整。

Suppoting Service （支持服務層）

​ 支持服務包括普遍的微服務，包括邊緣分析、日誌記錄、調度和數據清理等；支持服務包括規則引擎、計劃、日誌記錄、警報和通知。目前在EdgeX v1.2版本中已經棄用了Logging服務，日誌記錄會在EdgeX之後的版本中被刪除。

Alerts ＆ Notifications (警報和通知)

​ 在EdgeX框架中通知是很是重要的，當緊急事件發生時接收方可選適當的方式收取通知，包括SMS，郵件，REST回調，MQTT等等。通知微服務接收通知時，通知都在內部傳遞到通知處理程序。通知處理程序首先會保留通知，而後給定通知爲緊急時將其當即傳遞到分發協助器，如果正常狀況則將消息傳遞到消息調度程序。

Rules Engine ＆ Kuiper Rules Engine

​ 規則引擎在EdgeX v1.2中已經被啓用。在Geneva中EdgeX與 EMQ X Kuiper合做。而Kuiper是一個輕量級的開源軟件，實現物聯網邊緣分析和流處理，用戶能夠實現快速的數據處理並編寫SQL語句。Kuiper規則引擎基於三個部分組成，Source、 SQL、Sink

​ Source是流數據的源頭，能夠是MQTT服務器，也能夠是EdgeX的消息總線。SQL是處理指定業務邏輯的地方，用於提取、過濾或轉換數據。Sink用於將分析結果發送到特定目標，例如將結果發送給MQTT代理。（關係以下圖）

Scheduling (計劃)

​ 其實這就是一個內部調度的時鐘，能夠設置間隔時間操做。

Security （安全組）

​ 安全組能夠包括Edgex管理的設備，傳感器和其餘IoT對象的數據和控制。安全組主要有兩個組件，分別是：

1. Security store——用於提供安全的位置來保存EdgeX機密。EdgeX機密是其餘服務鏈接到雲系統的數據庫訪問密碼。

   1. 在Security store微服務中存儲了各類機密信息如令牌、密碼、證書等等。Security store與其餘微服務之間的通訊由TLS保護。

2. API gateway——用做反向代理，以限制對Edgex REST資源的訪問和控制操做。

   1. API 網關是全部EdgeX REST通訊的單入口，是外部客戶端與EdgeX微服務之間的一層保護，可房子和未經受權訪問EdgeX REST API。API網關接收客戶端請求，驗證客戶端身份，並將請求重定向到相關微服務。

Management （系統管理工具）

​ 系統管理工具爲外部管理系統提供了中心聯繫點，以啓動/中止/從新啓動EdgeX服務，獲取服務的狀態/運行情況或獲取EdgeX服務的指標.

寫在最後：

本文只是對EdgeX框架的大體介紹，本人對EdgeX框架也是初步瞭解，如有不對的地方請指正。還有，若是你以爲我寫得還有點意思，請關注公衆號 ProgrammerHe , 我在公衆號等你。

本文由博客羣發一文多發等運營工具平臺 OpenWrite 發佈