Nacos 架构与数据模型
动手用 Nacos 前先理解两件事：它对外提供什么接口（架构），数据按什么规则组织（模型）。Nacos 的数据模型分两套——服务/实例一套、配置一套，本章一次讲清。
整体架构
Nacos 对外提供双层入口（客户端 SDK 与 OpenAPI），对内是可水平扩展的服务端集群，数据落在存储层：
业务应用 / 异构系统
├─ 客户端 SDK（2.x 走 gRPC 长连接）
├─ OpenAPI（HTTP：/nacos/v1/ns/... 服务，/nacos/v1/cs/... 配置）
└─ 网页控制台（http://节点:8848/nacos）
│
服务端集群（Nacos Server，可单机运行）
│
存储层：内嵌 Derby 或 MySQL（配置、持久实例等数据）
服务数据模型：三级结构
服务侧按 service（服务）→ cluster（集群）→ instance（实例）三级组织，最外层还有 namespace 与 group 做隔离与分组：
namespaceId=public（命名空间，隔离环境/租户）
└─ group=DEFAULT_GROUP（分组，可按业务域划分）
└─ service=order-service（服务名，逻辑概念）
├─ cluster=DEFAULT（集群，如机房/单元）
│ └─ instance 192.168.1.10:8080（实例，真正干活的应用节点）
└─ cluster=shanghai
└─ instance 192.168.1.20:8081
服务与实例关键参数
注册、查询服务时最常用的字段如下：
| 参数 | 含义 | 默认/示例 |
|---|---|---|
| serviceName | 服务名，多个实例属于同一服务 | order-service |
| groupName | 分组，服务与配置共用 | DEFAULT_GROUP |
| clusterName | 集群名，服务内部再分机房/单元 | DEFAULT |
| ip / port | 实例地址，调用方据此发起请求 | 192.168.1.10 / 8080 |
| weight | 权重，客户端按权重做随机负载均衡 | 1.0 |
| ephemeral | 是否临时实例：true 走 AP，false 走 CP | true |
| namespaceId | 命名空间，跨环境/租户隔离 | public |
配置数据模型：三键定位
一份配置由 namespace + group + dataId 三个键唯一确定，缺一不可：
namespace（环境/租户隔离，默认 public，如 dev、prod）
└─ group（分组，默认 DEFAULT_GROUP）
└─ dataId（配置标识，如 order-service.properties）
| 键 | 含义 | 示例 |
|---|---|---|
| namespace | 换一套 namespace 就是完全隔离的一套配置与服务 | dev / test / prod |
| group | 同环境内按业务或团队再分组 | DEFAULT_GROUP |
| dataId | 具体某份配置，后缀决定内容格式 | order-service.properties |
同名 dataId 放在不同 namespace 或不同 group 下互不干扰，因此"改 namespace 即换环境"成为多环境管理的核心手段（见第 8 章）。
临时实例与持久实例
注册实例时必须想清楚 ephemeral 取什么值：
- 临时实例（ephemeral=true，默认）：由客户端心跳保活，断开自动摘除，数据不落库，量大、动态，适合绝大多数微服务；一致性走 AP。
- 持久实例（ephemeral=false）：由服务端主动健康检查，数据持久化保存，适合 DNS、Service Mesh 等需要长期稳定与强一致的场景；一致性走 CP。
两种实例对应的一致性协议细节在第 10 章展开，这里先建立印象：日常微服务用默认的临时实例即可。
小结
架构上记住"SDK/OpenAPI 双层入口 + 服务端集群 + 存储层"，模型上记住两套：服务是 namespace/group/service/cluster/instance 五层，配置是 namespace/group/dataId 三键，后面所有章节都在给这两个模型填充细节。