Nacos：云原生时代的服务与配置基石

章节一：Nacos 概况

一、前言

Nacos（Dynamic Naming and Configuration Service）是阿里巴巴开源的一款集服务发现、配置管理和服务管理于一体的平台 。它旨在帮助开发者更敏捷地构建、交付和管理云原生及微服务应用，是构建现代分布式架构的核心基础设施。

Nacos 的核心价值在于"一站式"解决微服务架构中的两大核心痛点：服务如何相互发现，以及配置如何集中、动态地管理。它无缝集成了服务注册中心与配置中心，相比传统的 Eureka + Spring Cloud Config 组合，在实时性、可用性和易用性上都有显著提升。

二、核心架构与工作原理

Nacos 的架构设计清晰分层，从客户端到存储层，各司其职。其服务注册发现的底层，巧妙地采用了双协议设计，以适应不同的一致性需求。

双协议引擎：AP与CP的智慧选择

Nacos 允许用户根据业务场景，在服务的 可用性（AP） 和 一致性（CP） 之间做出灵活选择。

Distro 协议 (AP模式)

这是 Nacos 的默认模式，优先保证服务的高可用性。它采用去中心化的 Gossip 协议进行数据同步，在网络分区发生时，各节点仍能独立提供服务，但不同节点间的数据可能存在短暂不一致。适用于对服务发现实时性要求极高，且能容忍短暂数据不一致的场景，如大多数电商核心交易链路。

Raft 协议 (CP模式)

当用户通过控制台或API将服务切换到 CP 模式时，Nacos 会使用 Raft 共识算法来保证数据的强一致性。在此模式下，集群会选举出一个 Leader 节点处理所有写请求，并同步给 Follower 节点，确保所有节点数据一致。这牺牲了一定的可用性（Leader 宕机时会有短暂的选举期），但保证了配置信息的绝对准确，适用于分布式锁、主备选举等场景。

在配置管理方面，Nacos 实现了高效的"推拉结合"机制。客户端会定时拉取配置，同时与服务端保持一个长连接。当配置发生变更时，服务端会通过这个长连接主动将变更推送给客户端，实现了配置的近实时动态刷新，无需重启应用。

三、关键概念与数据模型

要深入使用 Nacos，必须理解其核心数据模型。这些概念构成了 Nacos 管理和隔离服务与配置的基石。

🗂️ Nacos 的核心数据维度

（1）命名空间 (Namespace)

用于实现租户级或环境级的配置隔离。最常见的用法是区分开发、测试、生产等不同环境，确保各环境的配置互不干扰。

（2）分组 (Group)

在同一个命名空间内，对配置集进行进一步分组。默认分组为 DEFAULT_GROUP。例如，可以为"交易系统"和"用户系统"分别创建不同的 Group，即使它们有相同 Data ID 的数据库配置。

（3）数据 ID (Data ID)

一个配置集（通常对应一个配置文件）的唯一标识符。建议采用类似 Java 包名的命名规则（如 com.example.app.db-config）来保证全局唯一性。

一个完整的配置定位通常由 Namespace + Group + Data ID 三者共同决定。

在服务模型中，服务（Service） 是一等公民，一个服务下包含多个提供相同功能的实例（Instance）。Nacos 通过持续的健康检查来监控实例状态，自动将不健康的实例从服务列表中剔除，保障流量只会被路由到健康的节点。

四、Nacos 3.0：迈向AI原生的演进

Nacos 3.0 标志着其从"微服务基础设施"向"AI原生应用平台"的跨越。其核心愿景是成为全面拥抱AI时代的服务、配置与AI注册中心。

这一演进主要体现在三大新能力上：

• AI Registry（AI注册中心）：这是 Nacos 3.0 最核心的规划。它分为模型层、工具层和应用层，旨在管理AI模型的动态参数（如Prompt、学习率），并帮助AI智能体自动发现和调用外部的MCP工具，减少Token消耗，提升协作效率。
• MCP服务管理：Nacos 可以作为 MCP（Model Context Protocol）服务的注册中心，支持将存量HTTP/RPC服务零代码改造成MCP服务，也支持新MCP服务的自动注册与发现。
• 零信任安全架构：针对Nacos 2.0 API暴露的安全风险，3.0版本通过独立部署控制台、拆分鉴权开关、分类API并默认开启鉴权，以及与KMS等云产品合作实现运行时数据库凭据的动态轮转，构建了更坚固的安全防线。

4.1、MCP Registry

Nacos 3.0 最主要的能力就是作为MCP Registry，支持了MCP服务的注册，管理，和发现的能力。

Nacos MCP Registry支持三类MCP 服务的注册方式，

第一类：

是将存量HTTP或RPC的服务，通过声明自动转化为MCP服务，配合Higress的协议转换能力， 实现0代码改造成MCP服务协议，如何将存量API转化为MCP服务，详情可参见存量API转换MCP手册。

第二类：

就是新构建的MCP服务注册， 配合Spring AI等AI Agent应用框架和Nacos-MCP的sdk，能够做到像微服务一样自动注册到Nacos中进行统一的管理和维护，如何通过Spring AI或Nacos-MCP的sdk进行MCP服务的自动注册与发现，请参见MCP Server自动注册手册。

第三类：

就是已经构建好的或其他供应商提供的MCP服务，可以导入到Nacos中，进行其描述、工具列表、工具Schema等内容的动态修改和维护，让调试MCP服务变得更加简单。

4.2、Nacos MCP Router

Nacos MCP Router是一个基于MCP官方SDK开发的标准MCP Server，为MCP Client提供MCP Server的智能搜索、安装、代理等功能， 极大地简化了MCP服务的使用流程。 同时，Nacos MCP Router跟Nacos MCP Registry结合，可以实现MCP Server治理，如MCP Server及工具可见性、版本管理等。

五、部署模式

Nacos 提供了两种部署运行模式：单机模式和集群模式

5.1、单机模式

单机模式又称单例模式, 拥有所有Nacos的功能及特性，具有极易部署、快速启动等优点。但无法与其他节点组成集群，无法在节点或网络故障时提供高可用能力。单机模式同样可以使用内置Derby数据库（默认）和外置数据库进行存储。

单机模式主要适合于工程师于本地搭建或于测试环境中搭建Nacos环境，主要用于开发调试及测试使用；也能够兼顾部分对稳定性和可用性要求不高的业务场景。

5.2、集群模式

集群模式通过自研一致性协议Distro以及Raft协议，将多个Nacos节点构建成了高可用的Nacos集群。数据将在集群中各个节点进行同步，保证数据的一致性。集群模式具有高可用、高扩展、高并发等优点，确保在故障发生时不影响业务的运行。集群模式默认采用外置数据库进行存储，但也可以通过内置数据库进行存储。

该模式主要适合于生产环境，也是社区最为推荐的部署模式。

六、生态组件

七、路线规划

八、生态与最佳实践

Nacos 拥有强大的生态集成能力，与主流微服务框架无缝对接。在 Spring Cloud 体系中，通过引入 spring-cloud-starter-alibaba-nacos-discovery 和 spring-cloud-starter-alibaba-nacos-config 依赖，即可快速集成服务发现与配置管理功能。

集成框架	主要作用	关键优势
Spring Cloud / Spring Boot	作为默认的服务注册与配置中心	开箱即用，注解驱动，与Spring生态深度绑定
Dubbo	替代Zookeeper作为RPC服务的注册中心	提供更丰富的元数据管理和健康检查机制
Kubernetes	与K8s Service互通，统一管理容器内外服务	打通虚拟机与容器化部署的服务网络

一个典型的 Spring Boot 项目集成 Nacos 配置中心的步骤包括：在 bootstrap.properties 中配置 Nacos 服务器地址、命名空间等；在 Nacos 控制台创建对应的配置文件（Data ID）；最后在代码中使用 @Value 或 @ConfigurationProperties 注解注入配置值，并享受配置动态更新的能力。

九、总结与展望

Nacos 通过将服务发现、配置管理、服务元数据管理等核心能力融为一体，极大地简化了微服务架构的复杂度。其双协议设计、推拉结合的配置更新机制，以及面向云原生的架构，使其在生产环境中表现出极高的可靠性和灵活性。

而 Nacos 3.0 向 AI 原生的演进，更是展现了其作为基础设施平台的远见。它不再仅仅服务于传统的微服务，开始为AI智能体、大模型应用提供"服务发现"和"配置管理"能力，试图成为连接传统IT与AI应用的新一代枢纽。对于开发者而言，理解 Nacos 不仅是掌握了一个工具，更是把握了云原生向AI原生演进的技术脉搏。

十、写在最后的话

"Nacos 相信一切都是服务，每个服务节点被构想为一个星球，每个服务都是一个星系；Nacos 致力于帮助这些服务建立连接赋予智能，助力每个有面向星辰的梦想能够透过云层，飞在云上，更好的链接整片星空。"

章节二：Nacos AP/CP模式切换指南

一、前言

在微服务架构中，服务注册与发现的一致性模型选择直接影响系统的可用性和数据可靠性。Nacos作为阿里巴巴开源的服务发现和配置管理平台，提供了AP（可用性优先）和CP（一致性优先）两种集群模式，开发者可以根据业务场景灵活切换。

默认情况下，Nacos集群运行在AP模式，确保高可用性；当需要强一致性保证时，可以切换到CP模式。

二、两种切换方式

Nacos提供了两种主要的模式切换方法：通过HTTP API动态切换和通过配置文件静态设置。动态切换无需重启服务，但需要确保所有集群节点同步操作；配置文件设置则需要在启动前配置，重启后生效。

1、HTTP API动态切换

这是最常用的切换方式，通过向Nacos Server发送HTTP PUT请求即可完成模式切换。切换后需要重启Nacos服务使配置生效。

切换到CP模式

curl -X PUT 'http://<nacos-server-ip>:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP'

切换回AP模式

curl -X PUT 'http://<nacos-server-ip>:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=AP'

⚠️ 重要注意事项：

• 集群环境下所有节点都需要执行相同的切换命令，否则会导致数据不一致

• 必须使用PUT请求，GET和POST请求均无效

• 生产环境建议通过控制台操作，避免直接调用API带来的风险

2、配置文件静态设置

在Nacos Server的配置文件中预先设置默认模式，这种方式需要在服务启动前配置，重启后生效。

# application.properties配置示例

# 配置中心默认使用CP模式

nacos.naming.data.consistency=CP

# 服务发现默认使用AP模式

spring.cloud.nacos.discovery.consistency=AP

三、模式选择与实例配置

不同的模式对应不同的实例类型。AP模式只支持临时实例（ephemeral=true），而CP模式支持永久实例（ephemeral=false）。在切换模式时，需要同步调整客户端实例的配置。

🔄 客户端实例配置

AP模式配置

# bootstrap.properties
spring.cloud.nacos.discovery.ephemeral=true

临时实例，客户端主动发送心跳维持注册状态，适合动态变化频繁的服务实例。
CP模式配置

# bootstrap.properties
spring.cloud.nacos.discovery.ephemeral=false

永久实例，服务端主动探测实例健康状态，适合需要强一致性的配置信息。
💡混合模式支持

Nacos支持在同一集群中混合使用AP和CP模式。可以通过服务元数据配置，让部分服务使用临时实例（AP），部分服务使用永久实例（CP），实现灵活的业务适配。

四、核心差异对比

AP和CP模式在一致性、可用性、性能等方面存在显著差异，了解这些差异有助于做出正确的模式选择决策。

对比维度	AP模式	CP模式
一致性保证	最终一致性（5-30秒）	强一致性（毫秒级）
可用性	分区期间仍可用	分区期间不可用
协议基础	Distro协议（去中心化）	Raft协议（强一致性）
数据存储	内存存储（临时实例）	磁盘+内存（持久实例）
健康检查	客户端心跳（15秒超时）	服务端主动探测
注册延迟	<10ms	100-500ms
查询延迟	<1ms	约10ms
吞吐量	10,000+ TPS（单节点）	约2,000 TPS（受Raft限制）

五、适用场景建议

根据业务特性和一致性要求，合理选择AP或CP模式可以最大化系统效能。大多数微服务场景建议使用默认的AP模式，仅在特定场景下切换到CP模式。

✓选择AP模式当

• 服务实例动态变化频繁：如电商秒杀、促销活动等场景

• 允许短暂数据不一致：如缓存更新、推荐系统等容忍延迟的场景

• 需要容忍网络分区：跨机房、跨地域部署的微服务架构

• 高并发注册发现：需要快速注册和下线的服务治理场景

✓选择CP模式当

• 配置信息需要严格同步：如灰度发布开关、功能开关等

• 服务地址变更需立即生效：如数据库主从切换、服务熔断配置

• 金融级数据一致性要求：支付状态、交易流水等关键业务数据

• 基础设施注册：Redis集群地址、数据库连接池等需要强一致性的配置

六、故障恢复与监控

不同模式下的故障恢复机制和监控指标各有侧重。了解这些差异有助于在出现问题时快速定位和恢复。

🔄 Leader节点宕机场景对比

AP模式恢复

• 客户端自动重试其他节点
• 新Leader在3秒内选举完成
• 服务注册不受影响（仅元数据短暂不可查）

CP模式恢复

• 新注册请求被阻塞（持续3-10秒）
• 客户端SDK自动重试（默认5次）
• 数据恢复后继续处理

关键监控指标

AP模式关注

• naming_sync_success_rate（数据同步成功率）

• 客户端心跳成功率

• 注册/发现延迟

CP模式关注

• raft_leader_election_count（Leader选举次数）

• 数据同步延迟

• 读写请求成功率

七、写在最后的话

在分布式系统的世界里，没有完美的选择，只有最适合的权衡。Nacos的AP/CP双模式设计，本质上是CAP定理在工程实践中的智慧体现------它不强迫你在一致性和可用性之间二选一，而是让你根据业务场景自由调配。

就像优秀的厨师懂得根据食材调整火候，优秀的架构师也懂得根据业务特性选择合适的一致性模型。记住：默认AP，按需CP------这八个字能帮你避开大多数坑。