==================================----- 下面为前人的综合简介: --------=======================================
1.EdgeX Foundry简介.
EdgeX Foundry是Dell发起的物联网解决方案,整个框架采用微服务架构,核心微服务包含8个,4个支撑微服务,和若干设备驱动层的微服务,具体如下:
核心微服务
微服务名 | 描述 |
---|---|
volume | 数据卷微服务,所有数据都会持久化在这个微服务中。 |
config-seed | consul注册和配置中心,config-seed启动的时候,会读取本地所有其他微服务的配置文件到consul的配置中心,所有微服务如果在docker中运行,从consul配置中心中读取各自的配置文件。 |
mongo | mongoDB数据库,所有其他微服务持久化到mongoDB数据库,mongoDB的持久化文件本质上存储在volume微服务中。 |
log | 日志微服务,所有其他微服务的日志操作,都会异步和log微服务通信,持久化日志信息。 |
notification | 通知微服务,比如一个device的增删改查动作都会通过邮件、消息队列等方式向指定的目标发送通知。 |
core-data | 核心数据微服务,这里面有个值描述符(value descriptor)的概念,这个概念中包含的field是从device profile文件中的device resource中得到。 |
core-metadata | 核心元数据微服务,这里存储的是物理设备的元信息,这些元信息是用户从设备手册上得到,并编写到device profile文件中,然后经由该微服务持久化到mongoDB数据库。 |
core-command | 核心命令微服务,所有的设备的命令必须经由该微服务发送到device service层的设备驱动微服务,然后由设备驱动微服务发送到物理设备,本质上核心命令微服务中的设备命令也是从用户编写的device profile文件中得到。 |
支撑微服务
微服务名 | 描述 |
---|---|
scheduler | scheduler微服务,官方解释用于任务调用、数据清洗等,至于如何调度,暂没有深入研究。 |
export-client | 导出client微服务,需要和export-distro微服务配合使用,用于接收用户调用API后,持久化相关数据到mongoDB数据库,其实任何一个其他常规微服务,比如core-data,core-metadata,core-command等,都有一个对应的client工程,但是并没有当做一个微服务启动,这里的为什么会单独启动一个微服务,暂时未知,个人认为,可以合并到export-distro微服务。 |
export-distro | 导出数据到云端微服务,负责用户指定的一系列导出任务,官方文档表示是可以直接导出到云端的,但是经过研究,如果要导出到自己的云端还需要二次开发才可以,而且导出的数据是原始数据,实际生产环境无特别的意义,因为没有边缘计算一说了,也就是说,暂时无法把通过自己业务逻辑计算后的数据发送到云端展示,该功能模块待研究。 |
rule engine | 规则引擎微服务,用于智能化边缘测,比如得到一个设备的数据经过计算后,触发一系列规则让其他设备做出动作,本质上是给device service层发送设备已有的命令。 |
设备驱动微服务
微服务名 | 描述 |
---|---|
device-virtual | 虚拟设备微服务,该微服务用于测试模拟虚拟设备。 |
device-mqtt | mqtt协议的设备微服务,通过mqtt协议和设备通信。 |
device-modbus | modbus协议设备微服务,通过modbus协议和设备通信,如何添加,请参考“添加真实物理设备”章节,有视频演示。 |
device-bluetooth | 待研究 |
device-snmp | 待研究 |
device-bacnet | 待研究 |
device-fischertechnik | 待研究 |
更多详情可参考EdgeX Foundry官方文档:
2.运行EdgeX Foundry
如何运行EdgeX Foundry,请参考官方文档,已经很详细:
https://wiki.edgexfoundry.org/display/FA/Get+EdgeX+Foundry+-+Users(原文中的此链接已经失效)
https://wiki.edgexfoundry.org/display/FA/How-to+articles (updated)
这里补充一条官方文档没有的启动细节: 官方文档有最小化启动环境,而且是要按照官方指定的顺序和步骤启动,个人研究后发现,还可以有更小的启动方式:volume,config-seed,mongo,log,core-data,core-metadata,core-command和任何一个device service层的驱动微服务,其中volume,config-seed,mongo这三个非常规微服务必须在其他微服务启动之前启动完毕,尤其是config-seed微服务。
3.添加真实物理设备
虚拟设备微服务device-virtual,可以模拟三个设备,而且这个三个设备的是具备主发数据能力的,入手EdgeX Foundry人员一定要理解设备主发数据和被动发送数据,之前在和社区的人交流的时候,有人就对这两个概念不理解,认为设备不就是一直在发送数据嘛,还有的人员认为,设备只能是被动发送数据,其实设备是可以具备主动发送数据能力的,不然device-mqtt驱动微服务如何通订阅得到你的设备发来的数据?对于串口协议如device-modbus驱动微服务,那设备是被动发送数据的,也就是你需要给设备发送一个设备能识别的命令,设备才会把数据返回给你,这两点请相关阅读人员慢慢了解消化。
下面的链接是EdgeX Foundry官方文档,演示如何给不同的设备驱动微服务添加设备,已经很详细了,这里不再赘述。
https://wiki.edgexfoundry.org/display/FA/APIs--Device+Services+Layer(已失效)
https://wiki.edgexfoundry.org/display/FA/EdgeX+Documentation (updated)
https://fuji-docs.edgexfoundry.org/Ch-APIReference.html (updated)
这是本人根据EdgeX Foundry官方文档说明,添加一个modbus协议的温湿度传感器的视频演示,包含如何连接物理设备到gateway上,如何编写device profile文件,如何发送命令,这里面通过edgex ui添加设备的,edgex ui使用方式请看下一个小节。https://www.youtube.com/watch?v=_2AHiUcMzew&t=472s
4.EdgeX UI (又名 EdgeX Foundry Web Console)
EdgeX UI是本人开发的一个可以在web页面端操作添加设备,获取设备的网页图形界面,避免了操作人员在操作的过程中需要调用不同的API,拼接复杂的数据结构等步骤。 EdgeX UI前端基本从0写起,后端有java和go语言两个版本,go语言版本由EdgeX Foundry负责人要求的,目的在于轻量,一直处在维护状态,java版本已经数月没有更新,不建议使用java版的EdgeX UI。 用户只需执行如下命令即可启动edgex ui:
docker pull badboyqiao/edgex-ui-go:0.1.1
docker run -it -d -p 4000:4000 --name edgex-ui-go badboyqiao/edgex-ui-go:0.1.1
(亲测有效)
源码链接: https://github.com/edgexfoundry-holding/edgex-ui-go edgex-ui-go已经被官方仓库收录:https://github.com/edgexfoundry/edgex-ui-go
5.小结
EdgeX Foundry涵盖的前沿技术之多,逻辑之复杂,文字描述难以盖全,这里仅仅介绍一些个人所得,更深入的问题还需要深入研究理解,具体详情可以在每周三周六晚十点的zoom中细聊,里面有各类大神演示和分享经验,下面是zoom链接:https://VMware.zoom.us/j/3697467292
===============================---------
上面为前人的综合介绍 : 原文地址:https://www.edgexfoundry.club/articles/users/huaqiaoz/5bc1b181cedad55c32d6cc8b
--------=======================================