彻底搞懂Eureka——服务续约源码探究

在上篇文章《彻底搞懂Eureka——心跳发送源码探究》我们已经研究过了服务发送的流程，我们也知道，心跳发送与服务续约是一种相互作用的机制，client发送一个心跳，对应的服务端就要接受这个心跳完成一次服务的续约对吧。

我们来看一下InstanceResource这个类：

当客户端发送完心跳以后，服务端会在这个renewLease方法里面接受这个请求，接受一个PUT的httpMeathod，它的属性都是通过@QueryParam注入进来的
我们往下走一步：

可以看到这里有一个isFromReplicaNode属性，它的含义就是说你的心跳包来自哪里，这里因为它是由euraka-client发送过来的，并不是由其他注册中心同步过来的，所以这里的值是false，这个我们后续探讨注册中心高可用架构的时候，再给大家详细解释一下吧。
我们继续往下走，可以看到又来到了这个renew方法，跟进去看看：

我们看到，这个方法里有三个入参：
第一个参数appName是EUREKA-CLIENT。
第二个入参是serverId，这个serverId是ip、appName以及端口号的组合，所以说serverId在服务治理的生命周期中是唯一的。
第三个参数是isReplication，我们刚刚提到过了。

我们打个断点就往下走走看：

这里有一个applications，可以看到这个集合里目前只有一个服务。
如果我们对接了很多的服务方，那这个集合是很大的。

再往下看：

这段代码里就是一个for循环，当这个List中的application的Name和传入的appName相等的时候，把这个服务下面的所有instance拿到，这个instance就是服务提供者，比如我这个eureka-client有五个机器，那么这个instance就是五个，然后for循环这些instance，判断id和传进来的serverId是否相同，如果相同就为该instance进行续约。

紧接着：

它又通过了一个publishEvent发布了一个已经续约的Event，
最后它又到了这个renew的方法：

跟进去看看：

看到这里的renew又走了一个父类的renew方法，看下面有一个replicationToPeers方法，它指的是如果你的高可用注册中心如果有多个中心节点，那就需要向Peer同步，

我们继续把断点走进这个父类的renew方法里：

我们可以看到，在这个registry里面通过appName获取到了所有的租约，因为我们目前只注册了一个节点，那这里面也只有一个。
往下走：

这里通过serverId拿到租约。
再往下：

如果租约为空，计数器记录下来，返回false
我们这里不是空，就通过getHolder获取instance的信息。

然后这里通过三个参数判断instanceStatus：

我们这里获取到的是UP的status，继续往下看：

如果Instance的状态是UNKOWN，那RENEW_NOT_FOUND这个计数器又会加一。
再看下面：

它这里又会判断这个instance和当前这个instance的状态是否相同，如果不相同就会通过setStatusWithoutDirty这个方法重新设置status，我们可以点击去看下：

这里是synchronized修饰的一个方法。

我们再继续往下走：

可以看到来到了一个renewLastMin，这个就表示每过去一分钟记录一个读到的请求。
在下面，又来到了一个renew方法，我们点进去看看：

这里只是更新了一个lastUpdateTimestamp的属性。
我们再往后走：

就回到了我们的PeerAwareInstanceRegistryImpl#renew这个方法。
这里因为我们就一个注册中心，这个地方我们就先略过。再往下走回到我们的renewLease方法：

可以看到，这里的isSuccess已经是true了，也就是说，这里上面的renew流程已经是成功了，那如果不成功的话，就给客户端返回了一个NOT_FOUNT的状态，由客户端处理后续的容错流程。

我们再往下走：

这里看上面有个注释，说的是我们是否需要针对这个lastDirtyTimestamp做同步。
这个lastDirtyTimestamp是由发送方发送过来的，也就是说上一次和服务端出现脏数据的时间戳，这里脏数据也就是说服务不同步，和服务注册中心由于某些原因造成不同步的最近一次的时间。

这里如果lastDirtyTimestamp不为空，并且我们设置的shouldSyncWhenTimestampDiffers是否要做同步，如果这个属性也是true，就继续往下走后面的流程：

我们跟进这个validateDirtyTimestamp方法里：

首先获取到instanceInfo，然后判断是否不为空，然后判断lastDirtyTimestamp不为空，并且传入的lastDirtyTimestamp与当前在服务端保存的lastDirtyTimestamp是不一样的。
那如果满足上述条件，就说明有一段时间不同步的情况。
我们大体看一下这段代码：

首先判断当前传入的这个时间如果晚于服务端保存的时间。这就说明客户端可能出现了某些问题没有通知到服务端，这可能是网络通信切断了等等原因，那这时候就直接返回一个NOT_FOUND的状态，重新让它注册。

当客户端收到这个NOT_FOUND指令后，就会重新走一次注册流程。
这是一种情况，我们再来看下第二种情况：

这种情况就是服务端的这个时间大于客户端发来的这个时间，这时候就会有两个判断：
这个if里首先判断如果是从其他注册中心同步过来的，就会返回一个CONFLICT的状态。
如果是由客户端发过来的那就什么也不用管，就是成功的状态。

最后，我们再回到renewLease方法里：

可以看到我们的response对象已经构造出来了。
下面还有一个判断条件：

这段代码我们可以先不管，这里涉及到注册中心的高可用架构相关的属性，所以我们这里是不会走到这个判断里的。

最后：

我们就直接返回了response，到这里就完成了整个服务续约的流程