Nacos 心跳机制详解

目录

一、实例类型与健康检查模式

二、临时实例心跳机制（核心）

1. 客户端：BeatReactor 定时发心跳

2. 服务端：心跳处理与状态维护

3. 核心阈值（可配置）

4. 交互时序（临时实例）

三、永久实例健康检查

四、Nacos 2.x 重大优化：gRPC 长连接

五、常见问题与配置

六、总结

---

Nacos 心跳机制的核心是：临时实例由客户端主动定时发心跳续约，服务端超时标记不健康并最终剔除；永久实例由服务端主动探活，1.x 用 HTTP 短轮询，2.x 全面改用 gRPC 长连接，大幅降 overhead 并提升实时性Nacos。

---

一、实例类型与健康检查模式

Nacos 把服务实例分成两类，心跳 / 健康检查逻辑完全不同：

• 临时实例（Ephemeral=true，默认）用于普通微服务，客户端主动心跳 + 服务端超时剔除。实例会话化，客户端断连 / 停发心跳就会被踢，适合动态扩缩容场景Nacos。

• 永久实例（Ephemeral=false）用于数据库、消息队列等静态基础设施，服务端主动健康探测。实例长期存在，客户端不发心跳，由 Nacos 主动发起 TCP 连接探测或 HTTP 接口检查Nacos。

二、临时实例心跳机制（核心）

1. 客户端：BeatReactor 定时发心跳

• 实例注册后，SDK 的BeatReactor启动定时任务，默认每 5s发一次心跳（Beat）。
• 心跳内容：IP + 端口 + 服务名 + 集群 + 权重 + 元数据。
• 版本差异：
  • 1.x：HTTP PUT 请求/nacos/v1/ns/instance/beat，每次心跳都是独立 TCP 连接，开销大。
  • 2.x：gRPC 长连接，心跳复用连接，同时依赖连接本身的保活（Keepalive），连接断开即视为实例失效。

2. 服务端：心跳处理与状态维护

• 收到心跳 → 更新实例的lastBeatTime（最后心跳时间戳）→ 标记healthy=true。
• 服务端定时任务（默认每 5s 扫描一次）：
  • 15s 未收到心跳（3×5s）：标记healthy=false（不健康）。
  • 30s 未收到心跳（6×5s）：从注册表剔除实例，不再推给消费者。

3. 核心阈值（可配置）

心跳间隔：5s（client → server） 不健康阈值：15s（server 判定） 剔除阈值：30s（server 执行）

4. 交互时序（临时实例）

1. 服务启动 → 注册临时实例（ephemeral=true）。
2. 客户端 BeatReactor → 每 5s 发心跳。
3. 服务端 → 更新lastBeatTime、健康状态。
4. 服务端定时扫描：
   • <15s：健康
   • 15–30s：不健康
   • 30s：删除
5. 客户端断连 / 进程崩溃 → 停止发心跳 → 30s 后被剔除。

三、永久实例健康检查

• 客户端不发心跳，实例永久存储，除非手动删除Nacos。
• 服务端主动探活（默认每 5s）：
  • TCP 探测：向实例 IP:Port 建连，成功则健康，否则不健康Nacos。
  • HTTP 探测：指定接口（如/health），返回 2xx 则健康Nacos。
• 连续探测失败 N 次 → 标记不健康，但不自动剔除，需人工干预或配置自动删除Nacos。

---

四、Nacos 2.x 重大优化：gRPC 长连接

1. 连接复用：所有心跳、配置推送、服务发现请求复用同一 gRPC 连接，减少 TCP 握手开销。
2. 连接级保活：gRPC 内置 Keepalive，连接断开（网络分区、进程崩溃）服务端立即感知，无需等待 15s/30s，实时性大幅提升。
3. 心跳简化：长连接稳定时，客户端只需少量心跳维持，甚至可依赖连接保活，降低心跳频率与带宽消耗。

---

五、常见问题与配置

1. 心跳超时被剔除

   • 原因：客户端卡顿、GC 过长、网络抖动、Nacos Server 负载高。
   • 优化：调大心跳间隔（如 10s）、不健康阈值（30s）、剔除阈值（60s）；升级 Nacos 2.x；优化客户端 JVM / 网络。

2. Nacos 控制台实例健康状态异常

   • 检查客户端是否正常发心跳（日志搜BeatReactor）。
   • 检查服务端lastBeatTime是否更新。
   • 核对实例类型（临时 / 永久）是否匹配预期。

3. 核心配置项（nacos.properties）

# 客户端心跳间隔（ms） nacos.naming.beat.interval=5000 # 服务端不健康阈值（ms） nacos.naming.beat.unhealthy.threshold=15000 # 服务端剔除阈值（ms） nacos.naming.beat.delete.threshold=30000

---

六、总结

• 临时实例：客户端主动 5s 心跳 → 服务端 15s 不健康、30s 剔除；2.x 用 gRPC 长连接，实时性与性能更好。
• 永久实例：服务端主动 TCP/HTTP 探活，不自动剔除Nacos。
• 心跳机制是 Nacos 服务发现可用性与一致性的基石，合理配置可平衡实时性与稳定性。