文档
前言
在微服务架构中，服务实例的 IP/端口是动态变化的，如果每个服务都硬编码调用地址，系统将寸步难行。Nacos 作为阿里开源的注册 + 配置中心，解决了"服务在哪"和"配置怎么管"两个核心问题。
第一章：理解服务注册与发现
1.1 没有注册中心时
ServiceA 调用 ServiceB
→ 需要在代码/配置文件里写死 ServiceB 的地址
→ ServiceB 扩容、缩容、迁移 → 必须修改 ServiceA 的配置
→ 修改 → 重启 → 中断服务
1.2 有了 Nacos 后
ServiceB 启动 → 向 Nacos 注册（IP:Port）
ServiceA 启动 → 从 Nacos 订阅 ServiceB 的地址列表
ServiceB 扩容 → Nacos 推送新实例给 ServiceA
ServiceB 宕机 → Nacos 健康检查剔除，ServiceA 自动感知
1.3 Nacos 核心概念
| 概念 | 说明 | 类比 |
|---|---|---|
| Namespace（命名空间） | 环境隔离（dev/test/prod） | Git 分支 |
| Group（分组） | 同一环境下的业务分组 | 文件夹 |
| Service（服务） | 一组提供相同功能的实例 | 一个应用 |
| Instance（实例） | 一个具体的服务节点 | 一台机器上的进程 |
| Data ID（配置标识） | 唯一标识一个配置 | 文件名 |
| Config（配置内容） | 具体的配置项 | 文件内容 |
第二章：AP 与 CP 模式的选择
2.1 CAP 回顾
- C（Consistency）：所有节点同一时刻数据一致
- A（Availability）：每个请求都能收到响应
- P（Partition Tolerance）：网络分区时系统仍能工作
CAP 不可兼得，只能三选二。
2.2 Nacos 的独特之处：AP + CP 可切换
# AP 模式（默认）：优先保证可用性
nacos.core.protocol.raft.strictMode=false
# CP 模式：优先保证一致性（适合对数据一致性要求高的场景）
nacos.core.protocol.raft.strictMode=true
| 模式 | 适用场景 | 取舍 |
|---|---|---|
| AP | 一般微服务注册发现 | 网络分区时各节点可独立工作，恢复后自动合并 |
| CP | 金融/支付等强一致场景 | 网络分区时少数节点拒绝写入 |
这是 Nacos 相比 Eureka（纯 AP）和 ZooKeeper（纯 CP）的核心优势。
2.3 健康检查机制
临时实例（ephemeral=true，默认）
→ 客户端主动心跳（5s 间隔）
→ 15s 无心跳 → 标记不健康
→ 30s 无心跳 → 剔除
永久实例（ephemeral=false）
→ Nacos Server 主动探测（TCP/HTTP/MySQL）
→ 探测失败 → 标记不健康但不剔除
第三章：配置管理深入
3.1 配置的三级隔离
Namespace（环境）→ Group（业务域）→ Data ID（配置项）
示例：
dev → ORDER_GROUP → order-service.yaml
prod → ORDER_GROUP → order-service.yaml
3.2 配置优先级（Spring Cloud）
1. 命令行参数（最高）
2. Nacos 扩展配置（shared-configs → extension-configs）
3. Nacos 主配置（${spring.application.name}.${file-extension}）
4. application.yml（本地）
5. bootstrap.yml（本地，最低）
3.3 灰度配置发布
# 在 Nacos 控制台：配置管理 → 灰度发布
# 指定 IP 白名单，仅对特定实例生效
gray-ip-list: 192.168.1.100,192.168.1.101
3.4 配置回滚
Nacos 自动保存每次发布的快照（最多 30 个版本），控制台一键回滚到任意历史版本。
第四章：Nacos 集群部署要点
4.1 推荐架构
┌─────────────┐
│ Nginx LB │
└──────┬──────┘
┌──────────────┼──────────────┐
┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐
│ Nacos #1 │ │ Nacos #2 │ │ Nacos #3 │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
└──────────────┼──────────────┘
┌──────┴──────┐
│ MySQL │ ← 外部存储（共享）
└─────────────┘
4.2 关键配置
# cluster.conf（每个节点都要配置）
192.168.1.10:8848
192.168.1.11:8848
192.168.1.12:8848
三个节点形成 Raft 集群，Leader 负责写，Follower 可读。
第五章：与其他注册中心对比
| 特性 | Nacos | Eureka | Consul | ZooKeeper |
|---|---|---|---|---|
| CAP 模型 | AP/CP 可切换 | AP | CP | CP |
| 配置中心 | ✅ 内置 | ❌ | ✅ Key/Value | ❌（需 Curator） |
| 健康检查 | TCP/HTTP/MySQL/心跳 | 心跳 | TCP/HTTP/gRPC | KeepAlive |
| 控制台 | ✅ 功能完整 | ✅ 只读 | ✅ | ❌（需第三方） |
| 多数据中心 | ✅ | ✅ | ✅ | ❌ |
| Spring Cloud | ✅ 原生 | ✅ 原生 | ✅ | ✅ |
| Dubbo 支持 | ✅ 首选 | ❌ | ❌ | ✅ |
| 雪崩保护 | ✅ | ✅ | ❌ | ❌ |
思考题
- 在 CAP 理论中，Nacos 如何做到 AP 和 CP 模式切换？底层的 Raft 协议扮演什么角色？
- 配置热更新时，Nacos 客户端是如何感知到配置变化的？长轮询机制的原理是什么？
- 如果 Nacos 集群全部宕机，已注册的服务之间还能互相调用吗？为什么？
- 为什么 Nacos 2.x 将 gRPC 作为默认通信协议？相比 HTTP 有什么优势？
下一步
- 学习 Spring Cloud Gateway + Nacos 实现动态路由
- 学习 Sentinel + Nacos 实现限流规则持久化
- 学习 Dubbo + Nacos 实现 RPC 服务治理