由于之前名字为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的具体使用和配置方法进行进一步的介绍和说明。