系列：Nacos 三篇实践笔记
下一篇：[02｜Nacos 内核拆一拆：Distro、Raft、长轮询到底在干啥]
这一篇先把"为啥用、怎么接"讲清楚，下一篇拆原理，再下一篇讲生产怎么落。
一、起因：又一次被注册中心折腾过
我承认，之前我对 Nacos 一度有点冷淡。
前几年公司做微服务那会儿，注册中心选过 Eureka、ZooKeeper、Consul，每一个都不算特别糟。后来项目一多，问题就出来了：
- Eureka：心跳不及时，假死实例剔不掉。
- ZooKeeper：Leader 选举一抽风，半个集群拿不到服务列表。
- Consul：跨机房延迟一上来就开始抖。
- 配置中心还得另搭，跟注册中心两套体系，运维很累。
最近又接手一个新业务，重新选型，转了一圈最后还是把 Nacos 选回来了。不是因为它最炫，而是因为它把"注册中心 + 配置中心"做成了一件事，少养一套系统。
这一篇我就当作上手实践笔记来写：先把动机和最小接入聊清楚。
二、Nacos 到底是什么
官网那句话很标准：
Nacos 提供动态服务发现、配置和管理。
但单看这句没感觉。我自己理解成三件事：
- 服务注册中心：让微服务知道彼此在哪。
- 配置中心：让配置不再写死在 jar 里。
- 服务管理 / AI Registry：3.0 之后还在管 MCP 服务、Prompt 这类 AI 资产。
这三件事可以拆开用，也可以一起用。大多数团队会把前两件先吃下来。
三、为啥它在国内那么主流
我自己总结过几个原因，不是一句"阿里背书"那么简单。
1. 注册中心 + 配置中心一体
Eureka 只做注册，Consul 配置弱，ZooKeeper 配置基本得自己搞 watch。Nacos 直接两手都抓。
2. 同时支持 AP 和 CP
服务发现走 Distro（AP），配置中心走 Raft（CP）。
听着有点炫，实际意义很现实：你不用为了一个"配置写错全公司挂掉"再单独搭个强一致的存储。
3. Spring Cloud Alibaba 加持
国内大多数团队用的是 Spring Cloud Alibaba 而不是 Spring Cloud Netflix。Nacos 是 Alibaba 这套生态里的默认注册和配置中心，集成几乎零摩擦。
4. 生态成熟
控制台、命名空间、灰度、推送、监听、SDK 多语言，都已经磨过几年。线上踩过的坑，社区基本都讨论过。
四、最小接入：三个动作就能跑通
这一节我按"如果让我重新接一次"的思路写。命令和配置都是真实可用的，我只是按现在的版本梳理一遍，不是在你机器上跑。
第一步：起一个 Nacos Server
简单测试用单机模式：
# 下载 release 后
sh bin/startup.sh -m standalone
控制台默认地址：http://127.0.0.1:8848/nacos。
新版本默认账号是 nacos / nacos，首次登录强制改密码，别图省事不改。
第二步：Spring Boot 服务接入
我习惯把它当 Spring Cloud Alibaba 一员来用。pom 里大概是这样：
<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: order-service
cloud:
nacos:
discovery:
server-addr: 127.0.0.1:8848
namespace: dev
config:
server-addr: 127.0.0.1:8848
namespace: dev
file-extension: yaml
服务起来之后，控制台 → 服务列表里就能看到 order-service 出现，实例数 1。
第三步：把配置搬上去
在 Nacos 控制台新建 Data ID order-service.yaml，写点东西：
order:
default-page-size: 20
enable-cache: true
代码里通过 @Value 或 @ConfigurationProperties 注入。改一下控制台，几秒内服务收到推送，不用重启。
第一次看到这个效果的人多少都会"哟"一下。
五、注册中心选型：我现在的判断
我不会无脑推荐 Nacos，但我会按场景给建议。
| 场景 | 我的选择 |
|---|---|
| Java 微服务，国内团队，跟 Spring Cloud Alibaba 走 | Nacos |
| 多语言异构，强一致需求高 | Consul / etcd |
| 已有 Kubernetes 体系，服务发现走 Service | K8s Service + ConfigMap，必要时再加 Nacos |
| 历史项目重度依赖 Eureka，没动力迁 | 留着别动 |
| 重度依赖 ZooKeeper 做协调，不仅仅是注册 | 保留 ZooKeeper 做协调，注册和配置另外用 Nacos |
最后一行很关键。我见过一些团队抱着 ZooKeeper 当注册中心使，其实它本来是用来做协调（leader 选举、分布式锁）的。注册中心可以换 Nacos，协调还是它干，俩并存反而更舒服。
六、几个一开始我没注意到的细节
接 Nacos 这几年，有一些小经验值得提前讲：
1. 默认是临时实例（ephemeral=true）
Nacos 服务实例默认临时，靠心跳保活。心跳一断就剔除。
这个机制平时没事，但服务假死（线程卡死但心跳还在跑）的时候挺坑——实例不会被剔除，流量继续打过去。后面那篇里我会专门讲这块，先在心里有个印象。
2. 命名空间不是只有 public
很多人一上手只用 default 的 public namespace，结果 dev/test/prod 配置全混一起。
第一次接进项目时就把 namespace 切好，名字别太花，写 dev / test / prod 就行。
3. group 和 dataId 别乱填
dataId 默认会按 ${spring.application.name}-${profile}.${file-extension} 拼接。group 默认 DEFAULT_GROUP。
服务多了以后，group 一定要按业务线分，否则配置中心列表会变成一锅粥。
4. 控制台账号别用默认
nacos / nacos 上生产是事故现场预订。新版默认强制改，但内网集群很多人还是图省事。
至少做到：
- 改默认密码
- 控制台不暴露公网
- 内部业务方用专属账号
七、第一次接完之后的感受
我自己最直观的几个感受：
- 少养一个系统：以前 Eureka + Apollo 两套，现在合一套。
- 改配置不重启：这是最爽的体验，没有之一。
- 控制台肉眼可看：实例上线下线、配置版本，控制台都直观显示。
- 生态稳：踩坑搜中文社区基本一搜一大把。
但它也不是没缺点：
- 官方 Docker / 集群部署坑比想象多，下一篇讲。
- 3.0 之后引入了 AI Registry / MCP 管理，能力扩了，文档跟得有点吃力。
- 多语言 SDK 不算很均衡，Java 最完整，Go / Node 还在追。
- 运维不是开箱即用：Nacos 集群本身需要 MySQL，主备、扩缩容都要自己规划。
八、总结评价：它做对了一件最重要的事
写到这里我想说一句：Nacos 不是技术上最革命的项目。它的注册协议、Raft 算法、长轮询机制，都是组合现成思路。
但它做对了一件最重要的事——把工程团队真正每天用的两件事（服务发现 + 配置下发）合成一件事，且做出了一个像样的控制台。
很多基础设施项目败在"理论很美，工程难用"。Nacos 走的是反方向：理论不一定最优雅，但工程上拿来就能用。
这就是为什么我转了一圈，又回到它身上。
下一篇我会把它的内核拆开讲：Distro 和 Raft 是怎么各管一摊的、为什么配置推送可以做到秒级、临时实例假死是怎么发生的。这些懂了之后，遇到生产问题不会再去无头苍蝇式翻日志。
下一篇：[02｜Nacos 内核拆一拆：Distro、Raft、长轮询到底在干啥]
