一. 问题背景

昨天研究了Day2——Nacos自动服务注册原理（二），虽然知道了如何自动服务注册，但是nacos服务端会检测服务实例的健康状态，若实例不健康，则会将该实例剔除，这是心跳检测机制。因此今天继续研究，内容是心跳机制

二. 前言

心跳机制会在一个循环内发送更加多的url请求
关于本篇博客，还是推荐了解心跳机制的流程即可，不必纠结在源码实现细节，毕竟源码会因springboot的版本不同而不同。
本文将从nacos客户端、服务端来讲解自动服务注册的流程
前往gitee下载nacos客户端源码工程用来研究nacos自动服务注册的源码，前往nacos的github页面下载，用来启动nacos

三. 回顾

Day2——Nacos自动服务注册原理（二）

四. 客户端的心跳机制

客户端的心跳机制，可以叫做 心跳续约，而服务端的心跳机制可以叫做 健康检查。

首先从客户端的核心服务注册方法入手，如下：
在这里插入图片描述

解释：reactor设计模式是event-driven architecture的一种实现方式,处理多个客户端并发的向服务端请求服务的场景。

总结：schedule虽然只会执行一次；但是在BeatTask线程里面又再调用了schedule()方法，所以是无限循环

在这里插入图片描述

总结：客户端的心跳机制，其实也是发送http请求。但是底层是利用了一个线程池，开启一个线程去发送心跳。并且线程里面又再次调用了一次开启线程的方法。如果要对spring系统做扩展，实现心跳机制，那么我们可以直接仿照定义心跳线程任务的代码去实现

内容大概如下：

在这里插入图片描述

五. nacos服务端的心跳检测机制

5.1 理解service、instance、cluster（重要）

要了解服务端的心跳检测机制，必须要搞清楚service、instance、cluster之间的关系。先做一个了解，否则后面很难理解源码。

Service.java

public class Service extends xxx implements Record, RecordListener<Instances> {
    
    
	/**
	 * 省略其他无关内容
	 */
	
	private Map<String, Cluster> clusterMap = new HashMap<>();
}

解释：Service维护了一个名为clusterMap的Map。 Service实现了Record接口，RecordListener<Instances>，所以Service也是一个监听器，他对Instances有兴趣。

再了解Instances，如下：

public class Instances implements Record {
    
    
    // 省略其他无关代码
    
	private List<Instance> instanceList = new ArrayList<>();
}

解释：Instances维护了一个实例列表

Cluster.java

public class Cluster extends xxx implements Cloneable {
    
    
    // 持久化的实例
	@JsonIgnore
    private Set<Instance> persistentInstances = new HashSet<>();
    
    // 临时的实例
    @JsonIgnore
    private Set<Instance> ephemeralInstances = new HashSet<>();
    
    // 服务
	@JsonIgnore
    private Service service;

 	// 元数据
	private Map<String, String> metadata = new ConcurrentHashMap<>();
}