Eureka重点原理解析

前言

带着问题学习，事半功倍。本文将对如下几个问题进行总结说明：

1、EurekaServer端服务注册的流程和设计模式

2、Eureka服务续约的bug

3、EurekaClient的启动流程

4、client启动后是往一个server注册还是多个server遍历注册

5、EurekaServer的三级缓存

6、一个EurekaClient宕机后，其他EurekaClient最晚多长时间后才会不再往这个宕机的服务发起请求？

Eureka在Spring Cloud组件全家桶中，处于很核心的位置，从去年格林尼治版的更新说明中就能知道，更新日志截图如下，netflix的其他组件均进入维护状态，不再添加新特性，但Eureka不包括在内。个人观点，一方面Eureka的功能实现相对比较复杂，不好随便改动，再就是位置关键，改动后影响范围广。

下面进入正文。注：Spring Cloud版本Hoxton SR1，eureka-core 1.9.13

正文 

一、EurekaServer端服务注册的流程和设计模式

服务端的入口类如下所示，不带s的类中是对单个服务/实例的操作，带s的是集合操作。服务注册入口在ApplicationResource中。

服务注册方法是ApplicationResource#addInstance，可以看到经过一些必要的判断后调用了注册方法，注意因为该请求是从客户端发起的，isReplication为空，所以register方法的第二个参数是false。

         registry.register(info, "true".equals(isReplication));
         return Response.status(204).build();  // 204 to be backwards compatible
     }

追踪进入PeerAwareInstanceRegistryImpl类的register方法，如下，该方法先调用了父类的注册方法，然后调的往其他服务扩散注册信息的方法replicateToPeers。

     @Override
     public void register(final InstanceInfo info, final boolean isReplication) {
         int leaseDuration = Lease.DEFAULT_DURATION_IN_SECS;
         if (info.getLeaseInfo() != null && info.getLeaseInfo().getDurationInSecs() > 0) {
             leaseDuration = info.getLeaseInfo().getDurationInSecs();
         }
         super.register(info, leaseDuration, isReplication);
         replicateToPeers(Action.Register, info.getAppName(), info.getId(), info, null, isReplication);
     }

继续跟进到父类AbstractInstanceRegistry，在父类的register方法中完成了对真实服务列表ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry的维护 （方法太长就不贴出来了）。

至此完成了服务注册，共涉及到三个类：ApplicationResource、PeerAwareInstanceRegistryImpl、AbstractInstanceRegistry。前两个类的register方法都是做了一些自己的事情外加调用父类的register，一个典型的责任链模式应用，一个类只负责自己的事情，然后调用上一层的方法，如果需加一个功能，只需要在对应位置加一层继承关系即可，对原有功能无侵入。

二、Eureka服务续约的bug

打开Lease租债器类，看到renew方法和isExpired方法：

 public void renew() {
         lastUpdateTimestamp = System.currentTimeMillis() + duration;

     }

 public boolean isExpired(long additionalLeaseMs) {
         return (evictionTimestamp > 0 || System.currentTimeMillis() > (lastUpdateTimestamp + duration + additionalLeaseMs));
     }

续约方法每次调用都将最后修改时间变为当前时间+有效期（默认90s），而判断是否失效的方法比较的是当前时间和最后修改时间+有效期，这就导致有效期加了两次，即一个服务过了两倍的有效期时间之后才会被服务端判定为到期。其实这个事情在isExpired方法的注释中可以看到说明：

     /**
      * 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.
      */

三、EurekaClient的启动流程

Eureka客户端只需要引入依赖加上配置，便可以自动实现服务注册。客户端的功能主要包括三部分：启动时的服务注册、服务定时续约、服务列表缓存定时更新。

客户端启动的逻辑都在DiscoveryClient的构造方法中，com.netflix.discovery.DiscoveryClient#DiscoveryClient，方法代码太长，就不粘贴代码了，只描述下流程：

初始化两个ThreadPoolExecutor：服务续约和更新缓存；

从server拉取注册信息com.netflix.discovery.DiscoveryClient#fetchRegistry；

com.netflix.discovery.DiscoveryClient#register服务注册；

启动定时器。

四、client启动后是往一个server注册还是多个server遍历注册

客户端在执行register方法注册服务时，采用装饰器模式对httpClient进行处理，其中有一个是RetryableEurekaHttpClient，在该类的execute方法中对客户端配置文件中配置的serviceUrl进行了遍历，如果第一个注册请求处理成功了，则不再重试，否则遍历serviceUrl重试。具体可见com.netflix.discovery.shared.transport.decorator.RetryableEurekaHttpClient#execute方法。

五、EurekaServer的三级缓存

eureka的服务端为了提高服务列表维护和读取的一致性与可用性，对服务列表的查看设置了三级缓存，入口为com.netflix.eureka.resources.ApplicationsResource#getContainers。在该方法中调用了

ResponseCacheImpl#getGZIP方法获取缓存，如下：

 public byte[] getGZIP(Key key) {
         Value payload = getValue(key, shouldUseReadOnlyResponseCache);
         if (payload == null) {
             return null;
         }
         return payload.getGzipped();
     }

继续跟进getValue方法：

 Value getValue(final Key key, boolean useReadOnlyCache) {
         Value payload = null;
         try {
             if (useReadOnlyCache) {
                 final Value currentPayload = readOnlyCacheMap.get(key);
                 if (currentPayload != null) {
                     payload = currentPayload;
                 } else {
                     payload = readWriteCacheMap.get(key);
                     readOnlyCacheMap.put(key, payload);
                 }
             } else {
                 payload = readWriteCacheMap.get(key);
             }
         } catch (Throwable t) {
             logger.error("Cannot get value for key : {}", key, t);
         }
         return payload;
     }

可以看到，这里有两个map：readOnlyCacheMap（只读缓存）、readWriteCacheMap（读写缓存），再加上AbstractInstanceRegistry#registry真实数据，总共三级map缓存。

它们使用的规则如下：只读缓存每隔30s定时从读写缓存中更新最新数据，读写缓存与真实数据是同步的，它的存在是为了减少对真实数据的读取。额外要注意，在eureka server中，读取操作用的写锁，而注册修改下线操作用的读锁。

通过三级缓存，Eureka在并发吞吐量的基础上做到了最大程度的数据一致性。这种设计思路值得学习。

六、一个EurekaClient宕机后，其他EurekaClient最晚多长时间后才会不再往这个宕机的服务发起请求？

先说下上面三级缓存场景可能产生的延迟：如果在服务端的真实服务列表中，一个服务已经被剔除了，此时最多过多长时间其他客户端才能得知到此消息？

客户端每隔30s去服务端拉取一次缓存 + 服务端只读缓存每30s同步一次读写缓存的数据，即最长需要60s后客户端才能得到最新的服务端列表数据。

再来看宕机的情况，即如果一个服务宕机，其他服务最多会经过多长时间才不会再往这个服务发送请求？

先看服务端，因为有上面第二项说的bug存在，默认服务端经过90s*2才会剔除该宕机服务，该剔除的定时器每60s执行一次，再加上上面说的客户端更新缓存的60s延迟，再加上ribbon的60s缓存，所以总计是：

90*2 + 60 + 60 + 60 = 360s，即最长可能需要6分钟。

小结

Eureka的定时器真TM多。。。