spring cloud Greenwich下eureka服務註冊實現快速下線快速感知快速刷新的配置

這塊內容涉及到eureka的原理，其中重點在於eureka的多級緩存機制，

在拉取註冊表的時候：

首先從ReadOnlyCacheMap裏查緩存的註冊表。

若沒有，就找ReadWriteCacheMap裏緩存的註冊表。

如果還沒有，就從內存中獲取實際的註冊表數據。

在註冊表發生變更的時候：

會在內存中更新變更的註冊表數據，同時過期掉ReadWriteCacheMap。

此過程不會影響ReadOnlyCacheMap提供人家查詢註冊表。

一段時間內（默認30秒），各服務拉取註冊表會直接讀ReadOnlyCacheMap

30秒過後，Eureka Server的後臺線程發現ReadWriteCacheMap已經清空了，也會清空ReadOnlyCacheMap中的緩存

下次有服務拉取註冊表，又會從內存中獲取最新的數據了，同時填充各個緩存。

綜上所述，服務提供者和服務調用者配置不夠靈敏，總是服務提供者在停掉很久之後，服務調用者很長時間並沒有感知到變化的原因在於：
EurekaServer自己的ReadWriteMap緩存失效延遲，刷新到ReadOnlyMap的延遲，服務調用者自己本地緩存刷新的延遲。

服務已經註冊或者下線了，但是服務調用方長時間還是感知不到，發現不了新服務或者仍舊調用已經下線的服務。

解決方案：

EurekaServer修改如下配置：

eureka:
  server:
    responseCacheUpdateIntervalMs: 3000 #eureka server刷新readCacheMap的時間，注意，client讀取的是readCacheMap，這個時間決定了多久會把readWriteCacheMap的緩存更新到readCacheMap上,默認30s
    enable-self-preservation: true # 測試時關閉自我保護機制，保證不可用服務及時踢出【生成環境不要關閉】
    eviction-interval-timer-in-ms: 3000       # 續期時間，即掃描失效服務的間隔時間，清理無效節點的時間間隔，默認60000毫秒，即60秒

Eureka服務提供方修改如下配置：

eureka:
    instance:
        lease-renewal-interval-in-seconds: 1  #每間隔1s，向服務端發送一次心跳，證明自己依然”存活“，默認30秒
        lease-expiration-duration-in-seconds: 2  #告訴服務端，如果我2s之內沒有給你發心跳，就代表我“死”了，將我踢出掉。默認爲90秒

Eureka服務調用方修改如下配置：

eureka:
    client:
        registryFetchIntervalSeconds: 3  #eureka client刷新本地緩存時間,默認30s

ribbon:
  eureka:
    enabled: true
  ReadTimeout: 1000
  ConnectTimeout: 1000
  MaxAutoRetries: 1
  MaxAutoRetriesNextServer: 1
  OkToRetryOnAllOperations: true
  ServerListRefreshInterval: 3000 #eureka客戶端ribbon刷新時間,默認30s