eureka服務(wù)注冊(cè)最長(zhǎng)需要2分鐘的原因

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

摘要：的上有一句話，大意是一個(gè)服務(wù)啟動(dòng)后最長(zhǎng)可能需要分鐘時(shí)間才能被其它服務(wù)感知到，但是文檔并沒(méi)有解釋為什么會(huì)有這分鐘。其實(shí)這是由三處緩存一處延遲造成的。對(duì)此做了修改，服務(wù)啟動(dòng)后會(huì)馬上注冊(cè)以上這四個(gè)秒正是官方上寫服務(wù)注冊(cè)最長(zhǎng)需要分鐘的原因。

Eureka的wiki上有一句話，大意是一個(gè)服務(wù)啟動(dòng)后最長(zhǎng)可能需要2分鐘時(shí)間才能被其它服務(wù)感知到，但是文檔并沒(méi)有解釋為什么會(huì)有這2分鐘。其實(shí)這是由三處緩存 + 一處延遲造成的。

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

String payLoad = responseCache.get(cacheKey); // 從cache中拿響應(yīng)數(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類型，該類型是一個(gè)接口，其get()方法首先會(huì)去緩存中查詢數(shù)據(jù)，如果沒(méi)有則生成數(shù)據(jù)返回（即真正去查詢注冊(cè)列表），且緩存的有效時(shí)間為30s。也就是說(shuō)，客戶端拿到Eureka的響應(yīng)并不一定是即時(shí)的，大部分時(shí)候只是緩存信息。

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

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

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

以上這四個(gè)30秒正是官方wiki上寫服務(wù)注冊(cè)最長(zhǎng)需要2分鐘的原因。