由於之前名字爲openedge，所以還按照openedge來介紹本文。
在兩次摸索過Openedge後，決定還是寫下博客，來記錄和明確一下開發思路和過程。那麼在openedge，將分多個部分來完成對於openedge開發記錄。
文章初步框架：
（一）openedge的框架介紹和理解
（二）openedge的配置文件介紹和詳解
（三）openedge自定義容器的使用
（四）openedge自定義函數的使用
openedge的框架介紹和理解
要想說清楚openedge，首先大家明白什麼是邊緣計算，或者至少對“邊緣”這個詞有一定的理解。而我個人理解的openedge便是部署在邊緣節點（設備）上的，因此，我們通過openedge可以完成對於支持容器化的邊緣設備的容器的管理。所以，我們依賴opendedge提供的容器引擎（docker引擎）來完成容器的部署和管理。
綜上，我們可以進一步的抽象爲，openedge就是一個通過使用消息隊列來完成容器管控的框架和軟件。
首先，我們要對openedge的具體常用概念進行一個簡單的介紹。openedge主要涉及到這幾個概念：
主程序： 指 OpenEdge 實現的核心部分，負責管理所有 存儲卷 和 服務，內置 引擎系統，對外提供 RESTful API 和命令行等。
服務：指一組接受 OpenEdge 控制的運行程序集合，用於提供某些具體的功能，比如消息路由服務、函數計算服務、微服務等。
實例：指 服務 啓動的具體的運行程序或容器，一個 服務 可以啓動多個實例，也可以由其他服務負責動態啓動實例，比如函數計算的運行時實例就是由函數計算管理服務動態啓停的。
存儲卷：指被 服務 使用的目錄，可以是隻讀的目錄，比如放置配置、證書、腳本等資源的目錄，也可以是可寫的目錄，比如日誌、數據等持久化目錄。
引擎系統： 指 服務 的各類運行模式的操作抽象和具體實現，比如 Docker 容器模式和 Native 進程模式。
服務 和 系統 的關係：OpenEdge 系統可以啓動多個服務，服務之間沒有依賴關係，不應當假設他們的啓動順序（雖然當前還是順序啓動的）。服務在運行時產生的所有信息都是臨時的，服務停止後這些信息都會被刪除，除非映射到持久化目錄。服務內的程序由於種種原因可能會停止，服務會根據用戶的配置對程序進行重啓，這種情況不等於服務的停止，所以信息不會被刪除。
因此，根據上面對於概念的描述，我們可以看出來，整個openedge的使用流程是，用戶首先需要定義自己的個性化服務，之後通過主程序調用RESTAPI將自己的服務進行實例化，變成實例。
所以我們放一張架構圖進行進一步的說明
從架構圖中我們可以看到，我們可以看到整個框架可以進一步在縱向上拆分爲三大部分：最上面的agent可以用來與雲平臺進行交互，主要是負責升級和檢測openedge的狀態；中間的Hub主要用來對接所有的MQTT消息，最主要的還是接受已經定義好主題路由的消息來進一步通知function manager；而第三部分則是通過接受MQTT消息，調用主程序的API接口，完成對服務的實例化過程。
因此，結合上面的介紹，我們不難發現，整個openedge的使用流程大致如下：
1）在雲平臺上，註冊核心、下載代碼（不然沒有辦法與雲平臺通信）
2）編寫服務，定義主題的路由轉發規則，填寫對應的yml配置文件
3）啓動主程序，完成端側程序的啓動
4）在定義好的主題下發送相應的內容（定義好的消息會通過MQTT消息轉發通知function manager ，調用API完成容器的啓動 ）
5）容器實例化後，完成函數的計算與結果的返回，並通過回程消息路由返回結果。
本次先介紹到這裏，下次就openedge的具體使用和配置方法進行進一步的介紹和說明。