建站
咨詢
售后
建站咨詢
新聞中心
Eureka 有個延遲注冊的功能，也就是在服務啟動成功之后不立刻注冊到 Eureka Server，而是延遲一段時間再去注冊，這樣做的主要目的是因為雖然服務啟動成功了，可能還有一些框架或者業(yè)務的代碼沒有初始化完成，可能會導致調用的報錯，所以需要延遲注冊。
創(chuàng)新互聯(lián)服務項目包括福州網站建設、福州網站制作、福州網頁制作以及福州網絡營銷策劃等。多年來，我們專注于互聯(lián)網行業(yè)，利用自身積累的技術優(yōu)勢、行業(yè)經驗、深度合作伙伴關系等，向廣大中小型企業(yè)、政府機構等提供互聯(lián)網行業(yè)的解決方案，福州網站推廣取得了明顯的社會效益與經濟效益。目前，我們服務的客戶以成都為中心已經輻射到福州省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！
但是發(fā)現(xiàn)，然并卵啊，好像這個延遲注冊并沒有生效，也是開始了排查之路。
延遲注冊
首先，延遲注冊的功能主要依賴這兩個參數(shù)，eureka.client.initial-instance-info-replication-interval-seconds?代表第一次初始化延遲注冊的時間間隔，eureka.client.instance-info-replication-interval-seconds則代表后續(xù)同步注冊的時間間隔。
eureka.client.initial-instance-info-replication-interval-seconds=40 //默認40秒
eureka.client.instance-info-replication-interval-seconds=30 //默認30秒
我們從源碼先來看是怎么做到延遲注冊的，先看 DiscoveryClient? 的 initScheduledTasks ，這里創(chuàng)建了同步注冊到 Eureka Server 的定時任務。
之后調用 start 方法創(chuàng)建定時任務，并且延遲 40 秒執(zhí)行，也就是我們達到的延遲注冊的效果。
默認的第一次注冊，也就是延遲注冊的時間是 40 秒，之后每 30 秒會同步注冊信息。
但是，即便我們配置了這倆屬性，發(fā)現(xiàn)好像沒什么卵用，接下來我們要排查下到底是為啥捏？
第一個問題
我發(fā)現(xiàn)在 InstanceInfoReplica 中存在這樣一段終止當前線程池任務，并且直接調用 run 方法的存在，猜測失效就是他直接調用導致延遲任務沒有生效，因為這個方法的直接調用導致延遲注冊壓根就沒效果嘛。
看起來他存在兩個調用，第一個是registerHealthCheck?，當存在這個健康檢查什么玩意兒的時候就會去調用onDemandUpdate。
經過排查我們發(fā)現(xiàn)，只要配置了eureka.client.healthcheck.enabled=true?，就會創(chuàng)建 HealthCheckHandler?的實例出來，默認情況下他是false的，所以應該是對我們沒有影響的。
這里需要特別說明一下 eureka.client.healthcheck.enabled ?的作用，默認 Eureka 根據(jù)心跳來決定應用的狀態(tài)，如果是這個屬性配置成 true的話，則是會根據(jù) Spring Boot Actuator 來決定，而不是心跳了。
比如我們可以實現(xiàn) HealthIndicator?接口，自己寫一個Controller來動態(tài)改變服務的狀態(tài)
@RestController
public class ControllerTest {
@Autowired
private HealthChecker healthChecker;
@RequestMapping("/change")
public String test(Boolean flag) {
healthChecker.setUp(new AtomicBoolean(flag));
return "success";
}
}
實現(xiàn)HealthChecker，這樣會發(fā)現(xiàn)啟動、下線服務 Eureka Server 的狀態(tài)不會變成 Down，只有通過調用接口手動改變應用狀態(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();
}
}
第二個問題
第一個問題我們找到了，發(fā)現(xiàn)他不是導致我們問題的根因，于是繼續(xù)排查。
發(fā)現(xiàn)第二個調用，在DiscoveryClient注冊了狀態(tài)事件變更的監(jiān)聽，如果狀態(tài)發(fā)生變更，也會去調用 onDemandUpdate ，影響延遲注冊的效果。
這里存在一個配置項onDemandUpdateStatusChange?，默認是true，所以應該是他沒錯了。
進入StatusChangeListener，找到了一個調用。
就是通過setInstanceStatus方法觸發(fā)的事件通知。
這里存在 6 個調用，一一排查，通過源碼找啊找，最終定位到服務啟動自動裝配的地方，在這里去修改服務狀態(tài)為 UP?，然后觸發(fā)事件通知，啟動 start? 方法調用register方法。
繼續(xù)調用，修改應用為上線UP狀態(tài)。
由此我們知道，只要服務啟動成功，就會觸發(fā)事件通知，所以這個基本上是啟動成功立刻就會去注冊到 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秒
但是，但是?。。?/p>
發(fā)現(xiàn)過了幾十秒之后，還是注冊到 Server 了，真的是醉了。。。
那就繼續(xù)看吧。
再看下注冊方法，可能不止一個地方存在調用，我們發(fā)現(xiàn)果然如此，有 3 個地方都調用了注冊方法。
第一個調用在DiscoveryClient?注入的時候，這個看了下，clientConfig.shouldEnforceRegistrationAtInit()?默認是false，方法不會進來，不管他了。
那么繼續(xù)看第二個調用，第二個調用你看renew方法，這一看我們就知道了，這不就是心跳嗎？！
發(fā)送心跳如果返回NOT_FOUND，就會去注冊了啊。
感覺已經接近真相了，去找下 Server 心跳的源碼，根據(jù)調用的路徑找到源碼位于InstanceResource中。
可以看到第一次注冊的時候從注冊表拿到的實例信息是空的，所以直接返回了 false，就會返回 NOT FOUND 了。
看registry.renew?方法，最終會調用到AbstractInstanceRegistry?中，初始化的時候注冊表registry?肯定沒有當前實例的信息，所以拿到是空的，返回了false，最終就返回了NOT_FOUND。
因此，雖然我們把這兩個參數(shù)都設置成了false，但是由于心跳默認 30 秒一次，所以最終我們發(fā)現(xiàn)配置的超級大的延遲注冊的時間并沒有完全生效。
總結
OK，到此，延遲注冊不生效的原因找到了，我們做一個總結。
默認情況下，配置了延遲注冊的時間并不會生效，因為事件監(jiān)聽默認是true，服務啟動之后就會立刻注冊到 Eureka Server。
如果需要延遲注冊生效，必須 eureka.client.healthcheck.enabled ?、eureka.client.onDemandUpdateStatusChange? 都為false。
即便我們把所有途徑都封死了，但是發(fā)送心跳的線程仍然會去注冊，所以這個延遲注冊的時間最多也不會超過 30 秒，即便配置的延遲時間超過 30 秒。
網站名稱：我也是醉了，Eureka延遲注冊還有這個坑！
鏈接地址：http://m.fisionsoft.com.cn/article/dhcpocc.html
