Nacos注册中心AP模式核心源码分析（单机模式）

---

概述

  Nacos注册表架构：
  Nacos中注册表是一个重要的概念，也是Nacos存储服务实例的数据结构，源码中体现在ServiceManager的serviceMap属性中。
例：

{
public = {
DEFAULT_GROUP@@stock-service = Service{
name=‘DEFAULT_GROUP@@stock-service’,
protectThreshold=0.0,
appName=‘null’,
groupName=‘DEFAULT_GROUP’,
metadata={}
}
}
}

1. 第一层 Map：Map<String, Map<String, Service>>
   • 键（String）：public → 代表命名空间（namespaceId）。
   • 值（Map<String, Service>） → 该命名空间下的所有服务。
2. 第二层 Map：Map<String, Service>
   • 键（String）：DEFAULT_GROUP@@stock-service
     • DEFAULT_GROUP：Nacos 中的 服务分组（Group）。
     • stock-service：具体的服务名称（Service Name）。
     • 拼接方式：groupName + “@@” + serviceName
3. Service 对象:

Service {
name=‘DEFAULT_GROUP@@stock-service’, // 服务唯一标识
protectThreshold=0.0, // 保护阈值（避免雪崩）
appName=‘null’, // 可能未指定应用名
groupName=‘DEFAULT_GROUP’, // 该服务所属分组
metadata={} // 额外的元数据（如 tags、扩展信息）
}

  基本组件及概念（服务相关）：

名词	解释
namespaceId（命名空间）	用于隔离不同环境的服务，如 public、test、prod。在 serviceMap 中，namespaceId 是最外层的键。
group（服务分组）	用于将服务进一步分类，例如 DEFAULT_GROUP。多个不同业务的同名服务可以通过 group 进行区分。
serviceName（服务名称）	标识一个具体的服务，例如 order-service、stock-service。
service	表示 Nacos 中的一个服务对象，包含 name、groupName、metadata 等信息。
instance（实例）	具体提供服务的实例，通常指某个 IP + 端口（如 192.168.1.10:8080）。
weight（权重）	用于负载均衡，不同实例可以有不同的权重，影响流量分配比例。
protectThreshold（保护阈值）	用于设置 服务降级，防止雪崩效应，取值范围 0~1。
healthy（健康状态）	表示服务实例是否健康，通常由 心跳检测 维护。

  基本组件及概念（配置管理相关）：

名词	解释
DataId	配置项的唯一标识，如 application-dev.yml，类似于 文件名。
Group（配置分组）	配置的分组，默认是 DEFAULT_GROUP，可以用于区分不同的配置类别。
Namespace（命名空间）	用于隔离不同环境（如 dev、test、prod），可作用于 配置 和 服务。
Content（配置内容）	具体的配置信息，如 YAML、JSON 或 Properties 格式的内容。
Snapshot（快照）	本地缓存的配置快照，在网络异常时可以使用。

一、客户端启动主线流程源码分析

1.1、客户端与Spring Boot整合

  在Spring Boot项目中，如果需要使用Nacos注册中心，需要引入：

		<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId></dependency>

  引入了依赖后，Nacos将通过Spring Boot 自动装配机制，完成整合：
  在spring.factories中，与自动装配关系最为密切的是NacosDiscoveryAutoConfiguration，其主要工作是向Spring 容器中设置了三个Bean:

• NacosServiceRegistry（Nacos 服务注册中心实例）：创建 Nacos 服务注册中心，用于将 Spring Boot 应用注册到 Nacos。负责和 Nacos 交互，比如 注册/注销 服务。
• NacosRegistration（Nacos 服务注册信息）：封装当前服务实例的注册信息。
• NacosAutoServiceRegistration（Nacos 自动服务注册器）：自动注册 Spring Boot 服务到 Nacos。

  其中NacosAutoServiceRegistration最为核心，NacosAutoServiceRegistration的继承体系结构：
  实现了ApplicationListener接口，监听WebServerInitializedEvent类型的事件，调用onApplicationEvent方法：
  最终调用到register方法：
  这里的ServiceRegistry正是NacosDiscoveryAutoConfiguration中注册的NacosServiceRegistry，getRegistration获取到的是NacosRegistration。也就是调用Nacos 服务注册中心实例的register方法，去注册Nacos 服务注册信息：

1.2、注册实例（服务注册）

  在register方法中，首先会去通过getNacosInstanceFromRegistration方法，初始化一些实例的信息：
  然后调用namingService的registerInstance方法进行实例注册：
  请求路径：/nacos/v1/ns/instance，reqApI的底层，通过HttpClient发送请求：

1.3、发送心跳

  在调用namingService的registerInstance方法进行实例注册时，会有一个判断条件，如果实例是非永久的，就会去开启一个发送心跳的定时任务。
  实例默认就是非永久的。
  初始化发送心跳定时任务：  BeatTask实现了Runnable接口，真正执行的是其中的run方法，run方法中的sendBeat，同样是去利用HttpClient去发送请求，路径是/nacos/v1/ns/instance/beat。
  sendBeat方法会返回clientBeatInterval，也就是客户端心跳间隔的时间，并且将该时间间隔作为定时任务的延迟时间，继续递归执行该任务，持续向服务端发送心跳。

1.4、拉取服务端实例列表（服务发现）

  除了向服务端注册自身的信息外，客户端还有服务发现的请求NacosNamingService#getAllInstances：这里的subscribe属性默认为true，会进入hostReactor的getServiceInfo方法：
  在getServiceInfo方法中，首先会尝试从缓存中获取值：
  如果获取不到，则调用updateServiceNow方法：
  同样是通过Http请求，访问/nacos/v1/ns/instance/list，去从服务端获取所有的服务实例：
  最后还会调用scheduleUpdateIfAbsent方法
  去开启一个延迟的定时任务：
  默认时延1s：
  任务对象UpdateTask的run方法完成的逻辑：定时拉取服务端的最新数据，并且更新到本地。

二、服务端接收请求主线流程源码分析

  客户端无论是注册实例，发送心跳，还是从服务端拉取实例列表，实际上都是通过http请求，远程调用服务端InstanceController的接口，使用的是restFul请求风格：
请求路径为：/v1/ns/instance

2.1、接收注册请求

  接收注册请求，调用的是register方法，在方法中，首先会生成namespaceId和serviceName以及校验serviceName的合法性，并且从请求中还原出Instance然后调用registerInstance方法进行注册：
  在registerInstance方法中，主要完成了三件事：

• 初始化注册表
• 获取服务信息
• 将实例添加到服务
  

2.1.1、初始化注册表

  createServiceIfAbsent方法，首先会去尝试通过命名空间Id和服务名称去获取Service。如果实例类型是永久实例，那么getService这一行代码就可以获取到，反之在启动过程中获取不到，会进入if分支，去初始化Service。

  Service初始化完成后，执行putServiceAndInit的逻辑，在该方法中，同样做了两件事：

• 填充注册表
• 初始化检测心跳定时任务

  putService是填充注册表的方法，首先通过双检锁模式，对注册表进行初始化，这里初始化的是外层的map，key就是当前的命名空间。如dev，check，prod等。（外层map的value为何是跳表的结构？）。然后会去初始化内层的map，key是同一类型微服务的分组

---

  init方法中，会初始化两个定时任务。

• clientBeatCheckTask：服务端监听心跳定时任务，在客户端的启动过程中，会去向服务端通过延迟定时任务的方式发送自身的心跳。
• HealthCheckTask：在entry.getValue().init();中被初始化，是定期主动健康检查定时任务。
  
    其中服务端监听心跳定时任务，超过15s没有检测到心跳，就会标记该实例的状态为非健康状态
    超过30s没有检测到心跳，就会去删除该实例：
  

2.1.2、获取服务信息

  在getService方法中，首先会通过命名空间ID，获取注册表外层map的value。然后根据服务名称，获取具体的实例。

2.1.3、将实例添加到服务

  在addInstance方法中，主要也完成了三件事：

• 根据传入的ephemeral属性，生成一个全局唯一的key。
• 将传入的 Instance 添加到 service 的实例列表中。
• 将实例信息写入服务端内存中。

---

  consistencyService.put(key, instances);实际执行的是DelegateConsistencyServiceImpl的put方法：
  在put方法中，首先会解析之前生成的key，获取对应的实例，然后调用其put方法：
  在这里获取到的是ephemeralConsistencyService非永久。

  调用的实际是ephemeralConsistencyService子类DistroConsistencyServiceImpl的put方法：
  单机模式下重点关注onPut方法，是将key和instance实例放入一个阻塞队列中：
  上述所有的操作，都是服务端启动完成后，接收到客户端启动时发送的注册请求从而执行的全部流程。 所以为什么每次都是先要启动服务端再启动客户端的原因？

2.2、接收获取服务实例请求

  客户端在发起获取所有服务实例的请求后，实际调用的是服务端的：
  在doSrvIpxt方法中，首先会去调用getService方法，获取当前命名空间下的所有实例，然后调用service的srvIPs方法：

2.3、接收发送心跳请求

  客户端在发起上报心跳的请求后，实际调用的是服务端的：
  如果服务端发现实例不存在，则会走注册的逻辑：
  否则开启一个定时任务对客户端发送的心跳信息进行处理：
  在ClientBeatProcessor的run方法中，循环所有的实例，并且更新心跳时间

2.4、接收删除实例请求

  当某个实例30s没有向服务端发送心跳时，客户端就会发送删除实例请求：
  最终实际调用的是ServiceManager#updateIpAddresses的instanceMap.remove(instance.getDatumKey());方法。

三、服务端启动主线流程源码分析

  在2.1、接收注册请求的最后，服务端会将实例的信息存入一个阻塞队列，而Notifier实现了Runnable，必然有一个run方法需要执行，run方法的主要作用是消费阻塞队列的数据，然后真正地去执行将客户端的注册信息存入服务端内存的操作。，那么run方法是何时被执行的呢？
  Notifier是DistroConsistencyServiceImpl的一个属性，随着DistroConsistencyServiceImpl的实例化而被实例化，真正将其通过线程池运行的在于DistroConsistencyServiceImpl的init方法。该方法上加入了@PostConstruct注解，是在spring启动的流程中执行的。
  Nacos的服务端实际上也是一个Spring Boot项目，在启动的过程中，会去向线程池submit一个Notifier任务，从而执行其中的run方法的逻辑。再去仔细观察一下run方法，被设置成了死循环，那么**这样是否会造成cpu资源的浪费？可能很多人会想，如果我只启动了服务端，而一直没有启动客户端，那么代码会在for循环中无限空转。实际这种情况是不会发生的，因为tasks属性的数据结构是阻塞队列。**当队列为空时，则会陷入阻塞，不会一直循环。
  这里的handle方法，会进入if (action == DataOperation.CHANGE)的分支。
  最终调用的是Service的onChange方法，然后调用updateIPs:
  在updateIPs中有两个关键的逻辑：

• 将临时实例写入内存
• 主动向客户端推送发布事件

---

  将临时实例写入内存，应用了写时复制的思想。具体是将原有的内存结构复制一份，待操作完成后，再写回注册表的属性中。
  虽然牺牲了一定的实时性（其他线程读取到的是旧的数据），但是降低了锁的粒度，提高了并发。

---

  在将临时实例写入内存后，还会主动发布事件，告知客户端服务端最新的注册表内容，实际调用的是PushService的方法：
  而PushService又实现了ApplicationListener<ServiceChangeEvent>，所以最终由该类的onApplicationEvent方法执行逻辑：给服务端发送udp请求，将服务变更发送给订阅的客户端。

小结：单机模式下的定时任务

组件	任务名称	触发频率	作用
客户端（SDK）	发送心跳（BeatReactor）	默认 5 秒	客户端定期向 Nacos 发送 心跳，保持实例存活状态
客户端（SDK）	服务列表拉取（HostReactor）	默认 10 秒	客户端定期拉取注册中心中的 服务列表，用于本地缓存
客户端（SDK）	配置监听（ClientWorker）	10 秒（长轮询）	监听 配置变更，若有变化，则更新本地缓存
客户端（SDK）	负载均衡（LoadBalancer）	10 秒	轮询 可用实例，选择最优的实例进行调用
服务端（Nacos Server）	处理客户端心跳（ClientBeatCheckTask）	5 秒	检查服务实例是否仍然存活，如果未收到心跳，则标记为 不健康 或移除
服务端（Nacos Server）	临时实例清理（ExpireInstanceTask）	定期执行	清除失效的 临时实例（即 ephemeral=true）
服务端（Nacos Server）	持久化实例同步（PersistentServiceTask）	30 秒	将持久化实例（ephemeral=false）的状态写入数据库
服务端（Nacos Server）	配置变更通知（ConfigChangeNotifier）	实时触发	监听 配置变更，并通知所有监听的客户端
服务端（Nacos Server）	配置清理（ConfigCleanupTask）	10 分钟	清理过期或无用的 历史配置
服务端（Nacos Server）	权限数据同步（AuthRefreshTask）	5 分钟	刷新权限信息，确保权限策略有效
服务端（Nacos Server）	Raft 协议日志清理（RaftLogCleanupTask）	10 分钟	清理过期的 Raft 日志，保持数据一致性

---