共计 2875 个字符，预计需要花费 8 分钟才能阅读完成。
概述
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（设施服务）在首次启动的时候会做这些事件：
- 建设无关设施服务和设施的参考消息
- 让 EdgeX 其余局部晓得 DeivceService
设置设施服务（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 对象的数据和管制。平安组次要有两个组件，别离是：
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 公布
