注册中心 & 配置中心

技术架构

平台提供的注册中心和配置中心均基于 Nacos 实现。对比使用 ZooKeeper 做注册中心、Apollo 做配置中心，该方案在中间件运维简易度和资源利用率上有着巨大的优势。平台 BaaS 化 Nacos 的能力，从而实现多个项目的不同环境共用一套 Nacos，进一步提高资源利用率，同时业务开发过程中也无需关注底层租户隔离机制。

如下图所示，两个不同项目的环境，可在一个物理集群内共用一套 Nacos。

对于平台侧创建 Nacos 租户的流程，业务是无需感知的。业务应用的 dice.yml 通过 Addon 扩展机制申明注册中心或配置中心，随后部署应用，自动创建租户，同时将租户 ID 以环境变量的方式自动注入应用服务的容器中。

注册中心的功能主要包括 Dubbo 微服务框架注册发现和 Spring Cloud 微服务框架注册发现，配置中心的功能主要为 Spring Cloud 配置热更新机制。

核心概念

租户

在 Nacos 中，不同 Namespace 之间的服务注册发现和配置管理是相互隔离的。

如下所示，选择对应的 Namespace，即可查看该租户下具体的服务注册列表。

在 Erda 的注册中心和配置中心，租户将自动关联所属的项目环境，因此用户无需选择指定的 Nacos Namespace 即可查看项目环境下的服务注册列表等信息。

进入 微服务治理平台 > 环境设置 > 组件信息，可查看 Nacos NamespaceId 对应的服务参数（即自动注入的环境变量）。

注册中心对应的服务参数为 NACOS_TENANT_ID。

配置中心对应的服务参数为 CONFIGCENTER_TENANT_NAME。

注册中心

Dubbo 协议

Dubbo 框架的微服务注册发现机制。接口名称由对应的 Dubbo Service 和版本号构成。

供应者列表中的 IP 为提供该 Dubbo Service 的 Provider 实例的 K8s Pod IP，在 Nacos 中服务名以 providers:开头。

消费者列表中的 IP 为订阅消费该 Dubbo Service 的 Consumer 实例的 K8s Pod IP，在 Nacos 中服务名以 consumers: 开头。

HTTP 协议

Spring Cloud 框架的微服务注册发现机制。由于 Spring Cloud 框架的消费者无法注册自身信息，因此仅能查看供应者的名称和 IP 信息。

配置中心

配置中心的 Key/Value 配置项可合并形成一份 application.yml，动态下发配置。

对应至 Nacos，每个应用配置即为一个独立的 Data 配置项。

例如 parana-trade 应用的 Key/Value 配置可合并为 Data 如下：

可点击查看详情。