Eureka服务端源码流程梳理

一、简述

spring cloud三步走，一导包，二依赖，三配置为我们简化了太多东西，以至于很多东西知其然不知其所以然，了解底层实现之后对于一些问题我们也可以快速的定位问题所在。

spring cloud很多东西都是基于注解实现的，最开始接触的很迷，怎么一个注解就可以搞定这么多事情，那些配置是怎么加载到spring容器的？

了解springboot的都会知道在jar包里面一般都会都有一个spring.factories的配置文件，里面配置了很多配置类得路径，这里就是加载相关配置类得入口。

其次就是针对springcloud里面注解，一般来说在某个注解同级目录里面都会有xxxxxxxAutoConfiguration这样的配置类，里面会去初始化相关的bean，比如在EnableEurekaServer注解的同级目录就有EurekaServerAutoConfiguration这个玩意儿，而EurekaServerAutoConfiguration这个玩意儿就是配置在spring.factories里面的

二、、Eureka架构图及描述

 

 

 

1.服务注册(register)：Eureka Client会通过发送REST请求的方式向Eureka Server注册自己的服务，提供自身的元数据，比如ip地址、端口、运行状况指标的url、主页地址等信息。Eureka Server接收到注册请求后，就会把这些元数据信息存储在一个双层的Map中。
2.服务续约(renew)：在服务注册后，Eureka Client会维护一个心跳来持续通知Eureka Server，说明服务一直处于可用状态，防止被剔除。Eureka Client在默认的情况下会每隔30秒(eureka.instance.leaseRenewallIntervalInSeconds)发送一次心跳来进行服务续约。
3.服务同步(replicate)：Eureka Server之间会互相进行注册，构建Eureka Server集群，不同Eureka Server之间会进行服务同步，用来保证服务信息的一致性。
4.获取服务(get registry)：服务消费者（Eureka Client）在启动的时候，会发送一个REST请求给Eureka Server，获取上面注册的服务清单，并且缓存在Eureka Client本地，默认缓存30秒(eureka.client.registryFetchIntervalSeconds)。同时，为了性能虑，Eureka Server也会维护一份只读的服务清单缓存，该缓存每隔30秒更新一次。
5.服务调用：服务消费者在获取到服务清单后，就可以根据清单中的服务列表信息，查找到其他服务的地址，从而进行远程调用。Eureka有Region和Zone的概念，一个Region可以包含多个Zone，在进行服务调用时，优先访问处于同一个Zone中的服务提供者。
6.服务下线(cancel)：当Eureka Client需要关闭或重启时，就不希望在这个时间段内再有请求进来，所以，就需要提前先发送REST请求给Eureka Server，告诉Eureka Server自己要下线了，Eureka Server在收到请求后，就会把该服务状态置为下线（DOWN），并把该下线事件传播出去。
7.服务剔除(evict)：有时候，服务实例可能会因为网络故障等原因导致不能提供服务，而此时该实例也没有发送请求给Eureka Server来进行服务下线，所以，还需要有服务剔除的机制。Eureka Server在启动的时候会创建一个定时任务，每隔一段时间（默认60秒），从当前服务清单中把超时没有续约（默认90秒，eureka.instance.leaseExpirationDurationInSeconds）的服务剔除。
8.自我保护：既然Eureka Server会定时剔除超时没有续约的服务，那就有可能出现一种场景，网络一段时间内发生了异常，所有的服务都没能够进行续约，Eureka Server就把所有的服务都剔除了，这样显然不太合理。所以，就有了自我保护机制，当短时间内，统计续约失败的比例，如果达到一定阈值，则会触发自我保护的机制，在该机制下，Eureka Server不会剔除任何的微服务，等到正常后，再退出自我保护机制。自我保护开关(eureka.server.enable-self-preservation: false)

三、EurekaServer源码流程梳理图

首先推荐一个在线画图工具https://www.processon.com，按照流程图里面的类和方法去和源码对号入座。

 

 

四、服务端注册接口和注册列表获取接口（2019.05.03补充）

多级缓存设计思想：尽可能保证了内存注册表数据不会出现频繁的读写冲突问题，进一步保证对Eureka Server的大量请求，都是快速从纯内存走，性能极高

1.在拉取注册表的时候：
    首先从ReadOnlyCacheMap里查缓存的注册表。
    若没有，就找ReadWriteCacheMap里缓存的注册表。
    如果还没有，就从内存中获取实际的注册表数据。
2.在注册表发生变更的时候：
    会在内存中更新变更的注册表数据，同时过期掉ReadWriteCacheMap。
    此过程不会影响ReadOnlyCacheMap提供人家查询注册表。
    默认每30秒Eureka Server会将ReadWriteCacheMap更新到
    ReadOnlyCacheMap里
    默认每180秒Eureka Server会将ReadWriteCacheMap里是数据失效
   下次有服务拉取注册表，又会从内存中获取最新的数据了，同时填充 各级缓存。

 

存在的问题：

1.当我们eureka服务实例有注册或下线或有实例发生故障，内存注册表虽然会及时更新数据，但是客户端不一定能及时感知到，可能会过30秒才能感知到，因为客户端拉取注册表实例这里面有一个多级缓存机制

2.服务剔除的不是默认90秒没心跳的实例，剔除的是180秒没心跳的实例(eureka的bug导致)

 

/**
     * Renew the lease, use renewal duration if it was specified by the
     * associated {@link T} during registration, otherwise default duration is
     * {@link #DEFAULT_DURATION_IN_SECS}.
     */
    public void renew() {
        lastUpdateTimestamp = System.currentTimeMillis() + duration;

    }

 

加了两次duration值，com.netflix.eureka.lease.Lease#isExpired(long)

 

 

 /**
     * Checks if the lease of a given {@link com.netflix.appinfo.InstanceInfo} has expired or not.
     *
     * Note that due to renew() doing the 'wrong" thing and setting lastUpdateTimestamp to +duration more than
     * what it should be, the expiry will actually be 2 * duration. This is a minor bug and should only affect
     * instances that ungracefully shutdown. Due to possible wide ranging impact to existing usage, this will
     * not be fixed.
     *
     * @param additionalLeaseMs any additional lease time to add to the lease evaluation in ms.
     */
    public boolean isExpired(long additionalLeaseMs) {
        return (evictionTimestamp > 0 || System.currentTimeMillis() > (lastUpdateTimestamp + duration + additionalLeaseMs));
    }

 

 

 

流程图：