我也是醉了，Eureka 延遲注冊還有這個(gè)坑！
Eureka 有個(gè)延遲注冊的功能，也就是在服務(wù)啟動成功之后不立刻注冊到 Eureka Server，而是延遲一段時(shí)間再去注冊，這樣做的主要目的是因?yàn)殡m然服務(wù)啟動成功了，可能還有一些框架或者業(yè)務(wù)的代碼沒有初始化完成，可能會導(dǎo)致調(diào)用的報(bào)錯(cuò)，所以需要延遲注冊。
但是發(fā)現(xiàn)，然并卵啊，好像這個(gè)延遲注冊并沒有生效，也是開始了排查之路。
延遲注冊
首先，延遲注冊的功能主要依賴這兩個(gè)參數(shù)，eureka.client.initial-instance-info-replication-interval-seconds?代表第一次初始化延遲注冊的時(shí)間間隔，eureka.client.instance-info-replication-interval-seconds則代表后續(xù)同步注冊的時(shí)間間隔。
eureka.client.initial-instance-info-replication-interval-seconds=40 //默認(rèn)40秒
eureka.client.instance-info-replication-interval-seconds=30 //默認(rèn)30秒
我們從源碼先來看是怎么做到延遲注冊的，先看 DiscoveryClient? 的 initScheduledTasks ，這里創(chuàng)建了同步注冊到 Eureka Server 的定時(shí)任務(wù)。
之后調(diào)用 start 方法創(chuàng)建定時(shí)任務(wù)，并且延遲 40 秒執(zhí)行，也就是我們達(dá)到的延遲注冊的效果。
默認(rèn)的第一次注冊，也就是延遲注冊的時(shí)間是 40 秒，之后每 30 秒會同步注冊信息。
但是，即便我們配置了這倆屬性，發(fā)現(xiàn)好像沒什么卵用，接下來我們要排查下到底是為啥捏？
第一個(gè)問題
我發(fā)現(xiàn)在 InstanceInfoReplica 中存在這樣一段終止當(dāng)前線程池任務(wù)，并且直接調(diào)用 run 方法的存在，猜測失效就是他直接調(diào)用導(dǎo)致延遲任務(wù)沒有生效，因?yàn)檫@個(gè)方法的直接調(diào)用導(dǎo)致延遲注冊壓根就沒效果嘛。
看起來他存在兩個(gè)調(diào)用，第一個(gè)是registerHealthCheck?，當(dāng)存在這個(gè)健康檢查什么玩意兒的時(shí)候就會去調(diào)用onDemandUpdate。
經(jīng)過排查我們發(fā)現(xiàn)，只要配置了eureka.client.healthcheck.enabled=true?，就會創(chuàng)建 HealthCheckHandler?的實(shí)例出來，默認(rèn)情況下他是false的，所以應(yīng)該是對我們沒有影響的。
這里需要特別說明一下 eureka.client.healthcheck.enabled ?的作用，默認(rèn) Eureka 根據(jù)心跳來決定應(yīng)用的狀態(tài)，如果是這個(gè)屬性配置成 true的話，則是會根據(jù) Spring Boot Actuator 來決定，而不是心跳了。
比如我們可以實(shí)現(xiàn) HealthIndicator?接口，自己寫一個(gè)Controller來動態(tài)改變服務(wù)的狀態(tài)
@RestController
public class ControllerTest {
@Autowired
private HealthChecker healthChecker;
@RequestMapping("/change")
public String test(Boolean flag) {
healthChecker.setUp(new AtomicBoolean(flag));
return "success";
}
}
實(shí)現(xiàn)HealthChecker，這樣會發(fā)現(xiàn)啟動、下線服務(wù) Eureka Server 的狀態(tài)不會變成 Down，只有通過調(diào)用接口手動改變應(yīng)用狀態(tài) Server 的狀態(tài)才會發(fā)生改變，大家可以自行測試。
@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();
}
}
第二個(gè)問題
第一個(gè)問題我們找到了，發(fā)現(xiàn)他不是導(dǎo)致我們問題的根因，于是繼續(xù)排查。
發(fā)現(xiàn)第二個(gè)調(diào)用，在DiscoveryClient注冊了狀態(tài)事件變更的監(jiān)聽，如果狀態(tài)發(fā)生變更，也會去調(diào)用 onDemandUpdate ，影響延遲注冊的效果。
這里存在一個(gè)配置項(xiàng)onDemandUpdateStatusChange?，默認(rèn)是true，所以應(yīng)該是他沒錯(cuò)了。
進(jìn)入StatusChangeListener，找到了一個(gè)調(diào)用。
就是通過setInstanceStatus方法觸發(fā)的事件通知。
這里存在 6 個(gè)調(diào)用，一一排查，通過源碼找啊找，最終定位到服務(wù)啟動自動裝配的地方，在這里去修改服務(wù)狀態(tài)為 UP?，然后觸發(fā)事件通知，啟動 start? 方法調(diào)用register方法。
繼續(xù)調(diào)用，修改應(yīng)用為上線UP狀態(tài)。
由此我們知道，只要服務(wù)啟動成功，就會觸發(fā)事件通知，所以這個(gè)基本上是啟動成功立刻就會去注冊到 Eureka Server，這就會導(dǎo)致延遲注冊的失效，從啟動日志也能直觀的看到這個(gè)效果。
驗(yàn)證
為了驗(yàn)證我的猜想，我把這兩個(gè)配置同時(shí)配置成false，并且把延遲注冊的時(shí)間調(diào)整到非常大。
eureka.client.healthcheck.enabled=false
eureka.client.onDemandUpdateStatusChange=false
eureka.client.initial-instance-info-replication-interval-seconds=9999999 //默認(rèn)40秒
eureka.client.instance-info-replication-interval-seconds=999999 //默認(rèn)30秒
但是，但是?。?！
發(fā)現(xiàn)過了幾十秒之后，還是注冊到 Server 了，真的是醉了。。。
那就繼續(xù)看吧。
再看下注冊方法，可能不止一個(gè)地方存在調(diào)用，我們發(fā)現(xiàn)果然如此，有 3 個(gè)地方都調(diào)用了注冊方法。
第一個(gè)調(diào)用在DiscoveryClient?注入的時(shí)候，這個(gè)看了下，clientConfig.shouldEnforceRegistrationAtInit()?默認(rèn)是false，方法不會進(jìn)來，不管他了。
那么繼續(xù)看第二個(gè)調(diào)用，第二個(gè)調(diào)用你看renew方法，這一看我們就知道了，這不就是心跳嗎？！
發(fā)送心跳如果返回NOT_FOUND，就會去注冊了啊。
感覺已經(jīng)接近真相了，去找下 Server 心跳的源碼，根據(jù)調(diào)用的路徑找到源碼位于InstanceResource中。
可以看到第一次注冊的時(shí)候從注冊表拿到的實(shí)例信息是空的，所以直接返回了 false，就會返回 NOT FOUND 了。
看registry.renew?方法，最終會調(diào)用到AbstractInstanceRegistry?中，初始化的時(shí)候注冊表registry?肯定沒有當(dāng)前實(shí)例的信息，所以拿到是空的，返回了false，最終就返回了NOT_FOUND。
因此，雖然我們把這兩個(gè)參數(shù)都設(shè)置成了false，但是由于心跳默認(rèn) 30 秒一次，所以最終我們發(fā)現(xiàn)配置的超級大的延遲注冊的時(shí)間并沒有完全生效。
總結(jié)
OK，到此，延遲注冊不生效的原因找到了，我們做一個(gè)總結(jié)。
默認(rèn)情況下，配置了延遲注冊的時(shí)間并不會生效，因?yàn)槭录O(jiān)聽默認(rèn)是true，服務(wù)啟動之后就會立刻注冊到 Eureka Server。
如果需要延遲注冊生效，必須 eureka.client.healthcheck.enabled ?、eureka.client.onDemandUpdateStatusChange? 都為false。
即便我們把所有途徑都封死了，但是發(fā)送心跳的線程仍然會去注冊，所以這個(gè)延遲注冊的時(shí)間最多也不會超過 30 秒，即便配置的延遲時(shí)間超過 30 秒。
