文章目录
一. 问题背景
昨天研究了Day2——Nacos自动服务注册原理(二),虽然知道了如何自动服务注册,但是nacos服务端会检测服务实例的健康状态,若实例不健康,则会将该实例剔除,这是心跳检测机制。因此今天继续研究,内容是心跳机制
二. 前言
- 心跳机制会在一个循环内发送更加多的url请求
- 关于本篇博客,还是推荐了解心跳机制的流程即可,不必纠结在源码实现细节,毕竟源码会因springboot的版本不同而不同。
- 本文将从nacos客户端、服务端来讲解自动服务注册的流程
- 前往gitee下载nacos客户端源码工程用来研究nacos自动服务注册的源码,前往nacos的github页面下载,用来启动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<>();
}
总结:了解大概即可,后面还会更深入研究
5.2 服务端的心跳机制
我们从服务端的服务注册的核心方法InstanceController#register()
切入。
总结:nacos服务端的心跳检测也是使用了定时任务开启线程来处理(具体实现未深入研究,但是源码其实就是根据各种状态去判断客户端是否健康),服务端处理服务注册的过程中用了service,clusterMap,instances这三级关系来维护服务与它的实例们。
六. 总结
- nacos的客户端心跳机制是开启了线程定时发送心跳信息给服务端。
- nacos的服务端心跳机制也是开启线程定时监听客户端的各种状态从而判断是否健康。
- nacos用了service,clusterMap,instances来维护服务与它的实例们的关系。