Nacos 核心源码学习笔记

Nacos 作为微服务架构中核心的服务注册发现与配置中心，其底层设计与实现逻辑对理解微服务治理至关重要。本文从源码入口、服务注册、心跳检测、集群一致性四个核心维度，梳理 Nacos 关键机制的实现原理。

一、源码入口与初始化机制

1. 源码入口定位

分析 Nacos 源码时，可通过启动脚本定位启动类，或直接聚焦服务发现核心 Jar 包（如 nacos-discovery）。其初始化逻辑依赖 Spring Boot SPI 机制，核心流程如下：

• 在 META-INF/spring.factories 中配置自动配置类（如服务发现场景的 NacosDiscoveryAutoConfiguration）；
• 启用 Jar 包时，Spring 容器通过 @EnableAutoConfiguration 触发自动配置类加载；
• 自动配置类初始化 NacosServiceRegistry（服务注册）、NacosDiscoveryClient（服务发现）等核心组件，并向 Nacos 服务端发起请求，建立基础通信链路。

二、服务注册流程与高并发设计

1. 核心注册流程

1. 客户端封装服务信息（IP、端口、服务名等）为 Instance 对象，发送注册请求至服务端；
2. 服务端接收请求后，先将 Instance 存入 BlockingQueue 阻塞队列，作为请求缓冲层；
3. 后台专用线程从队列中持续取出 Instance，写入注册表（嵌套 Map 结构：serviceName -> cluster -> Instance）。

2. 高并发支撑策略

• 阻塞队列缓冲：通过“生产者-消费者”模式解耦请求接收与数据写入，避免直接操作注册表导致的锁竞争；
• 读写分离架构：
  • 写操作（注册/更新）：拷贝目标服务的 Instance 集合（Set），在副本中修改，不影响原集合；
  • 读操作（服务发现）：直接从原 Set 读取数据，保证查询无阻塞；
• 原子替换：修改完成后，用新 Set 原子替换原 Set，兼顾数据一致性与并发效率。

三、心跳检测机制

1. 客户端心跳发送

服务实例注册成功后，客户端默认每 5 秒 向 Nacos 服务端发送心跳请求，携带实例 ID 等唯一标识信息。

2. 服务端健康检查

服务端维护每个实例的“最后心跳时间”，通过时间差判断实例健康状态：

• 若 当前时间 - 最后心跳时间 > 15 秒：标记实例为不健康（healthy = false），服务发现时不返回该实例；
• 若 当前时间 - 最后心跳时间 > 30 秒：直接从注册表中移除实例，视为服务下线。

四、集群 CP 模式与 Raft 协议

1. CP 模式适用场景

通过配置 nacos.core.protocol=cp 开启 CP 模式，适用于数据一致性要求极高的场景（如金融领域服务注册）。

2. Raft 协议核心作用

服务注册、实例状态变更等操作会触发 Raft 协议，保障集群数据一致性：

• Leader 选举：集群节点通过 Raft 选举产生 Leader，由 Leader 统一处理客户端请求并协调数据同步；
• 日志复制：Leader 将数据变更记录为日志，同步至所有 Follower 节点，待多数节点确认后才提交变更（如写入注册表）；
• 基于 Raft 协议，Nacos 集群在节点故障、网络分区时仍能保证数据一致，实现高可靠服务治理。