EdgeXFoundry里都有啥

概述

​ EdgeXFoundry最开始是由Dell公司运行IOT网关上构建的系统，后来开源出来。EdgeXFoundry就像是硬件与软件之间的一个中间件，南向链接各类设备和传感器，北向链接应用程序。EdgeXFoundry框架有四个服务层和两个基础系统服务，分别是设备服务层（Device Service），核心服务层(Core Service)，支持服务层(Supporting Service)还有应用服务层(Application Services)；以及安全服务（Security）和系统管理服务(Management)。

EdgeXFoundry系统架构图

Device Service（设备服务层）

​ Device Service在系统架构图中位于最底层的位置，是与硬件（设备和传感器）交互的一层。南向的设备如机房服务器、精密空调、路由器等等，传感器如温湿度计、烟感器等等。

Device Service设备服务能够经过与每一个设备之间的协议进行通讯，设备服务将友IoT对象生成和通讯的数据转换为通用的EdgeXFoundry数据结构，并将转换后的数据发送到核心服务层（Core Service）以及其余层的微服务。简单来讲，Device Service负责采集设备数据，完事将数据发送给其余层或其余服务；设备服务充当EdgeX与实际设备和传感器的接口

Device Service（设备服务）在首次启动的时候会作这些事情：

1. 创建有关设备服务和设备的参考消息
2. 让EdgeX其余部分知道DeivceService

3. 设置设备服务（Device Service）将经过Edgex管理设备

   这时候我问各位bro一个问题，Device Service能够单独运行吗，若是能要怎么单独运行？单独运行以后如何跟Core Service进行数据传输？答案是确定的。EdgeX的微服务的单个实例能够分布在多个主机平台上。一个或多个EdgeX微服务的主机平台称为节点。
   
   #### Core 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代理。（关系以下图）

Scheduling (计划)

​ 其实这就是一个内部调度的时钟，能够设置间隔时间操做。

Security （安全组）

​ 安全组能够包括Edgex管理的设备，传感器和其余IoT对象的数据和控制。安全组主要有两个组件，分别是：

1. Security store——用于提供安全的位置来保存EdgeX机密。EdgeX机密是其余服务链接到云系统的数据库访问密码。

   1. 在Security store微服务中存储了各类机密信息如令牌、密码、证书等等。Security store与其余微服务之间的通讯由TLS保护。

2. API gateway——用做反向代理，以限制对Edgex REST资源的访问和控制操做。

   1. API 网关是全部EdgeX REST通讯的单入口，是外部客户端与EdgeX微服务之间的一层保护，可房子和未经受权访问EdgeX REST API。API网关接收客户端请求，验证客户端身份，并将请求重定向到相关微服务。

Management （系统管理工具）

​ 系统管理工具为外部管理系统提供了中心联系点，以启动/中止/从新启动EdgeX服务，获取服务的状态/运行情况或获取EdgeX服务的指标.

写在最后：

本文只是对EdgeX框架的大体介绍，本人对EdgeX框架也是初步了解，如有不对的地方请指正。还有，若是你以为我写得还有点意思，请关注公众号 ProgrammerHe , 我在公众号等你。

本文由博客群发一文多发等运营工具平台 OpenWrite 发布