Nacos五层数据模型：从Namespace到Instance详解

真实的菜

408人浏览 · 2026-06-11 10:00:11

真实的菜 · 2026-06-11 10:00:11 发布

一个namespace配错，整个测试环境挂了：Nacos五层数据模型彻底讲透

一个namespace引发的血案

“你把测试环境的配置发到生产去了。”

运维老张的声音很平静，但我知道他在压着火。

事情的经过很简单。我在 Nacos 控制台改了一个数据库连接池大小的配置，从 20 改到 50。确认、发布、生效——一切正常。

五分钟后，生产的订单服务开始疯狂报超时。

原因是连接池从 20 改成 50 之后，数据库撑不住了。而我的本意是改测试环境的配置，让压测能跑更高并发。

我在 Nacos 控制台里没切 namespace。

public namespace 下改的配置，直接推到了生产环境。

从那以后我给自己立了一条规矩：任何 Nacos 操作之前，先确认三件事——namespace、group、service。少一个不看，手不碰鼠标。

这篇文章，我把这三个维度加上 Cluster 和 Instance，凑成 Nacos 的完整五层数据模型，逐层拆开来讲清楚每层到底怎么用、怎么划、边界在哪里。

五层模型全景图

五层逐级收敛：Namespace（最粗粒度）→ Group → Service → Cluster → Instance（最细粒度）。每一层解决一个特定的隔离或路由问题。

第一层：Namespace —— 环境隔离的最后一道防线

它是什么

Namespace 是 Nacos 数据模型的最顶层。它的核心作用就一个：隔离。

一个 Namespace 里的服务和配置，另一个 Namespace 完全看不到。

典型划分方式

划分策略	示例	适用场景
按环境	dev / staging / prod	最常用，防止测试配置污染生产
按租户	tenant-a / tenant-b	SaaS 多租户平台
按业务线	order-biz / payment-biz	大型项目，不同业务线独立运维
按团队	team-frontend / team-backend	前后端分离，各自管理自己的服务

代码里怎么用

// 创建 ConfigService 时指定 namespace
Properties properties = new Properties();
properties.put("serverAddr", "127.0.0.1:8848");
properties.put("namespace", "prod");  // 这里就是 namespace

ConfigService configService = NacosFactory.createConfigService(properties);

// 获取配置时，自动带上 namespace
String config = configService.getConfig("database.yaml", "ORDER_GROUP", 3000);

对应的 bootstrap.yml：

spring:
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
        namespace: prod          # 服务发现的 namespace
      config:
        server-addr: 127.0.0.1:8848
        namespace: prod          # 配置管理的 namespace

一个关键细节

服务发现和配置管理的 namespace 可以不同。你可以让服务在 prod namespace 下注册，但从 public namespace 下读取某些公共配置。

spring:
  cloud:
    nacos:
      discovery:
        namespace: prod           # 服务注册在 prod
      config:
        namespace: public         # 配置从 public 读

不过大多数时候你不需要这么玩。99% 的场景是 discovery 和 config 用同一个 namespace。

第二层：Group —— 同一环境下的再分类

它是什么

Namespace 把环境隔开了。但在同一个环境下，你可能有几十上百个服务。全部堆在同一个平面里，控制台一眼望去全是服务名，找都找不到。

Group 解决的就是这个问题。它让你在同一个 Namespace 下再做一次归类。

常见拆分方式

划分策略	示例	适用场景
按业务域	ORDER / USER / PAYMENT / INVENTORY	所有项目通用
按应用名	order-service / order-admin	一个业务有多个子应用
按配置类型	db / cache / mq / business	配置文件按类别分 group

推荐做法是按业务域分 Group。因为：

# 订单域的所有配置放在 ORDER_GROUP 下
# 订单服务的配置
spring.cloud.nacos.config.group=ORDER_GROUP
spring.cloud.nacos.config.data-id=order-service.yaml

# 订单域的公共数据库配置
spring.cloud.nacos.config.shared-configs[0].group=ORDER_GROUP
spring.cloud.nacos.config.shared-configs[0].data-id=order-db.yaml

同一个 GROUP 下的服务共享同一套数据库、同一个 Redis 集群、同一个消息队列配置。

第三层：Service —— 微服务的抽象单元

它是什么

Service 就是你的微服务。订单服务是一个 Service，用户服务是另一个 Service。

在 Nacos 里，Service 不是一个抽象概念，是一个具体的数据实体。它有名字、有健康检查配置、有元数据、有一组实例。

服务注册时发生了什么

// 这一行代码在 Nacos 内部做了很多事
namingService.registerInstance("order-service", instance);

Nacos 收到这个请求后：

检查 order-service 这个 Service 是否存在，不存在就创建一个
把 instance 挂到这个 Service 下
如果 instance 的 cluster 信息匹配某个已有 cluster，就加入；否则创建一个新 cluster
触发服务变更事件，通知所有订阅者

注册流程第一步是查 Service 是否存在。Service 一旦创建就不会自动删除，即使所有实例都下线了。

第四层：Cluster —— 同城多活的物理边界

它是什么

同一个服务，部署在上海和北京两个机房。上海的用户应该优先访问上海的实例，北京的访问北京的。

Cluster 就是给同一个 Service 下的实例打上物理位置标签。

注册时指定 cluster

Instance instance = new Instance();
instance.setIp("10.0.1.10");
instance.setPort(8080);
instance.setClusterName("SH");  // 上海机房

namingService.registerInstance("order-service", instance);

调用时优先同 cluster

// 订阅时可以通过 cluster 过滤
List<ServiceInstance> instances = namingService.selectInstances(
    "order-service",
    "SH",     // 优先返回上海集群的实例
    true      // healthyOnly = true
);

Dubbo 和 Spring Cloud LoadBalancer 都支持基于 Nacos Cluster 的就近路由。

第五层：Instance —— 最小运行单元

它是什么

Instance 是一个服务实例的完整描述。不只是 IP + 端口。

一个完整的 Instance 长什么样

Instance instance = new Instance();
instance.setInstanceId("order-service-10.0.1.10-8080");  // 唯一标识
instance.setIp("10.0.1.10");          // IP
instance.setPort(8080);               // 端口
instance.setWeight(1.0);              // 权重（0~1）
instance.setHealthy(true);            // 健康状态
instance.setEnabled(true);            // 是否接收流量
instance.setEphemeral(true);          // 临时实例 or 持久化实例
instance.setClusterName("SH");        // 所属集群
instance.setServiceName("order-service");  // 所属服务
instance.setMetadata(new HashMap<>() {{  // 自定义元数据
    put("version", "v2.0.1");
    put("zone", "shanghai-hq");
}});

9 个核心字段，缺一个都可能影响路由逻辑。

weight 和 enabled 的区别（很多人搞混）

字段	作用	典型场景
`weight`	控制流量比例	灰度发布：新版本 weight=0.1，旧版本 weight=0.9
`enabled`	是否接收流量（开关）	临时摘除：enabled=false，实例还在但不再接收请求
`healthy`	健康状态（只读）	心跳断了 Nacos 自动标记 healthy=false

weight 不是负载均衡的唯一因子。 Spring Cloud LoadBalancer 默认用轮询，不受 weight 影响。你需要自定义 LoadBalancer 规则才能让 weight 生效。

五层的实际配合：一个完整案例

假设你有一个 SaaS 平台，三个客户租户（A公司、B公司、C公司），每个租户一套环境（dev / prod），每个环境有订单服务和用户服务，订单服务部署在上海和北京。

数据模型这样划分

完整坐标定位一个实例：

Namespace: tenant-a-prod
  └── Group: ORDER
        └── Service: order-service
              └── Cluster: SH
                    └── Instance: 10.0.1.10:8080 (weight=1.0, healthy=true)

举个反例：别这么干

上次我在一个项目里看到这样的划分：

Namespace: prod
  └── Group: DEFAULT_GROUP
        └── 下面挂了 120 个 Service

120 个服务全在 DEFAULT_GROUP 下。 控制台里翻页翻到手软。

至少应该按业务域拆成 5~8 个 Group：

Namespace: prod
  ├── Group: ORDER_GROUP     (12 个服务)
  ├── Group: USER_GROUP      (8 个服务)
  ├── Group: PAYMENT_GROUP   (6 个服务)
  ├── Group: INVENTORY_GROUP (5 个服务)
  └── Group: INFRA_GROUP     (网关、认证等基础设施)

最佳实践速查表

层次	推荐做法	不推荐
Namespace	按环境分（dev/staging/prod），最多加租户	按团队分，一个团队一个 namespace
Group	按业务域分，5~8 个为宜	全部堆在 DEFAULT_GROUP
Service	和 Spring 应用名一致	用中文或特殊字符
Cluster	按物理机房分（SH/BJ/GZ）	和 Service 重复命名
Instance	weight 用于灰度，enabled 用于下线	weight=0 代替 enabled=false