6.2　Nacos的核心功能

Nacos不仅是注册中心，而且是配置中心管理配置项。根据官方文档的描述，目前最稳定的功能是服务发现和配置管理，其架构如图6-1所示。

图6-1　Nacos架构图

6.2.1　服务注册、服务发现与健康检测

在任何分布式体系结构中，都需要提供一种查找计算机物理地址的能力，此概念从分布式计算开始时就被提出，我们称之为“服务发现”。

服务发现对微服务和基于云的应用程序至关重要。首先，服务发现可以让微服务拥有快速横向扩展的能力（即增减服务实例数）。通过服务发现，服务使用者不再需要知道服务的具体物理地址，因此开发者可以从可用服务池中添加或删除新的服务实例，从而实现服务的扩展和缩减，而且这种服务实例的变化对服务使用者而言是无感知的。其次，服务发现有助于提高应用程序的弹性，当某些微服务实例变得不正常或不可用时，可以将其从内部可用服务列表中删除，以保证服务发现不会将消费请求路由到不可用实例。

与Eureka类似，Nacos的服务注册和服务发现在服务提供者（Service Provider）启动的时候发起，将服务自身的信息注册到服务注册中心，在注册成功以后，还需要使用心跳机制将服务提供者的健康状况告知注册中心。而服务消费者（Service Consumer）通过服务名称从服务注册中心获得服务提供者的地址和端口号，从而使用该服务。Nacos服务注册与服务发现的流程如图6-2所示。

图6-2　Nacos服务注册与服务发现的流程

6.2.2　配置管理

在大规模的微服务系统中，将代码与配置信息分离是一种常见的设计，要实现这些需求，配置管理系统需要实现以下功能：

（1）当微服务实例启动时，可以调用配置服务来读取配置信息，而配置管理的连接信息（通信凭据、服务地址等）将在服务启动时被加载。

（2）配置项将被保存在存储库中，我们可以选择不同的存储方案来保存配置数据，如GitHub、关系型数据库或key-value存储。

（3）配置数据的管理与微服务的部署是相互独立的，配置更改可以通过版本信息进行标记，还可以在不同环境进行部署。

（4）在配置项被更改时，必须通知使用该配置项的服务更改并刷新其数据副本。

Nacos的配置管理功能正是基于以上原则构建的，Nacos支持环境隔离，也支持配置项的热更新、配置信息的监听等功能。此外，Nacos还提供了一个简单易用的管理界面，用于管理所有的服务和配置。

为了区分不同环境的不同配置项，Nacos定义了Name Space、DataID和Group来定位某一具体配置项。Name Space表示配置项所属的环境，Group则是一组配置项的集合，如果在发布某项配置时未指定Group，则默认使用DEFAULT_GROUP作为分组名，DataID可以理解为一个配置文件，所有的配置项都归属在DataID下，Name Space和Group的关系如图6-3所示。

图6-3　Name Space和Group的关系