我也是醉了，Eureka 延迟注册还有这个坑！

Eureka 有个延迟注册的功能，也就是在服务启动成功之后不立刻注册到 Eureka Server，而是延迟一段时间再去注册，这样做的主要目的是因为虽然服务启动成功了，可能还有一些框架或者业务的代码没有初始化完成，可能会导致调用的报错，所以需要延迟注册。

但是发现，然并卵啊，好像这个延迟注册并没有生效，也是开始了排查之路。

延迟注册

首先，延迟注册的功能主要依赖这两个参数，​​eureka.client.initial-instance-info-replication-interval-seconds​​​代表第一次初始化延迟注册的时间间隔，​​eureka.client.instance-info-replication-interval-seconds​​则代表后续同步注册的时间间隔。

eureka.client.initial-instance-info-replication-interval-seconds=40 //默认40秒
eureka.client.instance-info-replication-interval-seconds=30 //默认30秒

我们从源码先来看是怎么做到延迟注册的，先看 ​​DiscoveryClient​​​ 的 ​​initScheduledTasks​​ ，这里创建了同步注册到 Eureka Server 的定时任务。

之后调用 ​​start​​ 方法创建定时任务，并且延迟 40 秒执行，也就是我们达到的延迟注册的效果。

默认的第一次注册，也就是延迟注册的时间是 40 秒，之后每 30 秒会同步注册信息。

默认的第一次注册，也就是延迟注册的时间是 40 秒，之后每 30 秒会同步注册信息。

看起来他存在两个调用，第一个是​​registerHealthCheck​​​，当存在这个健康检查什么玩意儿的时候就会去调用​​onDemandUpdate​​。

经过排查我们发现，只要配置了​​eureka.client.healthcheck.enabled=true​​​，就会创建 ​​HealthCheckHandler​​​的实例出来，默认情况下他是​​false​​的，所以应该是对我们没有影响的。

这里需要特别说明一下 ​​eureka.client.healthcheck.enabled ​​​的作用，默认 Eureka 根据心跳来决定应用的状态，如果是这个属性配置成 ​​true​​的话，则是会根据 Spring Boot Actuator 来决定，而不是心跳了。

比如我们可以实现 ​​HealthIndicator​​​接口，自己写一个​​Controller​​来动态改变服务的状态

@RestController
public class ControllerTest {
    @Autowired
    private HealthChecker healthChecker;

    @RequestMapping("/change")
    public String test(Boolean flag){
        healthChecker.setUp(new AtomicBoolean(flag));
        return "success";
    }

}

实现​​HealthChecker​​，这样会发现启动、下线服务 Eureka Server 的状态不会变成 Down，只有通过调用接口手动改变应用状态 Server 的状态才会发生改变，大家可以自行测试。

@Component
public class HealthChecker extends EurekaHealthIndicator implements HealthIndicator {
    private AtomicBoolean up = new AtomicBoolean(true);

    public HealthChecker(EurekaClient eurekaClient, EurekaInstanceConfig instanceConfig, EurekaClientConfig clientConfig){
        super(eurekaClient, instanceConfig, clientConfig);
    }

    @Override
    public Health health(){
        if(up.get()){
            return Health.up().build();
        }else{
            return Health.down().build();
        }
    }

第二个问题

第一个问题我们找到了，发现他不是导致我们问题的根因，于是继续排查。

发现第二个调用，在​​DiscoveryClient​​注册了状态事件变更的监听，如果状态发生变更，也会去调用 onDemandUpdate ，影响延迟注册的效果。

这里存在一个配置项​​onDemandUpdateStatusChange​​​，默认是​​true​​，所以应该是他没错了。

进入​​StatusChangeListener​​，找到了一个调用。

就是通过​​setInstanceStatus​​方法触发的事件通知。

这里存在 6 个调用，一一排查，通过源码找啊找，最终定位到服务启动自动装配的地方，在这里去修改服务状态为 ​​UP​​，然后触发事件通知，启动 ​​start​​ 方法调用​​register​​方法。

继续调用，修改应用为上线​​UP​​状态。

由此我们知道，只要服务启动成功，就会触发事件通知，所以这个基本上是启动成功立刻就会去注册到 Eureka Server，这就会导致延迟注册的失效，从启动日志也能直观的看到这个效果。

验证

为了验证我的猜想，我把这两个配置同时配置成​​false​​，并且把延迟注册的时间调整到非常大。

eureka.client.healthcheck.enabled=false
eureka.client.onDemandUpdateStatusChange=false
eureka.client.initial-instance-info-replication-interval-seconds=9999999 //默认40秒
eureka.client.instance-info-replication-interval-seconds=999999 //默认30秒

但是，但是！！！

发现过了几十秒之后，还是注册到 Server 了，真的是醉了。。。

那就继续看吧。

再看下注册方法，可能不止一个地方存在调用，我们发现果然如此，有 3 个地方都调用了注册方法。

第一个调用在​​DiscoveryClient​​注入的时候，这个看了下，​​clientConfig.shouldEnforceRegistrationAtInit()​​默认是​​false​​，方法不会进来，不管他了。

那么继续看第二个调用，第二个调用你看​​renew​​方法，这一看我们就知道了，这不就是心跳吗？！

发送心跳如果返回​​NOT_FOUND​​，就会去注册了啊。

感觉已经接近真相了，去找下 Server 心跳的源码，根据调用的路径找到源码位于​​InstanceResource​​中。

可以看到第一次注册的时候从注册表拿到的实例信息是空的，所以直接返回了 false，就会返回 NOT FOUND 了。

看​​registry.renew​​方法，最终会调用到​​AbstractInstanceRegistry​​中，初始化的时候注册表​​registry​​肯定没有当前实例的信息，所以拿到是空的，返回了false，最终就返回了​​NOT_FOUND​​。

因此，虽然我们把这两个参数都设置成了​​false​​，但是由于心跳默认 30 秒一次，所以最终我们发现配置的超级大的延迟注册的时间并没有完全生效。

总结

OK，到此，延迟注册不生效的原因找到了，我们做一个总结。

默认情况下，配置了延迟注册的时间并不会生效，因为事件监听默认是​​true​​，服务启动之后就会立刻注册到 Eureka Server。

如果需要延迟注册生效，必须 ​​eureka.client.healthcheck.enabled ​​​、​​eureka.client.onDemandUpdateStatusChange​​​ 都为​​false​​。

即便我们把所有途径都封死了，但是发送心跳的线程仍然会去注册，所以这个延迟注册的时间最多也不会超过 30 秒，即便配置的延迟时间超过 30 秒。

OK，到此为止，结束，我是艾小仙，欢迎拍砖。

文章转载自公众号：艾小仙