【源码分析】2020.3.8笔记——eureka服务端的集群同步和服务剔除（Hoxton版）

集群同步

我们知道一般来说springcloud微服务项目中的节点都是需要做集群部署的，而其中eureka的服务端自然也需要做集群处理。既然存在集群，那么集群之中的节点必然需要集群同步，保证一致性。

在前面服务注册时就说过了，对于eureka服务端的集群同步操作都是由PeerAwareInstanceRegistryImpl这个类负责的

eureka服务端中最需要集群同步操作的是服务注册的信息，其中同步的流程图如下

下面是对于服务注册的集群同步操作方法

这个方法就是集群同步的入口，其中很多方法都会调用这个方法，这个很好理解，一旦集群中的服务发生改变都需要集群同步，下面就是调用这个方法的其他操作，可以看出包括服务剔除、服务注册、服务续约等等。

这个方法的参数前面都是关于需要同步的服务信息，最后一个布尔参数isReplication表示是否来自集群同步的意思，它可以帮助我们跳出递归调用。

其中下面这段代码就是遍历所有的eureka服务端（除自身）同步服务信息，至于这里的其他eureka服务端的信息在哪里获得的，这就是我们自己通过配置文件配置的。

其他eureka服务端节点信息

其中将服务信息同步给其他节点的方法就在replicateInstanceActionsToPeers中实现的，基本的逻辑就是将服务发送的请求转发给其他服务端节点。

那么问题来了，其他的服务端节点接收到请求后同样也会调用replicateToPeers这个集群同步方法，但是显然我们已经同步过了，就不需要再次同步，那么如何跳出这个循环呢？关键就是其中的一个参数isReplication，前面也介绍了，这个参数代表这个请求是否来自集群同步，显然除了第一次服务主动发送请求给服务端的那一次之外，后面的同步请求都是属于集群同步请求的。所以后面的请求都会进入这个if跳出循环。

服务剔除

eureka服务端中的服务剔除是通过一个定时任务去执行，这个定时任务在初始化就开启了，下面就是定时任务，这个定时任务是AbstractInstanceRegistry的内部类。

其中剔除的具体逻辑在evict方法中

首先判断是否进入了自我保护机制

下面的代码将所有的客户端实例拿出来并判断是否过期，如果过期了，就放到一个过期服务实例的集合中。

下面就是判断时候过期的方法，简单来说就是判断当前时间时候大于最后操作时间加上过期时间，不过这里加上的过期时间其实是多余的，之前我们就在服务注册的时候发现最后操作时间已经是加上过期时间的，所以这里其实加上了两倍的过期时间。

在筛选出所有的过期客户端实例后服务端并不会立刻将所有的客户端剔除，而是会先判断是否剔除的数量超过了自我保护机制的阈值，如果超过了，并不会全部剔除，而是只剔除自我保护机制的阈值数量的客户端，剩下的会等下一次剔除时再处理。