Nacos：注册与配置中心一体化

项目地址：https://github.com/alibaba/nacos 定位：阿里开源的"动态服务发现 + 配置管理 + 服务 DNS"平台，国内微服务体系（Spring Cloud Alibaba 系）的事实标配之一。

元信息	说明
语言	Java（内核）+ 控制台
星标	30k+ ⭐
协议	Apache 2.0
部署形态	单机（Derby）/ 集群（MySQL + Raft）
对比阅读	第 10 篇 etcd（通用一致性 KV 的对照面）

1、背景：注册与配置中心的成对逻辑

微服务体系的两个"动态性"需求：

服务发现（运行时动态）：
  实例上下线 → 调用方感知 → 流量摘除/路由更新
配置管理（发布时动态）：
  配置热更新 → 不重启生效 → 灰度发布/回滚

历史上它们是两个产品（Eureka+Config、Consul+Vault、ZooKeeper 双肩挑），Nacos 的产品判断：两者共享 90% 的基础设施（元数据存储、推送、健康检查、控制台），一体化交付运维成本减半。国内 Spring Cloud Alibaba 生态的捆绑，让它成为大厂与中小厂共同的选择。

2、核心架构

2.1、数据模型：Namespace → Group → Service/DataId

Namespace（环境隔离：dev/test/prod）
   └── Group（业务分组：DEFAULT_GROUP / 自定义）
          └── Service（服务） / DataId（配置项）
                 └── 实例列表 / 配置内容

三层命名空间是它的精髓：环境用 Namespace 硬隔离、业务用 Group 软分组、灰度用集群/权重做细粒度——比"一个平坦的 KV 空间"（etcd 裸用）更贴近组织结构。

2.2、两种实例与健康检查

类型	注册方式	健康检查	语义	典型场景
临时实例	客户端心跳上报	心跳超时（默认 15s/30s）自动剔除	实例与注册中心"弱绑定"，宕了自动消失	K8s Pod/弹性扩缩容（主流）
持久实例	服务端主动探测	TCP/HTTP 探测，不健康仅标记不删除	实例需人工/外部管理	DB/中间件这类"运维对象"

对照第 10 篇 etcd 的 lease 机制：临时实例=带 TTL 的租约（心跳续期，进程死了实例自动消失），思想同源，Nacos 把它产品化了。

2.3、一致性与订阅推送

集群内：Distro 协议（AP，临时实例的就近同步）+ Raft（CP，持久数据/元数据）
        → "分而治之"：高频心跳走 AP 保可用，低频元数据走 CP 保一致
客户端：长轮询（1.x 配置，默认 30s hold）+ gRPC 长连接（2.x 服务发现与配置推送）
        → 配置变更秒级触达全部客户端

Distro 是值得细读的设计：每个节点对部分数据"负责"，客户端连任意节点都能写（转发到负责人同步），读走本地——用"最终一致"换注册中心在网络分区时的可用性（注册中心短暂不一致的代价 << 注册中心不可用）。

3、快速上手

# 单机（测试）
docker run -d -p 8848:8848 -p 9848:9848 \
  -e MODE=standalone nacos/nacos-server:v2.3.2
# 控制台 http://localhost:8848/nacos（默认 nacos/nacos）

# 配置管理：控制台建配置 DataId=app-dev.yaml，或 API：
curl -X POST "http://localhost:8848/nacos/v1/cs/configs" \
  -d "dataId=app-dev.yaml&group=DEFAULT_GROUP&content=rate.limit: 100"

# Spring Cloud 接入（bootstrap.yml）
# spring.cloud.nacos.config.server-addr=localhost:8848
# spring.cloud.nacos.discovery.server-addr=localhost:8848

// 配置热更新（@RefreshScope 或 NacosConfigListener）
@NacosConfigListener(dataId = "app-dev.yaml")
public void onChange(String newConfig) {
    // 配置变更回调，秒级触达
}

4、生产实践清单

集群与存储：生产至少 3 节点 + 外置 MySQL（双主或 RDS）；Derby 只能单机玩；节点间 9848（gRPC，客户端）/7848（Raft）端口要通；
鉴权必须开：默认无鉴权是历史包袱——nacos.core.auth.enabled=true + 自定义 key；2023 年多个 0day 均源于裸奔 Nacos 暴露公网，8848 永远不进公网；
发布纪律：配置变更是"热发布的生产变更"——用 Nacos 的"灰度发布/Beta 推送"（先推一台验证）+ 变更历史（控制台可一键回滚）；把 DataId 纳入 CMDB 与审批流，别让配置中心变成"人人可改的数据库"；
容量与推送风暴：万级实例 × 高频心跳有上限；2.x gRPC 长连接显著优于 1.x 轮询，升级前压测；客户端订阅做合并（监听 DataId 数收敛）；
与 K8s 的关系（关键认知）：Pod 天然有 Service/Endpoint——K8s 内的服务发现不需要 Nacos，直连 Service 即可；Nacos 的位置在"混合云/非 K8s 部署的多语言体系"与"配置中心"这个角色上。别在纯 K8s 集群里为了注册中心装 Nacos，那是给系统加了个多余的依赖；
灾备：MySQL 备份 + Nacos 配置导出（控制台/OPENAPI 全量导出 YAML）入 Git——配置的最终事实源应该是 Git，Nacos 是分发层（与第 5 篇声明式思想一致）。

5、横向对比

方案	注册中心	配置中心	一致性	生态
Nacos	✅ AP/CP 可选	✅ 强（灰度/回滚/多格式）	Distro+Raft	Spring Cloud Alibaba/多语言 SDK
Consul	✅	✅（KV 简单）	Raft	HashiCorp 系/多语言/dns
Eureka+Config	✅（已停更）	✅（弱）	AP	Netflix 系（黄昏）
etcd（第 10 篇）	裸用可	裸用可	Raft	K8s 系/自研平台
Apollo	❌	✅（配置领域最深）	自研	携程系/Java 重

选型速判：Java/Spring Cloud Alibaba 栈 → Nacos；配置管理需求极重（审批流/多环境/细粒度权限）→ Apollo + 任意注册中心；多语言+HashiCorp 工具链 → Consul；自研平台要原语级控制 → etcd。

6、面试高频问答

Q：注册中心选 AP 还是 CP？ A：主流选 AP（Eureka/Nacos 临时实例）。理由：注册中心短暂不一致只影响"新发现的实例列表"，注册中心不可用则全链路故障；且实例有客户端心跳兜底。Paxos/Raft 强一致在分区时会牺牲可用性——对"名字服务"不划算。
Q：配置推送为什么用长轮询而不是长连接？ A：1.x 用长轮询（30s hold，兼容 HTTP 代理与负载均衡，实现简单）；2.x 换 gRPC 长连接（推送延迟从 ~秒级到毫秒级）。工程权衡：先保证"任何网络环境可用"，再优化延迟。
Q：Nacos 和 ZooKeeper 做注册中心的区别？ A：ZK 是 CP——主挂选举期间（30s+）整个注册表不可写，且临时节点靠会话，网络抖动会引发"实例批量掉线风暴"；Nacos Distro 分区时各节点仍可读写本地负责的数据，可用性优先。
Q：配置加密怎么做？ A：Nacos 内置配置加密插件（AES 密钥托管 KMS），或上层用 Jasypt 在客户端解密；敏感配置（DB 密码）最佳实践是"配置中心只放引用，真值在 Vault/KMS"。

7、总结

Nacos 的成功是"生态卡位 + 产品判断"的双重胜利：一体化降低运维成本、Distro 分治一致性与可用性、控制台把灰度/回滚做成标配。但要清醒使用它的边界——纯 K8s 环境里它的注册中心角色是冗余的，它的真正阵地是混合架构与配置管理。与第 10 篇 etcd 对读，你会发现"注册中心"们殊途同归：lease/TTL + watch 推送 + 多级命名空间，只是包装深浅不同。

8、参考资料

官方文档：https://nacos.io/docs/latest/
GitHub：https://github.com/alibaba/nacos
Distro 协议：https://nacos.io/docs/ebook/ktwggk.mdx
本系列第 10 篇（etcd 对比）、第 5 篇（声明式与 GitOps）