illegalCreed

中文

English

中文

English

Appearance

服务发现、健康检查与配置管理 ​

基于 Nacos 2.x · 核于 2026-08

速查 ​

  • 服务注册：服务启动调 namingService.registerInstance(serviceName, ip, port)（SDK 自动）或 Open API POST /nacos/v1/ns/instance，登记服务名 + 实例 IP/端口 + ephemeral（临时/永久）。临时实例默认 AP（Distro），永久实例走 CP（Raft）。
  • 健康检查（临时实例）：客户端 SDK 每 5s 主动发一次心跳（beat）给 Nacos。15s 不发标记「不健康」（仍可查但不推荐路由），30s 不发自动摘除。这是「主动上报」模式。
  • 健康检查（永久实例）：Nacos 服务端周期性探活（HTTP/TCP），探不到标不健康，但不自动摘除（永久实例即使挂了留目录）。需手动 deregister。
  • 服务发现（订阅推送）：调用方可主动查（getInstances，pull）或订阅推送（subscribe(listener)，push）。订阅模式下实例上下线时 Nacos 主动推送变更到订阅者，调用方实时更新本地实例列表，不必轮询。
  • 客户端负载均衡：SDK 拿实例列表后自己挑（轮询/随机/权重，配合 Ribbon/LoadBalancer），Nacos 不做服务端负载均衡。
  • 配置定位（三级）：Namespace（环境/租户）+ Group（业务分组）+ DataId（配置集，如 order-service-dev.yaml）。默认 Namespace=public，Group=DEFAULT_GROUP。
  • 动态推送（长轮询）：客户端拉取配置后，对每个 DataId 发起长轮询（请求挂起 ~30s），配置变化时 Nacos 立即返回，客户端重新拉取新配置。配合 Spring @RefreshScope 让 Bean 重新注入。
  • 灰度发布：配置推送可按 IP 或 cluster 灰度——只让指定实例先拿新配置，验证后全量。控制台或 API 配置 betaIps / targetCluster。
  • 历史版本回滚：Nacos 持久化每次配置修改（存 MySQL），控制台「历史版本」一键回滚到任意历史版本，配错能快速恢复。
  • 集群部署：生产 Nacos 集群 3+ 节点，配置数据持久化到外置 MySQL（主从），节点间 Distro（AP 服务数据）+ Raft（CP 配置/元数据）同步。

一、服务注册与命名服务 ​

服务接入 Nacos 第一步是注册。SDK 自动完成，也可调 Open API：

java
// Java SDK（Spring Cloud Alibaba 自动注册，无需手写）
NamingService naming = NamingFactory.createNamingService("127.0.0.1:8848");
naming.registerInstance("order-service", "10.0.0.5", 8080);
// 默认 ephemeral=true（临时实例，AP，主动报心跳）
bash
# Open API（非 Java 应用）
curl -X POST 'http://127.0.0.1:8848/nacos/v1/ns/instance' \
  -d 'serviceName=order-service&ip=10.0.0.5&port=8080&ephemeral=true'
  • serviceName：服务名（多实例同名）。
  • ip + port：实例地址。
  • ephemeral：临时（true，默认，AP，主动报心跳）vs 永久（false，CP，服务端探活）。
  • 集群（cluster）：可选，实例可归属某集群（如机房 cluster），用于同机房优先路由。
  • 权重（weight）：实例权重，影响负载均衡选中概率（权重越大越可能被选）。

二、健康检查与故障摘除 ​

临时实例（默认）— 主动上报 ​

客户端 SDK 启动后，每 5s 向 Nacos 发心跳（beat）：
   POST /nacos/v1/ns/instance/beat
   {serviceName, ip, port, ...}

Nacos 维护心跳记录：
   5s 内有心跳 → 健康（healthy=true）
   15s 无心跳 → 标记不健康（healthy=false，仍可查但不推荐）
   30s 无心跳 → 自动摘除（deregister，从实例列表删除）
  • 主动上报优势：客户端最清楚自己状态（如业务线程死锁，外部探不出来，但心跳线程也死了自然不报 → 摘除）。
  • 15s 标不健康 vs 30s 摘除：双阈值，先软降级（不健康但不删，可能短暂网络抖动），再硬摘除（确认宕机）。

永久实例 — 服务端探活 ​

Nacos 服务端周期性探活永久实例（HTTP/TCP）：
   探到 → 健康
   探不到 → 标记不健康，但不自动摘除（永久实例可能预期维护）
   恢复后自动标回健康
  • 永久实例场景：数据库、Redis、消息队列地址——这些不会频繁上下线，挂了也可能是预期维护，不应自动删，留目录供查询。

三、服务发现：订阅推送（Push 模型） ​

Nacos 服务发现支持 pull 与 push 两种：

java
// 方式 1：主动查询（pull，每次调用都查）
List<Instance> instances = naming.selectInstances("payment-service", true);

// 方式 2：订阅推送（push，推荐）— 注册监听器，实例变化时 Nacos 推送
naming.subscribe("payment-service", event -> {
    List<Instance> instances = event.getInstances();  // 更新本地缓存
    // 后续调用用本地缓存的实例列表
});
  • 订阅推送（push）：调用方注册监听器，Nacos 在实例上下线时主动推送变更事件，调用方更新本地实例列表。比 pull 高效（不轮询）、实时（变化秒级推送）。
  • 客户端负载均衡：SDK（Spring Cloud LoadBalancer / Ribbon）拿实例列表后自己选一个（轮询/随机/权重/MetadataZone 优先），Nacos 不做服务端转发。
  • gRPC 长连接（2.x）：Nacos 2.x 用 gRPC 长连接替代 1.x 的 HTTP 长轮询做推送，更轻量、更实时。

四、配置中心：三级模型 ​

Nacos 配置以「命名空间 + Group + DataId」三级定位：

Namespace（命名空间）
  └─ public（默认）
  └─ dev（开发环境）
  └─ prod（生产环境）
       └─ Group（分组）
            └─ DEFAULT_GROUP（默认）
            └─ ORDER_GROUP（订单业务线）
                 └─ DataId（配置集）
                      ├─ order-service.yaml      （主配置）
                      ├─ order-service-dev.yaml  （dev profile）
                      └─ common.yaml             （共享配置）
  • Namespace：环境隔离（dev/test/prod）或多租户。默认 public。不同 Namespace 配置互不可见。
  • Group：逻辑分组，默认 DEFAULT_GROUP。可按业务线/模块分（如 ORDER_GROUP、PAYMENT_GROUP）。
  • DataId：配置集名，约定俗成 ${服务名}-${profile}.${格式}（如 order-service-dev.yaml）。格式支持 properties/yaml/json/txt。
  • 共享配置：多个服务可通过 shared-configs 引用同一份公共配置（如 common.yaml 存数据库连接）。

五、动态推送、灰度与回滚 ​

动态推送（长轮询 / gRPC） ​

java
// Spring Boot 启动时自动拉取配置 + 监听变化
@RefreshScope   // 配置变化时该 Bean 重新创建，注入新值
@RestController
class OrderController {
    @Value("${order.timeout:3000}") int timeout;  // 配置变了自动更新
}
  • 客户端拉取配置后，对每个 DataId 发起长轮询（挂起 ~30s）；配置变化时 Nacos 立即响应，客户端重新拉取并触发 @RefreshScope Bean 重建。
  • 无需重启：改配置秒级生效，是配置中心的核心价值（不必为改个超时时间重启整个服务）。

灰度发布 ​

  • 按 IP 灰度：控制台或 API 配置 betaIps=10.0.0.5,10.0.0.6，新配置只推送给这几台，其他实例保持旧配置。验证无误后「停止灰度」全量推送。
  • 按集群灰度：targetCluster=SHANGHAI，只推给上海集群，北京集群不变。

历史版本回滚 ​

  • Nacos 持久化配置每次修改到 MySQL（his_config_info 表），保留历史快照。
  • 控制台「配置历史」可查看某 DataId 的所有修改记录，一键回滚到任意历史版本。配错了能秒级恢复，这是裸 KV（如 Consul）做不到的。

六、集群部署与持久化 ​

生产 Nacos 集群（3+ 节点）的架构：

   Nacos 节点 1   Nacos 节点 2   Nacos 节点 3   （节点对等）
       │              │              │
       │  Distro（AP）同步服务数据   │  （临时实例的注册信息）
       │  Raft（CP）同步配置/元数据  │  （永久实例、配置）
       │              │              │
       └──────────────┼──────────────┘
                      ▼
                MySQL（主从）           ← 配置持久化（config_info 表）
  • 节点对等：Nacos 节点无 Leader（AP 模式下），任一节点都能接受注册与查询，互相 Distro 同步服务数据。
  • 配置走 MySQL：配置数据持久化到外置 MySQL（主从高可用），所有 Nacos 节点共享同一 MySQL。这是 Nacos 配置可靠性的基础（MySQL 主从 + 定期备份）。
  • Raft 仅用于永久实例/元数据：少量需要强一致的数据（永久实例列表、Nacos 自身元数据）走 Raft，Leader 写、过半提交。

交互演示 ​

本叶无专门可视化。建议本地起 Nacos（sh startup.sh -m standalone），在控制台（http://localhost:8848/nacos，默认 nacos/nacos）实操配置发布与服务注册。

下一步 ​

理解了发现与配置后，下一步看Spring Cloud 中国实践——Spring Cloud Alibaba 集成、一致性协议（Distro + Raft）详解、与 Consul 的横向选型对比。