Core Services Layer - Configuration and Registry

发表于 | 分类于 | | 阅读次数:
字数统计: 1,546

Core Services Layer - Configuration and Registry：

  • Introduce to Configuration and Registry
  • Core Services Microservices - Configuration
  • Core Services Microservices - Registry

1. Introduce to Configuration and Registry

配置和注册表的微服务提供集中式（即EdgeX Foundry-wide）管理

  • 任何EdgeX Foundry微服务的配置和操作参数
  • EdgeX Foundry微服务的位置和状态

作为配置管理器，配置和注册表微服务在微服务启动时为每个微服务提供配置信息。此配置信息会覆盖微服务可能具有的任何内置配置，并提供满足微服务架构动态特性的方法。例如，配置和注册表微服务提供的配置信息可能会为另一个EdgeX Foundry微服务提供一个新的操作端口号，由于其默认端口号已被运行EdgeX Foundry的系统使用。配置和注册表微服务还提供了向EdgeX Foundry微服务通知配置更改的方法。这允许其他微服务动态地响应环境的变化。

作为EdgeX Foundry微服务注册表，配置和注册表微服务知道所有EdgeX Foundry微服务的位置和运行状态。当每个EdgeX Foundry微服务启动时，它被要求使用配置和注册表微服务注册自己。然后，配置和注册表微服务定期“ping”其他微服务，以准确了解微服务集合的健康状况。这为其他EdgeX Foundry微服务、系统管理系统和第三方应用程序提供了一个具有权威性的地方去获得EdgeX Foundry状态。

EdgeX Foundry微服务可以在没有配置和注册表微服务的情况下运行。当他们这样做时，他们使用内置配置初始化/配置自己并在本地而不是全局操作 - 也就是说，他们不会在任何中央机构或其他微服务中注册它们。如果没有配置和注册表微服务，每个其他微服务只能对位置（通过其自身的本地初始化提供）和其他微服务的运行状态做出假设。

2. 配置 ( Configuration )

对于Configuration，Configuration and Registry微服务集中并简化了不断增长的服务配置数据。Configuration微服务以开源服务Consul为基础，提供Key和Value Store，客户可以通过RESTful API访问EdgeX Foundry。

有关更多信息，请参阅Consul官方网站：https： //www.consul.io

1.png

当每个微服务启动时，会发生一个特殊的“引导”阶段，以便加载自己的配置数据。在“引导”阶段，客户端微服务尝试通过RESTful API访问配置微服务，并遵循命名约定来检索自己的配置数据。此外，客户端微服务在本地准备默认配置文件。如果由于任何错误而无法访问配置微服务，则客户端微服务会不断重试。当Configuration微服务不可用时，客户端微服务无法启动并报告错误消息。

物理上，“配置”服务和“注册表”服务在同一个Consul服务器节点上组合并运行。

2.1 命名约定 ( Naming Convention )

  • 键/值存储

Configuration微服务利用Consul提供的Key / Value Store存储配置数据，每个键包含一个以斜杠（“/”）分隔的命名空间，例如“/config/core-metadata/server.port”指定端口核心元数据微服务的数量。本节定义键的命名约定。

所有配置密钥都应存储在命名空间“/ config”下，然后将微服务ID存储为第二级命名空间。当微服务部署到不同的运行时环境时，通常一些配置细节会有所不同。例如，数据库连接的细节在开发环境中通常与在质量保证环境中不同，并且在生产环境中不同。基于配置文件的配置可以解决此问题。

配置文件是一种条件配置，其中根据运行时活动的配置文件使用或忽略不同的配置设置。例如：当EdgeXFoundry微服务放在Docker容器中进行部署时，配置文件用于提供特定于Docker环境的配置（例如config / core-metadata; docker）。例如“/config/application/logging.level”和“ /config/application/logging.path”。

例如，ID为“testApp”且带有“dev”配置文件的微服务会加载以下命名空间：

2.png

/ config / application命名空间中的配置数据适用于使用Configuration微服务的所有微服务。/ config / testApp命名空间中的配置数据仅适用于名为“testApp”的微服务实例。

下表显示了此示例中Key / Value Store中的每个配置数据:

table-1.png

2.2 全局级别配置 ( Global Level Configuration )

下表定义了全局配置数据，并且所有微服务都必须加载并使用此规则。

table-2.png

2.3 服务水平配置 (Service Level Configuration)

下表定义了每个微服务应遵循的一些特殊配置。

table-3.png

3. 注册表 ( Registry )

Registry的目标是使微服务能够相互查找和通信。当每个微服务启动时，它会将自己注册到注册表，并且注册表会定期继续检查其可用性。当一个微服务需要连接到另一个微服务时，它连接到Registry以检索目标微服务的可用主机名和端口号，然后调用目标微服务。下图显示了基本流程。

3.png

物理上，“注册表”和“配置”管理服务在同一个Consul服务器节点上组合并运行。

参考资料：
Core Services Layer - Configuration and Registry

------ 本文结束感谢您的阅读 ------