入门：Nacos 定义、发现+配置合一与双模式
基于 Nacos 2.x · 核于 2026-08
速查
- 定义：Nacos（Naming and Configuration Service）是阿里巴巴开源的服务发现与配置管理平台，把「动态服务发现」和「动态配置管理」合二为一，是 Spring Cloud Alibaba 核心、中国 Spring Cloud 微服务事实标准。
- 两大核心能力：①服务发现（服务注册、健康检查、订阅推送、AP/CP 双模式）；②配置中心（DataId/Group/命名空间三级模型、动态推送、灰度发布、历史回滚）。一个 Nacos 顶 Eureka + Spring Cloud Config 两套。
- 命名服务（Naming）：服务以「服务名 + 实例列表」注册，调用方按服务名查实例；客户端 SDK 订阅服务，实例上下线时 Nacos 推送变更（push 模型），不必轮询。
- 配置管理（Config）：配置以「命名空间 + Group + DataId」三级定位（如
public命名空间 +DEFAULT_GROUP+order-service-dev.yaml），客户端长轮询拉取，配置变了秒级推送，支持灰度发布（按 IP/集群）与历史版本回滚。 - AP/CP 双模式：服务发现默认 AP（Distro 协议，节点对等，高可用优先，临时实例主动报心跳）；配置存储用 CP（Raft 协议，强一致，持久化到 MySQL）。可按需切换服务发现的模式。
- 临时实例 vs 永久实例：临时实例（ephemeral=true，默认）— 客户端主动报心跳，不报即摘除，AP 模式；永久实例（ephemeral=false）— Nacos 主动探活，CP 模式，删了也留在目录（如数据库地址）。
- 健康检查：临时实例靠客户端主动上报心跳（默认 5s 一次，15s 不报标不健康，30s 不报摘除）；永久实例靠 Nacos 服务端主动探活（HTTP/TCP）。默认是临时实例主动上报。
- 命名空间（Namespace）：逻辑隔离单元，常用于环境隔离（dev/test/prod）或多租户。Group 用于配置分组（业务线/模块）。DataId 是具体配置集（如
order-service.yaml）。 - Spring Cloud Alibaba：
spring-cloud-starter-alibaba-nacos-discovery+spring-cloud-starter-alibaba-nacos-config两个 starter，加依赖 + 几行配置即接入，是国内 Spring Cloud 微服务主流。 - 与 Consul 区别：Nacos（AP/可切 CP，主动上报，配置中心原生，中国标准）/ Consul（CP，反向探，裸 KV，国际）。配置中心与生态是主要分野。
- 进阶顺序：服务发现与配置管理 → Spring Cloud 中国实践 → 参考。
一、Nacos 是什么：发现 + 配置合一
微服务架构需要两个基础设施：①注册中心（服务发现）；②配置中心（动态配置）。传统方案常拆两套——Eureka（注册）+ Spring Cloud Config（配置），或 Consul（注册）+ 外挂配置中心。Nacos 把这两者合一：
服务 A 启动
│
├──→ Nacos Naming（注册中心）
│ 服务名: order-service
│ 实例: [{ip:10.0.0.5, port:8080}, ...]
│ 健康检查: 客户端主动报心跳
│
└──→ Nacos Config（配置中心）
命名空间: dev
Group: ORDER_GROUP
DataId: order-service.yaml
配置: {db.host: 10.0.0.100, ...}- Naming（命名服务）：服务以「服务名 + 实例列表」形式注册。调用方按服务名查实例（或订阅推送），客户端负载均衡选一个调用。
- Config（配置管理）：配置以「命名空间 + Group + DataId」三级定位。客户端启动时拉取，运行时长轮询监听变化，配置变了 Nacos 秒级推送，无需重启。
- 合一的好处：一个组件、一套运维、一个控制台，比拆两套简单。这是 Nacos 在中国流行的核心理由——开发者只需认识一个 Nacos，就能搞定发现与配置。
一句话：Nacos 是 AP 优先的服务发现 + 原生配置中心，中国 Spring Cloud 事实标准。
二、AP/CP 双模式：按需切换
Nacos 的服务发现支持两种一致性模式，按实例类型自动选：
| 模式 | 协议 | 适用 | 特点 |
|---|---|---|---|
| AP（默认） | Distro | 临时实例（ephemeral=true） | 节点对等，每个节点都能写，最终一致；高可用优先，分区时各节点都能注册 |
| CP | Raft | 永久实例（ephemeral=false） | Leader 写、过半提交，强一致；分区时少数派不可写 |
- 临时实例走 AP：大多数微服务实例是临时的（容器/弹性伸缩），用 AP 保证注册高可用（即使部分 Nacos 节点故障也能注册），容忍短暂不一致（最终一致）。
- 永久实例走 CP：永久实例（如数据库、消息队列地址，不会频繁上下线）用 CP 保证强一致——所有节点看到同样的永久实例列表。
- 自动判断：实例注册时指定
ephemeral字段，Nacos 自动路由到对应模式。默认 ephemeral=true（临时/AP）。 - 与 Consul 对比：Consul 目录统一 CP（Raft）；Nacos 默认 AP，按需 CP，灵活性更高。
三、健康检查：主动上报为主
Nacos 的健康检查方式因实例类型而异：
- 临时实例（默认）— 客户端主动上报心跳：客户端 SDK 每 5s 向 Nacos 发一次心跳（beat）。15s 不发标
不健康（仍可查但不推荐），30s 不发自动摘除。这与 Consul 默认反向探相反——Nacos 让服务「自己说我活着」，适合「服务最清楚自己状态」。 - 永久实例 — Nacos 主动探活：服务端周期性探活（HTTP/TCP，类似 Consul），探不到标不健康，但不自动摘除（永久实例即使挂了也留目录，因为可能是预期维护）。
- 为什么默认主动上报：微服务实例动态、生命周期短，主动上报比服务端反向探更轻量（不用 Nacos 维护大量探活任务），且客户端最清楚自己是否健康（如队列消费者卡死，外部探不出来）。
四、配置中心：三级模型 + 动态推送
Nacos 配置中心用「命名空间 + Group + DataId」三级模型组织配置：
命名空间（Namespace）— 环境隔离（dev/test/prod）或多租户
└── Group — 配置分组（业务线/模块，如 ORDER_GROUP）
└── DataId — 具体配置集（如 order-service.yaml）
└── 配置内容（YAML/Properties/JSON）- 命名空间：默认
public。常用于环境隔离——dev/test/prod 各一个命名空间，互不干扰。也用于多租户（每个租户一个）。 - Group：默认
DEFAULT_GROUP。用于逻辑分组，如按业务线（ORDER_GROUP、PAYMENT_GROUP）或按模块。 - DataId：具体配置集，常用
${服务名}-${profile}.${后缀}（如order-service-dev.yaml）。 - 动态推送：客户端启动拉取配置后，通过长轮询（long polling）监听变化。配置在控制台改了，Nacos 立即通知客户端，秒级生效，无需重启。配合
@RefreshScope让 Spring Bean 重新注入新值。 - 灰度发布：可按 IP 或集群（cluster）灰度推送配置——只让部分实例先拿到新配置，验证后再全量。
- 历史版本回滚：Nacos 保留配置每次修改的历史版本，控制台一键回滚到任意历史版本（配错了能快速恢复）。
五、Nacos vs Consul：核心分野
| 维度 | Nacos | Consul |
|---|---|---|
| 出品方 | 阿里巴巴 | HashiCorp |
| 一致性 | AP 默认（可切 CP） | CP（Raft） |
| 健康检查 | 主动上报为主（临时实例） | 反向探为主（Agent 探服务） |
| 配置中心 | 原生（三级模型 + 灰度 + 回滚） | 裸 KV（无灰度/回滚原语） |
| DNS 接口 | 无 | 有（端口 8600） |
| 多 DC | 需集群联邦 | 原生（WAN Gossip） |
| Spring Cloud | Alibaba（中国事实标准） | 国际 |
| 典型场景 | 中国 Spring Cloud | 国际/多 DC/Go |
- 配置中心是关键差异：Nacos 是原生配置中心（三级模型 + 灰度 + 回滚），Consul 是裸 KV 要团队自拼。这是国内项目选 Nacos 的主因。
- 生态地域：Nacos 是 Spring Cloud Alibaba，中国事实标准；Consul 是国际派。选型常看团队地域与既有生态。
下一步
理解了 Nacos 的定位与双模式后，下一步深入服务发现与配置管理——注册/健康检查/订阅推送实战、配置三级模型、动态推送/灰度/回滚，以及Spring Cloud 中国实践——Spring Cloud Alibaba 集成与一致性协议详解。