彻底搞懂Eureka——心跳发送源码探究

在DiscoveryClient里有这样一个方法：

在服务的启动时，会有一个服务的心跳包在这里发送出去，我们打个断点，看一下这部分心跳的逻辑，前面的代码我们先略过，直接跳到发送心跳的地方：

根据这个方法名，我们不难猜测，它应该是在后台通过定时触发的一个任务，我们进入这个方法：

在这里可以看到这个定时的任务不仅包含心跳，还有缓存的刷新，我们这部分先不看，继续往下走：

这里就和心跳有关系了，可以看出，在clientConfig.shouldRegisterWithEureka()为true的时候才会进来，
我们在服务注册中心的配置里对这一项指定了false：

而在eureka-client这里我们并没有指定这个值，所以它默认是true，我们继续往下走：

可以看到这里有一个renewalIntervalInSecs，值为30，也就是说30秒发一个请求。
继续往下看：

可以看到这里有个scheduler，也就是定时启动后台任务的，里面用到了 renewalIntervalInSecs，说明就是30秒启动一次。我们刚刚看到，其实还有一个叫expBackOffBound的属性，它是什么含义呢？
我们先进入到TimedSupervisorTask看一下：

这里有一个maxDelay，它是用刚刚的超时时间乘以expBackOffBound，因此这里的expBackOffBound就是用于计算最大延迟时间的。

但是这些属性都是和具体发送心跳包没关系的，我们再回到上面：

真正发送心跳包，是在这个HeartbeatThread()里面，我们点进去看看：

可以看到，它是实现了一个Runnable接口，然后再run方法里面实现心跳包，我们进入到这个renew()方法里看看：

通过这个方法名，我们看着好像是续约的意思，其实心跳和服务续约是一套相互作用的机制，这里的renew在客户端来说，它是发送了一个心跳，但是在服务端来说，它接受了这个心跳，就是完成了一次服务的续约。

这里我们看的是客户端的心跳逻辑，后续我们再探讨服务的续约逻辑。

这里和服务注册一样也是一层一层的嵌套，我们来看这里，它是嵌套了一个SessionedEurekaHttpClient，这里我们就不一层一层的过了，感兴趣的小伙伴自己debug看看这个流程，我们就直接走到最终的地方看看它的心跳包都发送了哪些内容：

这里我们直接进入到AbstractJerseyEurekaHttpClient#sendHeartBeat这个方法，
这里它是最后一层了，它的上层其实是JerseyApplicationClient：

其实服务注册也是一样的，都是一套机制，只有你搞懂了一个，看其他的流程其实举一反三很容易就通了。

我们看到这里第一行是定义了一个url：

这个url指定的是当前客户端的地址。
紧接着，下面构造了一个WebResource:

这里指定了当前注册中心的url，以及客户端的路径，还有一些当前实例状态等信息。
再往下看：

这里就把这些参数发送出去了：

可以看到返回的是200，说明已经发送成功了。
我们回到renew方法里:

这里返回的也是200，最后进行了返回：

走到这里，其实整个心跳发送的流程就已经完成了，看到这里感觉这个流程还是比较简单的。