上篇文章分析到Nacos客户端心跳机制，那么本文接上文Nacos-客户端心跳机制
，继续分析Nacos服务端心跳机制。通过上文我们知道客户端发送心跳是通过下面这个接口完成的！Nacos服务端心跳机制我们可以分为两部分来分析，第一部分是心跳续约，第二部分是心跳检测
切入Nacos服务端代码！
入口InstanceController.beat
这部分主要就是得到request中的数据，取出后为核心逻辑做准备！
标注1的哪行代码是通过心跳发来的客户端数据，到Nacos服务中判断这个发送心跳的客户端是否存在！
标注2的那块代码是判断如果Nacos服务端中如果没有当前心跳的客户端信息那么Nacos服务端自动把这个客户端信息注册上去！
注意:这里是防止Nacos客户端/Nacos服务端由于网络波动或者是其他问题，导致服务端以为客户端已经挂掉，将其客户端节点剔除，但是客户端实际上没有挂掉，那么客户端从新发送心跳后，Nacos服务端就会通过标注2的逻辑从新将其客户端节点注册上去！
Nacos服务端心跳处理
Nacos服务端心跳处理就是通过这行代码进入的!
service.processClientBeat(clientBeat);
processClientBeat方法
这里HealthCheckReactor.scheduleNow(clientBeatProcessor);实际上就是抛出去了一个延迟线程任务！这里延迟时间是0，那么可以理解为这里就是开启了一个异步线程处理心跳续约逻辑
其真正逻辑存在ClientBeatProcessor对象中的run方法
ClientBeatProcessor.run
这里的核心逻辑就是刷新当前心跳时间！那么也就完成当前发送心跳的客户端心跳续约的处理
入口铺垫
这块逻辑挺有意思的，不是很好找到入口在哪！上面我们分析心跳续约的时候有一块如下逻辑
就是Nacos发现上报心跳的Nacos客户端节点不存在了，那么就会通过上面代码从新注册，那么心跳检测开启的大门就要从这里说起！这里有两种情况，一种是通过心跳检查进入，另一种是客户端服务注册的时候进入！绝大部分情况是从注册的时候开启的！
切入ServiceManager的registerInstance方法
这里其他代码就不分析了，主要分析是开启心跳检测！
继续深入createEmptyService方法
一杆子捅到底，切入createServiceIfAbsent方法
核心代码就是这两个圈起来的，第一块是根据名称空间和服务名得到service的，另一个是开启心跳检测，那个根据名称空间和服务名获取service的逻辑没什么好看的，我们进入开启心跳检测的代码
深入putServiceAndInit(service);
这个init就是整个心跳检测的主入口！
进入init
这里有开启了一个以固定延迟时间进行的线程任务！我们找到run方法！
ClientBeatCheckTask.run
第一块是判断是否超时(15秒)，如果有超过15秒那么将实例设置为非健康状态
这里橙色部分的就是检测时间15秒触发的！
如果操过30秒那么将这个实例直接剔除！那么以上就完成了整个心跳检测的逻辑！
说明
这里我没有看源码的时候大致以为是Nacos服务端有一个定时任务，按照一定的周期定时检查Nacos客户端心跳上报时间，但是第一次看源码逻辑的时候，看到服务端心跳接口的时候以为是为每个上报心跳的服务开启一个定时任务检查心跳，知道看第二遍的时候，通过
这行代码才得知，Nacos服务端是按在名称空间+服务名来创建定时任务做心跳检查的！
拿走不谢！
