前言

从Eureka到Nacos，微服务注册中心的一次认知升级

不知道你有没有发现这样一种趋势：最近用的人Eureka越来越少了，而用Nacos的人越来越多了。

而且很多之前用Apollo的人，最近也默默转向Nacos了。

今天这篇文章，我就把Nacos为什么越来越多人用的原因，从底层原理到实战用法，从头到尾给你拆解一遍。

希望对你会有所帮助。

一、注册和配置中心为什么“合体”？

在聊Nacos之前，我们先理解一个根本问题——为什么注册中心和配置中心应该是一体的？

微服务架构里有两个核心的“中心”：

• 注册中心：服务启动时告诉它“我在这里”，服务调用时问它“谁在那里”

• 配置中心：存着所有服务的配置参数，改了配置不用重启服务

在Nacos出现之前，这两个“中心”通常是分开的。

Eureka只管注册、Apollo只管配置，你得维护两套系统、两套控制台、两套权限体系。

问题在哪里？

想象一下这个场景：服务A调用服务B突然超时了。

你要排查原因——可能是服务B挂了（注册中心的问题），也可能是超时配置被改了（配置中心的问题）。

你需要在两个系统之间来回切换，翻两套日志，看两套监控。

更麻烦的是，Eureka 2.x已经停止维护，1.x版本发展缓慢。

你今天选Eureka，明天可能就得考虑迁移方案。

而Consul的配置能力相对较弱，ZooKeeper的配置基本得自己搞watch。

Nacos的核心价值，就是把这两件事做成了一件事。

Nacos = 服务注册与发现 + 动态配置管理 + 服务管理。

你只需要维护一套系统，注册中心和配置中心天然打通，服务发现和配置推送共享同一套基础设施。

二、一张图看懂Nacos的整体架构

在深入代码之前，我们先建立一个整体认知。

Nacos的架构设计充分考虑了高可用、高并发和可扩展性。

核心模块包括服务发现模块（NameService）、配置管理模块（ConfigService）和AI Registry模块，一致性协议层使用自研的Distro协议和Raft协议保证数据一致性。

但Nacos最精妙的设计，在于它内部其实干的是两件性质完全不同的活。

三、AP和CP双模：Nacos最核心的设计哲学

有些小伙伴可能会问：“Nacos到底是AP还是CP？”

答案是：它既是AP，也是CP。按场景选。

Nacos支持两种一致性模式：

• AP模式：基于Distro协议（最终一致性），优先保证可用性——用于服务发现

• CP模式：基于Raft协议（强一致性）——用于配置管理

3.1 为什么服务发现用AP？

服务发现的核心场景是：服务实例频繁上下线。

如果每次上线都要走Raft那种“多数派确认”，集群压力会非常大。

更重要的是，服务发现的容错点很特殊：

• 多一个实例：最多多一次失败重试，业务体感几乎没影响

• 少一个实例：最多少处理一段时间流量，影响有限

短时间不一致，对业务体感几乎没影响。所以服务发现没必要用强一致，AP就够了。

3.2 为什么配置管理用CP？

配置管理就不一样了。

想象一个场景：你在控制台里把一个核心限流值从1000改到100。

如果Nacos集群在这一刻不一致，部分节点收到了新值，部分节点还是老值——客户端从不同节点拉到的配置不一样，业务行为开始飘。

这种情况比“多一个老实例”严重得多。所以配置中心必须CP，写入要在多数派确认成功之后才算成功。

Nacos配置中心走的是JRaft（Raft协议的工程化实现），几个工程细节必须注意：

• 必须≥3节点：Raft要选举，2节点没法选

• 写都走Leader：Follower收到写请求会转发或拒绝

• Leader挂了会重新选：选举期间短暂不可写，是正常的

• 配置存到MySQL：Raft是协调一致性，不是存储

3.3 AP与CP模式下的数据流对比

四、Distro协议深度

Distro是Nacos自研的一致性协议，专门为服务发现场景设计。

4.1 责任分片：每个节点管一摊

Distro的核心设计思路是责任分片。每个Nacos节点只负责一部分服务实例的“权威数据”。

4.2 读写分离：读本地、写异步

Distro协议的核心机制：

• 写操作：客户端注册到任意节点，节点先本地写再异步广播给其他节点

• 读操作：客户端从任意节点读取，读到的是该节点当前的本地数据

• 最终一致：一段时间内集群内同一服务实例视图会收敛

• 节点故障可恢复：某节点挂了，它负责的实例数据由其他节点接管，重启后可重新拉取

这个设计的精妙之处在于：它承认了“服务发现是AP场景”这件事，没有为了强一致硬上Raft。

4.3 健康检查机制

Nacos的健康检查非常灵活：

健康检查类型	适用场景	工作机制
客户端主动心跳	大多数场景	服务实例定期发送心跳，超时标记不健康
服务端主动探测	特殊场景	服务端主动探测实例端口是否可达
TCP/HTTP检测	定制化需求	通过TCP连接或HTTP请求检测服务可用性
自定义检测	特殊业务场景	支持用户自定义健康检查逻辑

4.4 CopyOnWrite：读写并发冲突的优雅解法

Nacos为防止读写并发冲突，在服务注册表的更新中大量运用了CopyOnWrite思想——把原内存结构复制一份，操作完再替换回真正的注册表。

为什么不用锁？

因为服务发现是典型的“读多写少”场景。读操作频繁（每次服务调用都要查），写操作相对较少（实例上下线）。

CopyOnWrite让读操作完全无锁，写操作复制一份再替换，读操作永远看到一致的数据。

五、配置推送

很多人以为Nacos推配置走的是WebSocket。

不是。

它用的是长轮询（Long Polling） 。

5.1 长轮询的工作流程

5.2 为什么用长轮询而不是WebSocket？

• 简单：HTTP协议，所有SDK都好实现，运维和网关压力小

• 兼容性好：不需要支持WebSocket的代理

• 可靠：HTTP请求天然支持超时和重试

• 防火墙友好：WebSocket在某些网络环境下可能被拦截

5.3 配置数据的变更通知机制

六、Nacos 2.0：性能提升10倍的秘密

如果你还在用Nacos 1.x，这篇文章有一个非常重要的信息要告诉你：Nacos 2.0性能提升了10倍。

6.1 1.x时代的“三座大山”

6.2 2.0的四张王牌

效果有多明显？ 有团队把Nacos从1.4升级到2.1后，服务发现的延迟从800ms直接降到20ms，降了**96%**。

如果你还在跑Nacos 1.x，升级的理由已经够了——延迟降96%，连接数降8倍，不需要改任何业务代码。

七、Nacos 3.0：从微服务到AI Agent

有些小伙伴可能会问：“Nacos不是做微服务的吗？跟AI有什么关系？”

2026年，Nacos发生了一次定位级别的巨变。

官方定义从“更易于构建云原生应用的动态服务发现、配置管理和服务管理平台”变成了 “一个易于构建AI Agent应用的动态服务发现、配置管理和AI智能体管理平台” 。

7.1 为什么Agent需要Nacos？

微服务时代，Nacos解决的是“服务A怎么找到服务B”。AI Agent时代，Agent需要调用各种工具——查天气、查订单、发邮件、操作数据库。

问题来了：Agent怎么知道有哪些工具可以用？怎么知道每个工具的调用方式？怎么动态发现新上线的工具？

用人话说：微服务时代，Nacos是人与服务之间的“电话簿”。AI Agent时代，Nacos要变成Agent与工具之间的“电话簿” 。

7.2 AI Registry：三层架构

Nacos 3.0引入了全新的AI Registry模块，和传统的服务注册、配置管理并列，成为Nacos的三大核心能力之一。

AI Registry的架构分为三层：

模型层：管理AI模型的动态参数——Prompt模板、学习率、连接配置等。这一层复用了Nacos配置管理的分发能力。典型场景：线上Prompt模板热更新、多模型切换、A/B测试不同Prompt版本。

工具层：这是AI Registry最核心的一层——MCP Registry。它解决的问题是：让LLM模型和MCP工具之间实现自动发现、自动注册、智能检索。关键能力是通过智能过滤，减少传递给大模型的工具描述数量，从而降低Token消耗。

智能体层：管理AI Agent的生命周期和元数据。

八、Nacos vs 主流注册中心对比

我把几个主流注册中心放在一起做了个深度对比：

对比维度	Nacos	Eureka	Consul	ZooKeeper
一致性协议	AP+CP双模	AP	CP	CP
配置中心	✅ 原生支持	❌ 需额外组件	⚠️ 较弱	⚠️ 需自己搞watch
控制台	✅ 功能丰富	❌ 简单	✅ 有	❌ 无
健康检查	心跳+多种方式	仅心跳	HTTP/TCP/gRPC	心跳
Spring Cloud集成	✅ 深度集成	✅ 原生	✅ 支持	⚠️ 需适配
多数据中心	⚠️ 有限	❌ 不支持	✅ 原生支持	❌ 不支持
服务管理	✅ 完善	❌ 无	✅ 有	❌ 无
AI原生支持	✅ 3.0 AI Registry	❌	❌	❌

Eureka 2.x已经停止维护，1.x版本发展缓慢。Consul的配置能力相对较弱。ZooKeeper的配置基本得自己搞watch。

Nacos最大的优势不是“某一个功能特别强”，而是“该有的都有，而且都做到了及格线以上”。

九、实战：3步跑通Nacos

光说理论不够，我们来看怎么快速上手。

9.1 第一步：启动Nacos Server

从GitHub下载最新版本：

# 下载后解压
unzip nacos-server-2.3.2.zip
cd nacos/bin

# 单机模式启动（开发/测试环境）
sh startup.sh -m standalone

控制台默认地址：http://127.0.0.1:8848/nacos。默认账号是nacos/nacos，首次登录强制改密码。

9.2 第二步：Spring Boot服务接入

在pom.xml中添加依赖：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>

在application.yml中配置：

spring:
  application:
    name: user-service
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
      config:
        server-addr: 127.0.0.1:8848
        file-extension: yaml

加上@EnableDiscoveryClient注解，服务启动后自动注册到Nacos。

9.3 第三步：动态配置刷新

@RestController
@RefreshScope  // 配置变更自动刷新
public class ConfigController {
    
    @Value("${app.timeout:30}")
    private int timeout;
    
    @GetMapping("/timeout")
    public int getTimeout() {
        return timeout;
    }
}

在Nacos控制台修改app.timeout的值，不需要重启服务，配置自动生效。

十、优缺点

优点

1. 注册中心+配置中心一体化Nacos把两件事做成了一件事，少养一套系统。Eureka只做注册，Consul配置弱，ZooKeeper配置基本得自己搞watch。

2. AP/CP双模切换服务发现走Distro（AP），配置管理走Raft（CP）。你不用为了“配置写错全公司挂掉”再单独搭个强一致的存储。

3. 性能强悍Nacos 2.0将通信从HTTP升级到gRPC，性能提升10倍。服务发现延迟从800ms降到20ms。

4. Spring Cloud Alibaba深度集成国内大多数团队用的是Spring Cloud Alibaba而不是Spring Cloud Netflix。Nacos是这套生态里的默认注册和配置中心，集成几乎零摩擦。

5. 生态成熟控制台、命名空间、灰度、推送、监听、SDK多语言，都已经磨过几年。线上踩过的坑，社区基本都讨论过。

6. AI时代持续进化Nacos 3.0引入了AI Registry模块，支持MCP工具的自动发现和注册。

7. 开源协议友好Apache 2.0协议，可自由使用、修改、商用。

缺点

1. 多语言SDK支持不均衡Java最完整，Go和Node还在追。如果团队使用多种语言，需要评估各语言SDK的成熟度。

2. 文档更新跟不上版本3.0引入AI Registry/MCP管理后，能力扩展了，文档跟得有点吃力。

3. 大规模集群部署较复杂3节点+MySQL手动部署步骤繁琐，容器化部署更推荐。

4. gRPC端口需要额外放行Nacos 2.x引入了gRPC通信端口（主端口+1000），防火墙必须放行，否则集群间通信失败。

十一、适用场景

场景	推荐程度	理由
Spring Cloud Alibaba项目	✅✅✅ 强烈推荐	零摩擦集成，生态默认选择
需要注册+配置一体化	✅✅✅ 强烈推荐	少维护一套系统，降低运维成本
微服务规模中等偏大	✅✅✅ 强烈推荐	性能强悍，支撑大规模服务注册
需要AP/CP灵活切换	✅✅✅ 强烈推荐	服务发现用AP，配置管理用CP
Kubernetes云原生环境	✅✅ 推荐	提供良好的Kubernetes支持
AI Agent/MCP工具管理	✅✅ 推荐	Nacos 3.0原生支持AI Registry
纯Dubbo项目	✅✅ 推荐	可替代ZooKeeper作为注册中心
多语言混合团队	⚠️ 需评估	Go/Node SDK成熟度不如Java

十二、写在最后

回到最初的问题：为什么越来越多人用Nacos？

答案其实很简单——因为它把注册中心和配置中心这两件微服务架构中最核心的事情，做成了“一件事”。

Eureka只做注册，Consul配置弱，ZooKeeper配置要自己搞watch。

每一个都有短板，每一个都让你不得不多维护一套系统。

Nacos走了一条“第三条路” ——注册中心和配置中心天然一体化，AP和CP按场景切换，1.x到2.x性能提升10倍，3.0又拥抱了AI时代。它不是“某一个功能特别强”，而是 “该有的都有，而且都做到了及格线以上” 。

从Eureka到Nacos，不是“谁取代谁”，而是在合适的场景选择更合适的工具。

开源地址