系列：Nacos 三篇实践笔记
上一篇：[02｜Nacos 内核拆一拆：Distro、Raft、长轮询到底在干啥]
第一篇：[01｜重新拾起 Nacos：为啥团队最后还是回到了它]
这一篇是收尾：怎么把 Nacos 真正放进生产环境，怎么避开常见的坑，以及 3.0 之后的 AI Registry 到底要做什么。
一、生产部署的最低标配
我现在做生产规划时，Nacos 的底线就这几条：
- 至少 3 节点，跨可用区
- 后端配 MySQL 主备（Nacos 配置中心强依赖它）
- 前面挂 Nginx / SLB 做负载均衡
- 每个环境一套 独立集群或至少独立 namespace
- 控制台 不暴露公网
3 节点不是装样子。配置中心走 Raft，2 节点选不出 Leader。Nacos 集群规模别小于 3，这是工程纪律。
二、多环境隔离：用 namespace，别只靠 group
很多团队一开始只用 public namespace，把 dev / test / prod 配置全堆在一起。这是大坑。
我现在固定的做法：
| 环境 | namespace | 用法 |
|---|---|---|
| dev | dev |
开发自己折腾 |
| test | test |
测试环境固定 |
| pre | pre |
预发，结构跟 prod 完全一致 |
| prod | prod |
线上，权限最严 |
group 我留给"业务线"维度：
pay组放支付相关order组放订单相关infra组放基础设施
namespace 切环境，group 切业务线。这套分法用过都说香。
三、灰度配置：Nacos 自己提供的 beta 发布
业务里经常需要"先发一部分机器"。
Nacos 配置中心有一个不那么显眼但很好用的功能——Beta 发布：在控制台发布配置时，可以指定一组 IP 先生效。
我习惯把它和发布平台对接：
实际效果是：你可以只针对某几台机器先生效新配置，其他机器拿到的还是旧值。
听起来朴素，但很多团队搞的"灰度系统"，最后底层就是借这个能力。
四、踩过的几个真实坑
下面这几条都是我实战里碰过、或者亲眼看着团队栽过的，不夸张地说，每一个都让人花过半天以上：
坑 1：临时实例假死，流量打不停
服务卡死、心跳线程还在。Nacos 不剔除，网关一直打流量。
应对：
- 网关侧自己做主动健康检查，别只信 Nacos。
- 关键服务改持久实例，让 Nacos 主动检查。
- 调用侧加熔断（Sentinel / Resilience4j）。
坑 2：MySQL 主备切换，Nacos 集群脑抽
Nacos 配置依赖 MySQL。某些版本 + 某些数据库连接池组合下，主备切换后 Nacos 没及时换连接，控制台开始报错。
应对：
- 数据库地址走 VIP / 中间件，不直连 IP。
- 配置
db.url走域名而不是 IP。 - 集群升级前先在预发跑一遍主备切换演练。
坑 3：跨机房延迟拖垮 Distro 同步
跨城多 region 部署 Nacos 集群，节点间同步抖动会让服务列表收敛慢，偶发几秒不一致。
应对：
- 不要跨城拉一个 Nacos 集群。每个 region 一套独立集群更稳。
- 多 region 之间通过双注册或服务网关同步，而不是依赖 Nacos 跨机房。
坑 4：客户端版本太杂
历史项目 Nacos client SDK 版本横跨好几代，老 client 连新 server 偶发兼容问题。
应对：
- 项目里统一 SDK 大版本。
- 服务升级 Nacos server 之前，先扫一遍业务方使用的 client 版本。
- 中间件团队定期发版本兼容矩阵。
坑 5：动态配置坑死人
配置一改全公司生效，听着爽，事故来得也快。
应对：
- 关键开关一律先 Beta 发布。
- 控制台配置改动接审计日志。
- 危险配置项加二次确认，操作记录可追溯。
五、SDK 接入的几个隐性细节
我看过太多团队把 client 当工具人用，没注意几个小地方：
1. @RefreshScope 不是免费的
Spring 里加 @RefreshScope 可以让 Bean 在配置变更时刷新，但代价是 Bean 变成代理模式，启动顺序、循环依赖容易出问题。
只给真正需要动态刷新的 Bean 加，不是全场加。
2. 监听器写法别写出阻塞
自己写的 ConfigService.addListener 回调里，不要做耗时操作。Nacos 客户端通知是同步触发的，回调阻塞会影响后续推送处理。
configService.addListener(dataId, group, new Listener() {
@Override
public Executor getExecutor() {
// 自己丢线程池里跑
return businessExecutor;
}
@Override
public void receiveConfigInfo(String configInfo) {
// 这里别 sleep / 别调外部接口阻塞
}
});
3. 启动期允许"读旧"
服务启动时如果连不上 Nacos，让它读 ~/nacos/config 里的本地快照启动，别死等连接。生产事故经常是 Nacos 抖一下，业务集体起不来。
六、Nacos 3.0 的 AI Registry：要把 MCP / Prompt 也注册进来
讲完传统部分，看一眼 3.0 给行业带来的新东西。
阿里官方对 Nacos 3.0 的定位是：
一个易于构建 AI Agent 应用的动态服务发现、配置管理和 AI 智能体管理平台。
人话翻译：Nacos 不再只管"服务和配置"，还想管 AI Agent 时代的几样新资产。
我的理解是：MCP server 也是一种"服务"，Prompt 也是一种"配置"。 Nacos 已经做过几亿级实例的 service registry，自然不希望 AI 这条线另搞一套体系。
值不值得用？我现在的态度比较保守：
- 传统注册和配置：直接升 3.0 没问题。
- AI Registry 的新能力：可以预研、可以小范围试，但生产落地我会等再过两个版本。
- MCP 注册：如果团队已经在用 MCP，且部署了 Nacos，一并管理是顺手的事；如果只是因为新名词去引入，我不推荐。
不要为了用新功能而上新功能。注册中心是底层基础设施，稳定永远比新潮重要。
七、迁移老项目的最小痛苦路径
如果你正打算从 Eureka / ZooKeeper / Apollo 迁过来，我一般建议这样的顺序：
要点：
- 先双注册：服务同时注册到旧注册中心和 Nacos，让生产先看到 Nacos 上有完整数据，再切流量。
- 配置最后迁：注册先迁，配置后迁。别颠倒——配置错了影响远比注册错大。
- 每一步都要可回滚：网关层、SDK 层都要支持快速切回。
- 监控同步上线：Nacos 自己有 metrics，新接入时务必把监控盯起来。
这套迁移路径不性感，但能让你在出问题时一步步退回去，不会一脚踏空。
八、什么时候你不该用 Nacos
写到这里，必须说点实话——
这些情况我反而不推荐 Nacos：
- 业务规模极小，单服务 + 一份 yaml 文件就够了。引注册中心反而是负担。
- 完全跑在 Kubernetes 上，服务发现可以走 K8s Service，配置走 ConfigMap / External Secrets，未必非得 Nacos。
- 多语言异构，对一致性要求极高，Java 不是主力。Consul / etcd 可能更合适。
- 公司本身已有成熟内部 service mesh / config service，没必要再引入一个新组件。
技术选型最忌讳"别人都用，所以我也用"。Nacos 强不等于在你的场景里强。
九、把三篇拼起来回看：我对 Nacos 的整体评价
到这里系列就收尾了。我把三篇看下来对 Nacos 的评价梳理成几句话：
- 它不是炫技，是务实。Distro + Raft + long-polling + 本地缓存，组合老牌技术解决一线工程问题。
- 它做对的最大一件事：把"服务发现 + 配置管理"合一。
- 它的硬约束：配置中心 ≥ 3 节点、依赖 MySQL、务必规划 namespace。
- 它的常见坑：临时实例假死、跨机房 Distro 抖、控制台暴露公网、SDK 版本杂。
- 它在 AI 时代的演进：3.0 把 MCP / Prompt 也纳进 Registry，这个方向值得关注，但生产端别冒进。
如果让我用一句话总结：
Nacos 是国内微服务团队最稳的注册和配置底座之一，也很可能是 AI 时代第一批被改造成 AI Agent Registry 的老牌基础设施。
它在工程世界里继续证明一件事：好用比好看更重要。
本系列三篇：
- [01｜重新拾起 Nacos：为啥团队最后还是回到了它]
- [02｜Nacos 内核拆一拆：Distro、Raft、长轮询到底在干啥]
- [03｜Nacos 生产落地：多环境、踩坑、和 3.0 的 AI Registry 演进]
