eureka服務註冊最長鬚要2分鐘的緣由

Eureka的wiki上有一句話，大意是一個服務啓動後最長可能須要2分鐘時間才能被其它服務感知到，可是文檔並無解釋爲何會有這2分鐘。其實這是由三處緩存 + 一處延遲形成的。

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

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

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()方法首先會去緩存中查詢數據，若是沒有則生成數據返回（即真正去查詢註冊列表），且緩存的有效時間爲30s。也就是說，客戶端拿到Eureka的響應並不必定是即時的，大部分時候只是緩存信息。

其次，Eureka Client對已經獲取到的註冊信息也作了30s緩存。即服務經過eureka客戶端第一次查詢到可用服務地址後會將結果緩存，下次再調用時就不會真正向Eureka發起HTTP請求了。

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

最後，若是你並非在Spring Cloud環境下使用這些組件(Eureka, Ribbon)，你的服務啓動後並不會立刻向Eureka註冊，而是須要等到第一次發送心跳請求時纔會註冊。心跳請求的發送間隔也是30s。（Spring Cloud對此作了修改，服務啓動後會立刻註冊）

以上這四個30秒正是官方wiki上寫服務註冊最長鬚要2分鐘的緣由。