核心服务概览
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#/