Nacos源码与原理 04，Nacos 心跳机制与服务剔除：源码层面吃透服务健康管理-编程阁

服务注册与发现是微服务架构的核心基石，而服务健康管理则是保障服务发现可靠性的关键 —— 只有实时感知服务实例的存活状态，才能避免流量转发到故障节点，确保微服务集群的稳定性。Nacos 作为主流的服务注册中心，其内置的心跳机制（服务实例保活）与服务剔除（故障实例清理）构成了完整的服务健康管理体系，二者协同工作实现了服务实例状态的精准感知与自动化治理。本文将从核心设计逻辑出发，深入 Nacos 源码层面，拆解心跳机制的实现流程、服务剔除的执行原理，以及二者的联动逻辑，让你从根上理解 Nacos 服务健康管理的底层逻辑。

一、核心设计：心跳机制与服务剔除的协同逻辑

在深入源码前，先建立 Nacos 服务健康管理的整体认知，核心围绕客户端主动保活、服务端定时检测、故障实例延迟剔除三大核心设计，二者的协同逻辑可概括为：

心跳机制：服务实例（客户端）注册到 Nacos 服务端后，会按照固定频率主动发送心跳包（本质是实例状态刷新请求），告知服务端 “自身存活”，服务端接收到心跳后，更新该实例的最后心跳时间，维持实例的健康状态；
服务剔除：Nacos 服务端启动独立的定时任务，周期性扫描所有服务实例，对比实例的最后心跳时间与当前时间，若超出心跳超时阈值，则判定实例为不健康状态；若不健康状态持续超出剔除阈值，则将该实例从服务列表中剔除，避免被服务消费者发现；
核心阈值：两个关键配置支撑整个流程（默认值可通过 Nacos 配置文件修改）：
- 心跳间隔：客户端默认5 秒发送一次心跳；
- 心跳超时阈值：服务端默认15 秒（3 倍心跳间隔）未收到心跳，标记实例为不健康；
- 剔除阈值：服务端默认30 秒（6 倍心跳间隔）不健康实例，执行剔除操作。

简单来说：心跳是客户端的 “保活动作”，剔除是服务端的 “故障清理动作”，超时阈值是二者的联动标尺，这种设计既避免了网络抖动导致的误判，又能及时清理真正的故障实例。

二、心跳机制源码解析：客户端主动保活的实现流程

Nacos 心跳机制的核心实现在客户端侧（nacos-client 模块），服务端仅负责接收心跳并更新状态，整体流程为：实例注册成功 → 启动心跳定时任务 → 周期性发送心跳包 → 服务端更新最后心跳时间。

2.1 核心入口：实例注册成功后触发心跳任务

服务实例通过NacosNamingService完成注册后，会立即触发心跳任务的启动，核心入口在com.alibaba.nacos.client.naming.NacosNamingService#registerInstance方法，关键源码片段如下：

// 服务实例注册核心方法 @Override public void registerInstance(String serviceName, String groupName, Instance instance) throws NacosException { // 1. 实例注册前置处理（分组、命名空间等） String groupedServiceName = NamingUtils.getGroupedName(serviceName, groupName); // 2. 核心注册逻辑：调用服务端注册接口 namingClientProxy.registerService(groupedServiceName, instance); // 3. 注册成功后，启动心跳保活任务（核心！） if (instance.isEphemeral()) { // 临时实例才会走心跳机制，持久化实例不触发 BeatReactor beatReactor = nacosNamingService.getBeatReactor(); BeatInfo beatInfo = buildBeatInfo(groupedServiceName, instance); beatReactor.addBeatInfo(groupedServiceName, beatInfo); } }

关键要点：

Nacos 分为临时实例（ephemeral=true，默认）和持久化实例（ephemeral=false），仅临时实例触发心跳机制，持久化实例由用户手动维护状态；
心跳任务的核心管理类是BeatReactor，负责心跳任务的添加、启动和销毁。

2.2 心跳任务核心管理：BeatReactor 类

BeatReactor是客户端心跳机制的核心管理类，位于com.alibaba.nacos.client.naming.beat包下，其核心作用是通过线程池管理所有服务实例的心跳定时任务，关键源码如下：

public class BeatReactor { // 心跳任务线程池（核心线程数默认CPU核心数） private final ScheduledExecutorService executorService; // 存储心跳任务：key=服务名+实例ID，value=心跳定时任务 private final Map<String, ScheduledFuture<?>> beatFutureMap = new ConcurrentHashMap<>(); // 构造方法：初始化线程池 public BeatReactor(NacosNamingService nacosNamingService) { this.executorService = Executors.newScheduledThreadPool( Runtime.getRuntime().availableProcessors(), new ThreadFactory() { @Override public Thread newThread(Runnable r) { Thread thread = new Thread(r, "nacos-beat-thread"); thread.setDaemon(true); // 守护线程，避免阻塞应用退出 return thread; } } ); } // 添加并启动心跳任务：核心方法 public void addBeatInfo(String serviceName, BeatInfo beatInfo) { String key = buildKey(serviceName, beatInfo.getIp(), beatInfo.getPort()); // 先取消已存在的心跳任务，避免重复 cancelBeatInfo(key); // 启动定时心跳任务：延迟0秒执行，每隔beatInfo.getPeriod()秒执行一次 ScheduledFuture<?> future = executorService.scheduleAtFixedRate( new BeatTask(beatInfo, nacosNamingService), 0, beatInfo.getPeriod(), TimeUnit.MILLISECONDS ); beatFutureMap.put(key, future); } // 取消心跳任务（实例注销时调用） public void cancelBeatInfo(String key) { ScheduledFuture<?> future = beatFutureMap.remove(key); if (future != null) { future.cancel(false); } } }

关键要点：

心跳任务基于定时线程池（ScheduledExecutorService）实现，采用守护线程，避免因心跳任务未结束导致应用无法正常退出；
心跳执行策略：延迟 0 秒立即执行第一次心跳，后续按照固定周期（默认 5 秒）执行，确保实例注册后快速完成首次保活；
维护beatFutureMap映射表，实现心跳任务的精准管理（添加、取消），避免同一实例重复创建心跳任务。

2.3 心跳执行核心：BeatTask 任务类

BeatTask是实现Runnable接口的心跳任务执行类，位于com.alibaba.nacos.client.naming.beat包下，其run()方法是每次心跳的具体执行逻辑，核心职责是向 Nacos 服务端发送心跳请求，关键源码如下：

public class BeatTask implements Runnable { private final BeatInfo beatInfo; // 心跳信息（服务名、IP、端口、心跳周期等） private final NacosNamingService nacosNamingService; @Override public void run() { try { // 核心：发送心跳请求到服务端 boolean result = nacosNamingService.getNamingClientProxy().sendBeat(beatInfo); if (!result) { // 心跳发送失败：重新注册实例（避免因服务端重启导致实例信息丢失） Instance instance = beatInfo.buildInstance(); nacosNamingService.registerInstance( beatInfo.getServiceName(), NamingUtils.getGroupName(beatInfo.getServiceName()), instance ); } } catch (Exception e) { NAMING_LOGGER.error("Send beat to server error, beatInfo:{}", beatInfo, e); } } }

心跳核心动作：sendBeat(beatInfo)方法，该方法会向 Nacos 服务端发送HTTP POST 请求（默认），请求路径为/nacos/v1/ns/instance/beat，携带的核心参数包括：服务名、实例 IP、端口、最后心跳时间、实例状态等。

2.4 服务端心跳处理：更新最后心跳时间

Nacos 服务端接收到客户端心跳请求后，核心处理逻辑在InstanceController类的beat方法（位于com.alibaba.nacos.naming.controllers包），无复杂业务逻辑，仅做两件事：

从请求参数中解析出实例信息，找到对应的服务实例；
更新该实例的lastBeatTime（最后心跳时间）为当前系统时间，并将实例状态维持为UP（健康）；
返回心跳响应结果（成功 / 失败），供客户端判断是否需要重新注册。

核心源码片段（服务端）：

@PostMapping("/beat") public ObjectNode beat(HttpServletRequest request) throws Exception { // 1. 解析心跳请求参数 BeatInfo beatInfo = parseBeatInfo(request); // 2. 找到对应的服务和实例 Service service = serviceManager.getService(NamespaceUtil.getNamespaceId(request), beatInfo.getServiceName()); Instance instance = service.getInstance(beatInfo.getIp(), beatInfo.getPort()); // 3. 核心：更新最后心跳时间 if (instance != null) { instance.setLastBeatTime(System.currentTimeMillis()); instance.setHealthy(true); // 标记为健康状态 } // 4. 构建并返回响应 ObjectNode result = JacksonUtils.createEmptyJsonNode(); result.put(SUCCESS, true); return result; }

关键结论：心跳机制的核心工作量在客户端，服务端仅做轻量级的状态更新，这种设计分散了服务端压力，适合大规模微服务集群部署。

三、服务剔除源码解析：服务端故障实例的自动化清理

服务剔除是 Nacos服务端侧的核心功能，由独立的定时任务完成，核心设计是 **“先标记不健康，再延迟剔除”**，避免因网络抖动、临时网络故障导致的误剔除，整体流程为：启动剔除定时任务 → 周期性扫描所有实例 → 筛选超时实例 → 标记不健康 / 执行剔除 → 同步剔除结果。

3.1 核心入口：服务端启动时初始化剔除任务

Nacos 服务端启动时，会通过NamingModule完成核心组件的初始化，其中就包括服务剔除定时任务，核心管理类是ExpiredInstanceCleaner（过期实例清理器），位于com.alibaba.nacos.naming.core包下，是服务剔除的核心类。

3.2 剔除任务核心：ExpiredInstanceCleaner 类

ExpiredInstanceCleaner是服务端服务剔除的核心类，其核心作用是通过定时线程池周期性执行实例扫描和剔除逻辑，默认扫描周期为 5 秒（与客户端心跳间隔一致），关键源码如下：

@Component public class ExpiredInstanceCleaner { // 服务管理核心类：维护所有服务和实例信息 @Autowired private ServiceManager serviceManager; // 剔除任务线程池 private ScheduledExecutorService executorService; // 服务端启动后初始化：启动剔除定时任务 @PostConstruct public void init() { this.executorService = Executors.newSingleThreadScheduledExecutor( new ThreadFactory() { @Override public Thread newThread(Runnable r) { Thread thread = new Thread(r, "nacos-expired-instance-cleaner"); thread.setDaemon(true); return thread; } } ); // 启动定时任务：延迟0秒执行，每隔5秒扫描一次（默认周期） executorService.scheduleAtFixedRate( this::cleanExpiredInstances, 0, Constants.DEFAULT_CLEAN_INTERVAL, // 默认5秒，可配置 TimeUnit.MILLISECONDS ); } // 核心方法：扫描并清理过期实例 private void cleanExpiredInstances() { try { // 遍历所有命名空间下的所有服务 for (String namespaceId : serviceManager.getAllNamespaceIds()) { for (Service service : serviceManager.getServices(namespaceId).values()) { // 仅处理临时实例（持久化实例不自动剔除） if (service.isEphemeral()) { cleanExpiredInstanceForService(service); } } } } catch (Exception e) { NAMING_LOGGER.error("Clean expired instances error", e); } } }

关键要点：

服务剔除仅针对临时实例（与心跳机制一致），持久化实例不会被自动剔除，符合 Nacos 实例设计规范；
扫描周期默认 5 秒，与客户端心跳间隔一致，确保快速感知实例心跳超时；
依赖ServiceManager类（Nacos 服务端核心类），维护所有命名空间、服务、实例的映射关系，是实例扫描的基础。

3.3 核心剔除逻辑：cleanExpiredInstanceForService 方法

cleanExpiredInstanceForService是服务剔除的核心业务方法，实现了 “超时判断 → 标记不健康 → 延迟剔除” 的完整逻辑，也是 Nacos 避免误剔除的关键，核心源码如下：

private void cleanExpiredInstanceForService(Service service) { long currentTime = System.currentTimeMillis(); // 获取服务下的所有实例列表 List<Instance> instances = service.getAllInstances(); for (Instance instance : instances) { // 计算实例心跳超时时间：当前时间 - 最后心跳时间 long beatTimeout = currentTime - instance.getLastBeatTime(); // 1. 心跳超时（默认15秒）：标记为不健康 if (beatTimeout > service.getMetaData().getBeatTimeout() || !instance.isHealthy()) { if (instance.isHealthy()) { instance.setHealthy(false); // 标记为不健康 NAMING_LOGGER.info("Instance {}:{} of service {} is marked as unhealthy, beat timeout:{}ms", instance.getIp(), instance.getPort(), service.getName(), beatTimeout); // 发布实例状态变更事件，通知其他组件（如服务发现、配置中心） eventPublisher.publishEvent(new InstanceStatusChangedEvent(service, instance)); } // 2. 不健康状态持续超时（默认30秒）：执行剔除 long unhealthyDuration = currentTime - instance.getLastBeatTime(); if (unhealthyDuration > service.getMetaData().getExpireTimeout()) { // 从服务实例列表中移除 service.removeInstance(instance.getIp(), instance.getPort(), instance.getClusterName()); NAMING_LOGGER.info("Instance {}:{} of service {} is expired, unhealthy duration:{}ms", instance.getIp(), instance.getPort(), service.getName(), unhealthyDuration); // 发布实例剔除事件，同步到集群其他节点（集群部署时） eventPublisher.publishEvent(new InstanceDeletedEvent(service, instance)); } } } }

核心剔除流程拆解（最关键的部分）：

步骤 1：心跳超时判断，标记实例为不健康

判断标准：当前时间 - 最后心跳时间 > 心跳超时阈值（默认15秒）；
动作：将实例的healthy属性设为false，并发布InstanceStatusChangedEvent状态变更事件；
关键作用：此时实例仅被标记为不健康，并未从服务列表中剔除，服务消费者会感知到实例状态为不健康，不再将流量转发到该实例，但实例信息仍保留在服务端。

步骤 2：不健康状态持续超时，执行实例剔除

判断标准：当前时间 - 最后心跳时间 > 剔除阈值（默认30秒）；
动作：调用service.removeInstance()方法，将实例从服务的实例列表中永久移除，并发布InstanceDeletedEvent剔除事件；
关键作用：实例被彻底剔除后，服务消费者将无法再发现该实例，彻底避免流量转发到故障节点。

步骤 3：集群同步（集群部署场景）

Nacos 服务端集群部署时，实例状态变更和剔除事件会通过Raft 协议同步到集群所有节点，确保所有节点的服务实例列表一致，避免集群节点状态不一致导致的服务发现异常。

3.4 核心阈值配置：可自定义修改

上述剔除逻辑中的心跳超时阈值和剔除阈值，并非硬编码，而是通过 Nacos 服务端配置文件（nacos/conf/application.properties）自定义配置，默认配置如下：

# 心跳超时阈值：默认15秒（3倍心跳间隔） nacos.naming.instance.beat.timeout=15000 # 剔除阈值：默认30秒（6倍心跳间隔） nacos.naming.instance.expire.timeout=30000 # 剔除任务扫描周期：默认5秒 nacos.naming.clean.interval=5000

可根据业务场景调整：比如网络不稳定的环境，可适当增大阈值，避免误剔除；对可用性要求极高的环境，可适当减小阈值，加快故障实例清理。

四、心跳与剔除的联动关键：核心阈值的设计逻辑

Nacos 中心跳间隔、心跳超时阈值、剔除阈值的默认倍数关系（1:3:6）是经过工程实践验证的，其设计逻辑直接决定了心跳与剔除的联动效果，核心设计思路为：

心跳间隔（5 秒）：兼顾保活实时性和客户端压力，5 秒的间隔既可以快速保活，又不会因频繁发送请求导致客户端网络 / CPU 压力过大；
心跳超时阈值（15 秒 = 3×5 秒）：允许客户端2 次心跳发送失败（网络抖动、临时 GC 停顿等），避免因单次网络故障导致实例被误标记为不健康；
剔除阈值（30 秒 = 6×5 秒）：允许实例5 次心跳发送失败，在标记为不健康后，仍保留 15 秒的 “缓冲期”，若缓冲期内实例恢复心跳（网络恢复、实例重启），则会重新标记为健康，彻底避免误剔除。

联动效果示例：

正常实例：每 5 秒发送一次心跳，服务端持续更新lastBeatTime，实例始终保持健康状态；
网络抖动实例：某一次心跳发送失败，10 秒后恢复心跳，服务端更新lastBeatTime，实例仍健康；
临时故障实例：心跳发送失败持续 16 秒，服务端标记为不健康，消费者停止转发流量；20 秒后故障恢复，发送心跳，服务端重新标记为健康，消费者恢复流量；
永久故障实例：心跳发送失败持续 30 秒，服务端先标记为不健康，最终执行剔除，消费者彻底无法发现该实例。

五、核心总结

Nacos 服务健康管理的核心是 **“客户端主动心跳保活 + 服务端定时扫描剔除”** 的协同模式，从源码层面可提炼出 5 个核心结论：

实例类型区分：仅临时实例触发心跳和自动剔除，持久化实例由用户手动维护，这是 Nacos 实例设计的核心规范；
心跳机制核心：客户端通过BeatReactor管理心跳线程池，BeatTask周期性发送心跳请求，服务端仅轻量级更新lastBeatTime，分散服务端压力；
剔除机制核心：服务端通过ExpiredInstanceCleaner启动定时扫描任务，遵循 **“先标记不健康，再延迟剔除”** 逻辑，避免网络抖动导致的误剔除；
联动关键阈值：默认 1:3:6 的阈值比例（心跳间隔 5 秒、超时 15 秒、剔除 30 秒）是核心联动标尺，可根据业务场景自定义调整；
集群一致性：实例状态变更和剔除事件通过 Raft 协议同步到 Nacos 集群所有节点，确保集群状态一致。