概述
EdgeXFoundry最开始是由Dell公司运行IOT网关上构建的系统，后来开源出来。EdgeXFoundry就像是硬件与软件之间的一个中间件，南向连接各种设备和传感器，北向连接应用程序。**EdgeXFoundry框架有四个服务层和两个基础系统服务，分别是设备服务层（Device Service），核心服务层(Core Service)，支持服务层(Supporting Service)还有应用服务层(Application Services)；以及安全服务（Security）和系统管理服务(Management)。**
EdgeXFoundry系统架构图
file
Device Service（设备服务层）
Device Service在系统架构图中位于最底层的位置，是与硬件（设备和传感器）交互的一层。南向的设备如机房服务器、精密空调、路由器等等，传感器如温湿度计、烟感器等等。
file
Device Service设备服务可以通过与每个设备之间的协议进行通信，设备服务将友IoT对象生成和通信的数据转换为通用的EdgeXFoundry数据结构，并将转换后的数据发送到核心服务层（Core Service）以及其他层的微服务。简单来说，Device Service负责采集设备数据，完事将数据发送给其他层或其他服务；设备服务充当EdgeX与实际设备和传感器的接口
Device Service（设备服务）在首次启动的时候会做这些事情：
建立有关设备服务和设备的参考消息
让EdgeX其他部分知道DeivceService
-
设置设备服务（Device Service）将通过Edgex管理设备
这时候我问各位bro一个问题，Device Service可以单独运行吗，如果能要怎么单独运行？单独运行之后如何跟Core Service进行数据传输？答案是肯定的。EdgeX的微服务的单个实例可以分布在多个主机平台上。一个或多个EdgeX微服务的主机平台称为节点。
fileCore 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代理。（关系如下图）
file
Scheduling (计划)
其实这就是一个内部调度的时钟，可以设置间隔时间操作。
Security （安全组）
安全组可以包括Edgex管理的设备，传感器和其他IoT对象的数据和控制。安全组主要有两个组件，分别是：
- Security store——用于提供安全的位置来保存EdgeX机密。EdgeX机密是其他服务连接到云系统的数据库访问密码。
- 在Security store微服务中存储了各种机密信息如令牌、密码、证书等等。Security store与其他微服务之间的通信由TLS保护。
- API gateway——用作反向代理，以限制对Edgex REST资源的访问和控制操作。
- API 网关是所有EdgeX REST通信的单入口，是外部客户端与EdgeX微服务之间的一层保护，可房子和未经授权访问EdgeX REST API。API网关接收客户端请求，验证客户端身份，并将请求重定向到相关微服务。
Management （系统管理工具）
系统管理工具为外部管理系统提供了中心联系点，以启动/停止/重新启动EdgeX服务，获取服务的状态/运行状况或获取EdgeX服务的指标.
写在最后：
本文只是对EdgeX框架的大致介绍，本人对EdgeX框架也是初步了解，若有不对的地方请指正。还有，如果你觉得我写得还有点意思，请关注公众号 ProgrammerHe , 我在公众号等你。
本文由博客群发一文多发等运营工具平台 OpenWrite 发布
