Nacos（Dynamic Naming and Configuration Service）是阿里巴巴开源的动态服务发现、配置管理和服务治理平台，为微服务架构提供了一站式解决方案。其核心知识点可归纳为以下几个方面：
一、核心定位与功能
Nacos 的核心目标是解决微服务中的两大核心问题：
- 服务发现：帮助服务消费者自动发现服务提供者的网络地址（IP:端口），实现服务间的动态通信。
- 配置管理：实现配置的集中管理、动态更新（无需重启服务），支持多环境、多应用的配置隔离。
- 服务治理：提供服务健康检查、权重调整、元数据管理等能力，保障服务可用性。
二、服务发现核心机制
Nacos 作为注册中心，核心是实现服务的“注册-发现-健康管理”闭环，具体包括：
1. 服务注册
- 服务提供者（Provider）启动时，通过 Nacos Client 将自身信息（IP、端口、服务名、元数据等）注册到 Nacos Server。
- 注册信息包含：服务名（Service Name）、集群名（Cluster Name）、实例（Instance）详情。
2. 服务发现
- 服务消费者（Consumer）启动时，通过 Nacos Client 从 Nacos Server 订阅目标服务，获取服务实例列表。
- 若服务实例发生变化（新增/下线），Nacos Server 会主动推送更新给消费者（基于长连接），避免消费者轮询压力。
3. 健康检查
- 客户端主动上报：服务实例定期向 Nacos Server 发送心跳（默认5秒一次），证明自身存活。
- 服务端主动探测：若心跳超时（默认15秒），Nacos Server 会标记实例为“不健康”；若持续30秒无心跳，则将实例从服务列表中移除。
- 不健康实例不会被消费者发现，保障调用可靠性。
三、配置管理核心机制
Nacos 作为配置中心，核心是实现“配置集中存储-动态推送-多维度隔离”，具体包括：
1. 配置模型：三维度隔离
Nacos 通过命名空间（Namespace）、分组（Group）、数据ID（Data ID） 三级结构管理配置，实现多环境、多应用的配置隔离：
- 命名空间（Namespace）：通常用于隔离环境（如开发、测试、生产），默认命名空间为
public。 - 分组（Group）：用于隔离同一环境下的不同应用或模块（如
user-service-group、order-service-group），默认分组为DEFAULT_GROUP。 - 数据ID（Data ID）：配置文件的唯一标识，格式通常为
{应用名}-{环境}.{配置格式}（如user-service-dev.yaml）。
2. 动态配置推送
- 客户端启动时，通过 Nacos Client 从 Server 拉取指定配置，并注册“配置监听”。
- 当配置在 Nacos Server 被修改后，Server 会通过长连接主动将变更推送给所有监听该配置的客户端，客户端收到后更新本地配置（无需重启服务）。
3. 配置持久化
- Nacos 默认使用嵌入式数据库（Derby） 存储配置和服务信息，但生产环境通常切换为 MySQL（支持主从），确保数据持久化和高可用。
四、数据模型
Nacos 以“服务（Service）”和“配置（Config）”为核心数据实体，关联关系如下：
- 服务（Service）：由多个集群（Cluster）组成，每个集群包含多个实例（Instance）。
- 实例（Instance）：服务的具体节点（如
192.168.1.1:8080），包含 IP、端口、权重、健康状态、元数据等。 - 集群（Cluster）：同一服务在不同地域/机房的分组（如“北京集群”“上海集群”），用于就近调用。
- 实例（Instance）：服务的具体节点（如
- 配置（Config）：由命名空间、分组、数据ID唯一标识，内容为键值对（如
server.port=8080）。
五、AP/CP 模式切换
Nacos 基于 CAP 理论，支持两种一致性模型，可根据业务场景切换：
- AP 模式：优先保证可用性（Availability）和分区容错性（Partition tolerance），弱化一致性（Consistency）。
- 适用场景：服务发现（允许短暂的数据不一致，优先保证服务可用）。
- 原理：采用最终一致性协议，类似 Eureka 的“自我保护机制”，网络分区时仍能提供服务注册/发现。
- CP 模式：优先保证一致性（Consistency）和分区容错性（Partition tolerance），弱化可用性。
- 适用场景：配置管理（要求配置变更在所有节点强一致，避免配置混乱）。
- 原理：基于 Raft 协议实现强一致性，网络分区时会暂停服务注册，确保数据一致。
切换方式：通过 API 指定服务的一致性模式（如 nacos-server/v1/ns/service?serviceName=xxx&ephemeral=false，ephemeral=false 表示 CP 模式）。
六、架构设计
Nacos 架构分为客户端（Nacos Client） 和服务端（Nacos Server）：
1. 客户端（Nacos Client）
- 嵌入在服务应用中，提供服务注册/发现、配置拉取/监听的 API（如 Java 中的
@NacosDiscovery、@NacosValue注解）。
2. 服务端（Nacos Server）
- 核心模块：
- 注册中心模块：处理服务注册、发现、健康检查。
- 配置中心模块：处理配置CRUD、动态推送。
- 控制台模块：Web UI 界面，用于可视化管理服务和配置。
- 集群部署：支持多节点集群，通过 Raft 协议实现数据同步（CP模式）或最终一致性（AP模式），确保高可用。
七、与其他组件的对比
| 功能 | Nacos | Eureka（注册中心） | Spring Cloud Config（配置中心） |
|---|---|---|---|
| 服务发现 | 支持（AP/CP切换） | 支持（AP） | 不支持 |
| 配置管理 | 支持（动态推送） | 不支持 | 支持（需结合Bus实现动态推送） |
| 健康检查 | 客户端+服务端双检 | 客户端心跳 | 不支持 |
| 易用性 | 一站式解决方案 | 仅注册中心 | 需额外集成组件 |
总结
Nacos 作为微服务生态的核心组件，通过“服务发现+配置管理”的一站式能力，简化了微服务的开发和运维。其核心优势在于：动态性（无需重启）、高可用（集群部署）、灵活性（AP/CP切换）、易用性（可视化控制台），因此被广泛用于 Spring Cloud、Dubbo 等微服务架构中。
