聊一聊nacos是如何进行服务注册的（三）

三、心跳机制源码剖析

心跳机制，就是客户端定时向服务端发送请求，告诉服务端 “我还活着” ，服务端就会知道这个服务实例仍然可用。

服务注册我们剖析完了，接下来回过头，来看看心跳机制的源码。

首先是构建了一个BeatInfo，就是一个心跳信息参数的封装，就不点进去看了，接下来，我们进入addBeatInfo方法。

这个方法就是通过BeatInfo构建一个BeatTask，然后扔到调度线程池，等待一定（默认是5s，你可以自己进去构建BeatInfo代码，这个参数默认是5s）时间之后执行，那么自然而然BeatTask就是心跳机制执行的逻辑，我们进入BeatTask代码。

BeatTask实现了Runable接口，所以我们直接看run方法的实现。

首先就是通过serverProxy发送一个http请求到服务端，服务端进行响应，其实这个过程就完成了跟服务端的心跳，接下来就是解析服务端的响应的数据了。根据服务端返回的不同的状态码进行判断，进行不同的操作。这里我们着重看一下这个响应码RESOURCE_NOT_FOUND （资源未找到）对应的操作

这段代码其实就是重新向服务端进行服务的注册。有人肯定会好奇，为什么发送心跳的时候，服务端会告诉客户端，该服务实例在服务端找不到？不是只有注册服务的时候才会去构建心跳么，按道理应该存在的？是的，这是正常的情况下，在正常情况下，客户端发送心跳，服务实例应该存在于服务端的，但是有些情况，比如说网络抖动的时候，因为网络的问题，客户端无法给服务端发送心跳，长时间服务端无法接收到客户端的心跳，此时服务端认为你的这个服务实例出问题了，这样服务端就会主动从服务注册表中剔除该服务实例，该服务实例就不存在服务端了。当客户端网络好了的话，那么此时会恢复跟服务端的心跳机制，就会出现服务找不到的现象，这种情况下只要重新注册一下就行了。

接下来有一行很重要的代码，我们继续往下看。

这行代码就是重新构建了一个BeatTask,，然后重新扔到调度线程池，等待nextTime之后执行。nextTime一般是BeatInfo的period，也就是默认是5s，但是有种情况，就是当发送心跳的实话，服务端可能会响应给客户端一个下一次发送心跳的时间间隔，此时就以nextTime就是服务端响应的时间，你可以自行查看nextTime的赋值情况。

通过这种形式，就实现了定时发送心跳的功能。当这次心跳完成之后，就会继续构建下一次心跳的任务，扔到调度线程池等待一定的时间之后执行，如此往复，就实现了定时发送心跳的机制。

这里的这个定时的机制其实大家可以学习一下，这个定时机制实现了变频的功能，所谓的变频就是定时任务执行的间隔是不固定的，这次任务的执行才决定下一次任务执行的时间，这样有一个好处就是在一些场景中，如果有的任务频繁失败，那么是不是可以考虑让下一次执行的任务时间拉长，减少资源的浪费，nacos在定时更新本地服务实例列表的缓存也使用到了这个机制。这种机制其实在很多框架，中间件都有使用。

总结

本文最开始介绍了NamingService接口的作用，通过这个接口就可以向服务端注册服务实例；接下来基于该接口，剖析了服务注册的源码，说白了就是发送http请求给服务端，然后服务端保存服务实例的数据；最后我们剖析了客户端的心跳机制，说白了就是构建BeatTask，定时(默认5s)向服务端发送请求。后面我会再写几篇文章，来剖析服务订阅、故障转移等机制以及nacos是如何整合springcloud的，包括注册中心和配置中心的整合源码剖析。

文章转自公众号：三友的java日记