📖 本章预览
本章为预览版本，展示部分核心内容。完整内容包含详细源码解析、实战代码和面试要点，加入知识星球即可解锁全部章节。
第七章：Naming 健康检查机制
7.1 两套健康检查机制
Nacos 的健康检查分为两大类，对应两种实例类型：
| 实例类型 | 检查方式 | 触发方 | 适用场景 |
|---|---|---|---|
| 临时实例（2.x） | gRPC 连接即心跳 | 连接层自动管理 | gRPC SDK 客户端 |
| 临时实例（1.x 兼容） | HTTP 心跳上报 | 客户端定时发送 | HTTP 旧版客户端 |
| 持久实例 | 服务端主动探测 | 服务端定时执行 | 数据库、中间件等 |
7.2 临时实例——gRPC 连接即心跳（2.x 主力）
2.x 架构下，临时实例的健康检查极其简洁：gRPC 连接活着 = 实例健康，连接断了 = 实例摘除。
客户端 SDK ←── gRPC 长连接 ──→ Nacos Server
│
├── 连接正常 → 实例健康
│
└── 连接断开 → ConnectionManager.unregister()
→ 通知 ClientManager
→ 销毁 Client 对象
→ 所有实例自动摘除
不需要额外的心跳线程、不需要超时检测。gRPC 框架自带的 keepalive 机制保证了连接的活性检测。
7.3 临时实例——HTTP 心跳检查（1.x 兼容）
对于通过 HTTP 注册的旧版客户端（IpPortBasedClient），仍然需要传统的心跳检查。
7.3.1 ClientBeatCheckTaskV2——入口
public class ClientBeatCheckTaskV2 extends AbstractExecuteTask {
private final IpPortBasedClient client;
private final InstanceBeatCheckTaskInterceptorChain interceptorChain;
@Override
public void doHealthCheck() {
Collection<Service> services = client.getAllPublishedService();
for (Service each : services) {
HealthCheckInstancePublishInfo instance =
(HealthCheckInstancePublishInfo) client.getInstancePublishInfo(each);
interceptorChain.doInterceptor(
new InstanceBeatCheckTask(client, each, instance));
}
}
}
7.3.2 拦截器链——层层过滤
InstanceBeatCheckTaskInterceptorChain
│
├── InstanceBeatCheckResponsibleInterceptor
│ 问：这个实例归我管吗？（Distro 分片）
│ hash(clientId) % nodeCount == myIndex → 归我管，继续
│
├── InstanceEnableBeatCheckInterceptor
│ 问：这个实例启用了心跳检查吗？
│
├── ServiceEnableBeatCheckInterceptor
│ 问：这个服务启用了心跳检查吗？
│
└── 通过所有拦截器后 → 执行实际检查
为什么需要 ResponsibleInterceptor？ 假设集群有 3 个节点，通过 Distro 分片，每个实例只被一个节点检查，避免重复。
🔒 解锁完整内容
本章剩余内容需要解锁后查看
以上仅为本章部分预览内容，完整内容包含更多深度源码解析、实战代码和面试要点。
加入知识星球你将获得：
- ✅ 全部 17 章完整内容 + 持续更新
- ✅ 配套源码 + 实战项目
- ✅ 一对一答疑 + 面试辅导
- ✅ 简历优化 + 内推机会
📚 本章完整目录
以下为本章完整目录结构，加入知识星球即可解锁全部内容。