eureka服務注冊最長需要2分鐘的原因

Awbeci 發(fā)布于2019-08-16 13:37 / 1198人閱讀

摘要：的上有一句話，大意是一個服務啟動后最長可能需要分鐘時間才能被其它服務感知到，但是文檔并沒有解釋為什么會有這分鐘。其實這是由三處緩存一處延遲造成的。對此做了修改，服務啟動后會馬上注冊以上這四個秒正是官方上寫服務注冊最長需要分鐘的原因。

Eureka的wiki上有一句話，大意是一個服務啟動后最長可能需要2分鐘時間才能被其它服務感知到，但是文檔并沒有解釋為什么會有這2分鐘。其實這是由三處緩存 + 一處延遲造成的。

首先，Eureka對HTTP響應做了緩存。在Eureka的”控制器”類ApplicationResource的109行可以看到有一行
String payLoad = responseCache.get(cacheKey);
的調(diào)用，該代碼所在的getApplication()方法的功能是響應客戶端查詢某個服務信息的HTTP請求：

String payLoad = responseCache.get(cacheKey); // 從cache中拿響應數(shù)據(jù)

if (payLoad != null) {
       logger.debug("Found: {}", appName);
       return Response.ok(payLoad).build();
} else {
       logger.debug("Not Found: {}", appName);
       return Response.status(Status.NOT_FOUND).build();
}

上面的代碼中，responseCache引用的是ResponseCache類型，該類型是一個接口，其get()方法首先會去緩存中查詢數(shù)據(jù)，如果沒有則生成數(shù)據(jù)返回（即真正去查詢注冊列表），且緩存的有效時間為30s。也就是說，客戶端拿到Eureka的響應并不一定是即時的，大部分時候只是緩存信息。

其次，Eureka Client對已經(jīng)獲取到的注冊信息也做了30s緩存。即服務通過eureka客戶端第一次查詢到可用服務地址后會將結(jié)果緩存，下次再調(diào)用時就不會真正向Eureka發(fā)起HTTP請求了。

再次，負載均衡組件Ribbon也有30s緩存。Ribbon會從上面提到的Eureka Client獲取服務列表，然后將結(jié)果緩存30s。

最后，如果你并不是在Spring Cloud環(huán)境下使用這些組件(Eureka, Ribbon)，你的服務啟動后并不會馬上向Eureka注冊，而是需要等到第一次發(fā)送心跳請求時才會注冊。心跳請求的發(fā)送間隔也是30s。（Spring Cloud對此做了修改，服務啟動后會馬上注冊）

以上這四個30秒正是官方wiki上寫服務注冊最長需要2分鐘的原因。