https://docs.edgexfoundry.org/1.2/microservices/core/Ch-CoreServices/
核心服务作为EdgeX南和北的协调者。正如名字一样,它们是EdgeX的核心功能,将事物固有的信息连接起来,收集传感器数据,配置EdgeX。它由以下微服务组成:
核心数据:一个持久存储库和相关管理服务,用于从南边目标收集数据。
命令:一个服务,用于帮助和控制从北边向南边的行动请求。
元数据:一个元数据的仓库和相关管理服务,它们是关于连接到EdgeX Foundry的物体。元数据提供了添加新设备的能力,并且将之与对应的设备服务配对。
登记和配置:提供了其他EdgeX Foundry的微服务信息,这些信息是关于系统内部的相关服务和微服务配置属性。
核心数据微服务提供了数据的中心持久化,数据从设备收集。收集传感器数据的设备服务,唤起核心数据服务以存储在边缘系统中的传感器数据(如网关),直到数据数据移动到北边,然后导出到企业和云平台。核心数据存储的数据位于本地数据库。Redis是默认配置,但是数据库抽象层允许使用其他数据库。
EdgeX过去使用MongoDB,通过Geneva的发行版本,MongoDB仍然支持但是被考虑弃用。过去还提供了可供选择的商业或开源实现。
核心数据有一个REST API,用于在本地存储进出数据。未来,核心数据能够扩展以发送或获取传感器数据,实现方案通过其它如MQTT,AMQP等。核心数据默认通过ZeroMQ移动数据到应用服务(和边缘分析)。EdgeX提供了一个信息总线抽象,支持ZeroMQ和MQTT。MQTT的使用要求安装一个broker,如ActiveMQ。你也能添加自己的信息总线抽象实现,如果需要的话。
默认情况下,核心数据持久了所有通过设备收集并发送给它的数据。然而,当数据太敏感而不能存储在边缘,或者数据对其他本地服务没有用(例如分析微服务),数据能够流过核心数据而不持久化。对核心数据的配置改变(PersisData=false)能够将数据发送给应用服务而不持久化。这种想法有穿过这层服务而降低延迟的优点,存储在网络边缘的需要。但是代价是没有用于分析的历史数据,需要回顾过去做出决定。
当持久层通过PersisData关闭,它是针对所有设备的。这时,你不能声明哪个设备数据被持久化和哪个不被。应用服务允许过滤设备数据,在它被导出或发送到另一个服务(如规则引擎)时,但是这不是基于数据是否被持久的。
从传感器收集数据排列到EdgeX事件和阅读对象(以JSON对象在服务REST中传送,调用核心服务)。一个事件表示一个或多个传感器阅读。一些传感器或设备只提供一个值,一次只读一个。其他传感器在读的时候吐出多个值。
一个事件至少读一个。事件与传感器或设备关联,物体感知环境然后产生了阅读。阅读表示了一个传感器或设备的感知部分。阅读只作为事件的部分存在。阅读是必要的简单的键值对,它关于感知了什么(键),值为多少(值)。一个阅读能够包含其它bits的信息以提供更多的文本(如数据类型信息)给用户。自定义的数据阅读能够包括用户接口,数据可视化系统和分析工具。
在下述图表中,描绘了一个事件与阅读。事件来自motor123设备,有两个阅读(或感知值)。第一个读表示motor123设备报告了motor的压力是1300(测量单位可能是PSI)。
上述值属性让用户了解了值的信息是整形,base64等,第二个阅读报告了相关的温度信息。
如下是核心数据的图表。设备服务发出包含一个集合的事件对象,或者当设备捕捉到传感器阅读时读取核心数据。
两个高层交互图如下:
新传感器阅读如何被设备收集,并且添加一个事件与阅读到核心数据,并且关联到持久存储。
客户(内部或外部)如何查找事件(通过设备名)
https://app.swaggerhub.com/apis-docs/EdgeXFoundry1/core-data/1.2.0#/