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官方文档：
https://wiki.edgexfoundry.org/display/FA/Introduction+to+EdgeX+Foundry#IntroductiontoEdgeXFoundry-Introduction
2.运行EdgeX Foundry

如何运行EdgeX Foundry，请参考官方文档，已经很详细：
https://wiki.edgexfoundry.org/display/FA/Get+EdgeX+Foundry±+Users

这里补充一条官方文档没有的启动细节：
官方文档有最小化启动环境，而且是要按照官方指定的顺序和步骤启动，个人研究后发现，还可以有更小的启动方式：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

这是本人根据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

原作者：huaqiaoz
来源：https://www.edgexfoundry.club/user/huaqiaoz/article/5bc1b181cedad55c32d6cc8b