圖解原理
看圖說明：
1. 應用server的服務實例一上線，就會將自己註冊到Eureka Server的註冊表中；
2. 服務註冊表一旦檢測到有更新，就會將實例同步到讀寫緩存表；
3. 讀寫緩存表每隔30s，就會將實例信息同步給讀緩存表；
4. 應用Client的服務，每隔30s，就會去Eureka Server的讀緩存拉取所有的服務實例，這時候通信已經建立起來；
5. 服務註冊表每隔60s，會自檢測服務狀態是否有更新，如果有不可用的服務，及時剔除掉；
6. 如果在90s這段時間內，服務實例還沒發送心跳給Eureka Server，Eureka Server就會認爲該實例的服務已經掛掉了，就會將其從註冊表中剔除，並立馬同步給讀寫緩存。
默認參數弊端
從上圖可看出：
一個服務感知另一個服務上線的最久時間是: 步驟3和步驟4，也就是60s；
一個服務感知另一個服務下線的最久時間是：步驟3和步驟4和步驟6，也就是150s。
稍微對時間敏感一點的項目，等這麼久，是很難受的，需要進行調優。
Eureka參數調優
Eureka Server
responseCacheUpdateIntervalMs
讀寫緩存同步給讀緩存，默認是30s，將其改爲3s：
eureka.server.responseCacheUpdateIntervalMs = 3000
evictionIntervalTimerInMs
線程自檢測時間默認是60s，將其改爲6s：
eureka.server.evictionIntervalTimerInMs = 6000
leaseExpirationDurationInSeconds
client心跳過期時間默認是90s，將其改爲6s：
eureka.instance.leaseExpirationDurationInSeconds = 6
應用實例
registryFetchIntervalSeconds
去Eureka Server拉取的時間默認是30s，將其改爲3s：
eureka.client.registryFetchIntervalSeconds = 3
leaseRenewalIntervalInSeconds
發送給Eureka Server的心跳時間，默認是30s，將其改爲3s:
eureka.client.leaseRenewalIntervalInSeconds = 3
調優結果
一個服務感知另一個服務上線的最久時間是: 步驟3和步驟4，也就是6s；
一個服務感知另一個服務下線的最久時間是：步驟3和步驟4和步驟6，也就是12s