I'm also drunk. Eureka delayed registration and this pit

Eureka There is a function of delaying registration , That is, after the service is successfully started, you do not immediately register to Eureka Server, It's about delaying registration for a while , The main purpose of this is because although the service is started successfully , There may be some framework or business code that has not been initialized , It may cause an error in the call , Therefore, registration needs to be delayed .

But found , But there are no eggs , It seems that this delayed registration does not take effect , It is also the beginning of the investigation .

Delay registration

First , The function of delayed registration mainly depends on these two parameters ,eureka.client.initial-instance-info-replication-interval-seconds Represents the time interval between the first initialization delay registration ,eureka.client.instance-info-replication-interval-seconds Represents the time interval of subsequent synchronous registration .

eureka.client.initial-instance-info-replication-interval-seconds=40 // Default 40 second 
eureka.client.instance-info-replication-interval-seconds=30 // Default 30 second 
 Copy code 

Let's start with the source code and see how to delay registration , First look at  DiscoveryClient  Of  initScheduledTasks , Here we create a synchronous registration to Eureka Server Scheduled tasks for .

Then call  start  Method to create a scheduled task , And delay 40 Seconds to perform , That is, we achieve the effect of delayed registration .

Default first registration , That is, the time to delay registration is 40 second , After every 30 Seconds will synchronize the registration information .

however , Even if we configure these two properties , It seems that there is no use for eggs , Next, we need to check why ？

The first question is

I found it in  InstanceInfoReplica  There is such a section in to terminate the current thread pool task , And directly call run The existence of methods , Guess failure is that the delayed task does not take effect due to his direct call , Because the direct call of this method leads to delayed registration, it has no effect at all .

It seems that he has two calls , The first is registerHealthCheck, When there is something about this health check, it will be called onDemandUpdate.

After investigation, we found that , Just configure eureka.client.healthcheck.enabled=true, Will be created  HealthCheckHandler An example of , By default, he is false Of , So it should have no impact on us .

Here's a special explanation  eureka.client.healthcheck.enabled  The role of , Default Eureka Determine the application status according to the heartbeat , If this attribute is configured as  true Words , According to Spring Boot Actuator To decide , Instead of the heartbeat .

For example, we can achieve  HealthIndicator Interface , Write one yourself Controller To dynamically change the state of the service

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

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

}
 Copy code 

Realization HealthChecker, In this way, you will find that the startup 、 Offline service Eureka Server The state of will not become Down, Only by calling the interface to manually change the application state Server The state of will change , You can test it yourself .

@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();
        }
    }

 Copy code 

The second question is

The first question we found , It is found that he is not the root cause of our problems , So continue the investigation .

Found the second call , stay DiscoveryClient Registered status event change listener , If the status changes , I will call onDemandUpdate , Affect the effect of delayed registration .

There is a configuration item onDemandUpdateStatusChange, The default is true, So he should be right .

Get into StatusChangeListener, Found a call .

It is through setInstanceStatus Method triggers event notification .

There is 6 Calls , One by one investigation , Find it through the source code , Finally, locate the place where the service starts automatic assembly , Modify the service status here to  UP, Then trigger the event notification , start-up  start  Method call register Method .

Continue to call , Modify the application to online UP state .

So we know , As long as the service starts successfully , Event notification will be triggered , So this is basically a successful start, and you will register to Eureka Server, This will lead to the invalidation of delayed registration , This effect can also be seen intuitively from the startup log .

verification

To test my guess , I configure these two configurations at the same time false, And adjust the delay of registration to a very large time .

eureka.client.healthcheck.enabled=false
eureka.client.onDemandUpdateStatusChange=false
eureka.client.initial-instance-info-replication-interval-seconds=9999999 // Default 40 second 
eureka.client.instance-info-replication-interval-seconds=999999 // Default 30 second 
 Copy code 

however , however ！！！

Dozens of seconds later , Or register to Server 了 , I'm really drunk ...

Then keep watching .

Look at the registration method , There may be calls in more than one place , We found that it was true , Yes 3 Registration methods are called in all places .

The first call is in DiscoveryClient At the time of Injection , Take a look at this ,clientConfig.shouldEnforceRegistrationAtInit() The default is false, Methods won't come in , He doesn't care .

Then continue to look at the second call , The second call you see renew Method , We know at a glance , This is the heartbeat ？！

Send heartbeat if it returns NOT_FOUND, I will go to register .

I feel close to the truth , Go find Server The source code of heartbeat , Find the source code according to the call path located at InstanceResource in .

You can see that the instance information obtained from the registry is empty when you register for the first time , So straight back to false, It will return NOT FOUND 了 .

see registry.renew Method , Will eventually be called to AbstractInstanceRegistry in , When initializing the registry registry There must be no information about the current instance , So it's empty , Back to false, Finally returned NOT_FOUND.

therefore , Although we set these two parameters to false, But because the heartbeat defaults 30 Seconds at a time , So we finally found that the configured super large delay registration time did not fully take effect .

summary

OK, Here we are , The reason why the delayed registration does not take effect has been found , Let's summarize .

By default , The delay registration time configured will not take effect , Because event monitoring defaults to true, After the service is started, it will register to Eureka Server.

If you need to delay the registration , must  eureka.client.healthcheck.enabled 、eureka.client.onDemandUpdateStatusChange  All for false.

Even if we block all the ways , But the thread that sends the heartbeat will still register , Therefore, the delay in registration will not exceed 30 second , Even if the configured delay time exceeds 30 second .