程式設計師筆記|詳解Eureka 快取機制
引言
Eureka是Netflix開源的、用於實現服務註冊和發現的服務。Spring Cloud Eureka基於Eureka進行二次封裝，增加了更人性化的UI，使用更為方便。但是由於Eureka本身存在較多快取，服務狀態更新滯後，最常見的狀況是：服務下線後狀態沒有及時更新，服務消費者呼叫到已下線的服務導致請求失敗。
本文基於Spring Cloud Eureka 1.4.4.RELEASE，在預設region和zone的前提下，介紹Eureka的快取機制。
一、AP特性
從CAP理論看，Eureka是一個AP系統，優先保證可用性（A）和分割槽容錯性（P），不保證強一致性（C），只保證最終一致性，因此在架構中設計了較多快取。
Eureka高可用架構
二、服務狀態
Eureka服務狀態enum類：
com。netflix。appinfo。InstanceInfo。InstanceStatus
三、Eureka Server
在Eureka高可用架構中，Eureka Server也可以作為Client向其他server註冊，多節點相互註冊組成Eureka叢集，叢集間相互視為peer。Eureka Client向Server註冊、續約、更新狀態時，接受節點更新自己的服務註冊資訊後，逐個同步至其他peer節點。
【注意】
如果server-A向server-B節點單向註冊，則server-A視server-B為peer節點，server-A接受的資料會同步給server-B，但server-B接受的資料不會同步給server-A。
3.1 快取機制
Eureka Server存在三個變數：（
registry、readWriteCacheMap、readOnlyCacheMap
）儲存服務註冊資訊，預設情況下定時任務每30s將readWriteCacheMap同步至readOnlyCacheMap，每60s清理超過90s未續約的節點，Eureka Client每30s從readOnlyCacheMap更新服務註冊資訊，而UI則從registry更新服務註冊資訊。
三級快取
快取相關配置
關鍵類
四、Eureka Client
Eureka Client存在兩種角色：
服務提供者
和
服務消費者
，作為服務消費者一般配合Ribbon或Feign（Feign內部使用Ribbon）使用。Eureka Client啟動後，作為服務提供者立即向Server註冊，預設情況下每30s續約（renew）；作為服務消費者立即向Server全量更新服務註冊資訊，預設情況下每30s增量更新服務註冊資訊；Ribbon延時1s向Client獲取使用的服務註冊資訊，預設每30s更新使用的服務註冊資訊，只儲存狀態為UP的服務。
二級快取
快取相關配置
關鍵類
五、預設配置下服務消費者最長感知時間
考慮如下情況
0s時服務未通知Eureka Client直接下線；
29s時第一次過期檢查evict未超過90s；
89s時第二次過期檢查evict未超過90s；
149s時第三次過期檢查evict未續約時間超過了90s，故將該服務例項從registry和readWriteCacheMap中刪除；
179s時定時任務從readWriteCacheMap更新至readOnlyCacheMap；
209s時Eureka Client從Eureka Server的readOnlyCacheMap更新；
239s時Ribbon從Eureka Client更新。
因此，極限情況下服務消費者最長感知時間將無限趨近240s。
六、應對措施
服務註冊中心在選擇使用Eureka時說明已經接受了其優先保證可用性（A）和分割槽容錯性（P）、不保證強一致性（C）的特點。如果需要優先保證強一致性（C），則應該考慮使用ZooKeeper等CP系統作為服務註冊中心。分散式系統中一般配置多節點，單個節點服務上線的狀態更新滯後並沒有什麼影響，這裡主要考慮服務下線後狀態更新滯後的應對措施。
6.1 Eureka Server
1。
縮短readOnlyCacheMap更新週期
。縮短該定時任務週期可減少滯後時間。
eureka。server。responsecCacheUpdateIntervalMs： 10000 # Eureka Server readOnlyCacheMap更新週期
2。
關閉readOnlyCacheMap
。中小型系統可以考慮該方案，Eureka Client直接從readWriteCacheMap更新服務註冊資訊。
eureka。server。useReadOnlyResponseCache： false # 是否使用readOnlyCacheMap
6.2 Eureka Client
1。
服務消費者使用容錯機制
。如Spring Cloud Retry和Hystrix，Ribbon、Feign、Zuul都可以配置Retry，服務消費者訪問某個已下線節點時一般報ConnectTimeout，這時可以透過Retry機制重試下一個節點。
2。
服務消費者縮短更新週期
。Eureka Client和Ribbon二級快取影響狀態更新，縮短這兩個定時任務週期可減少滯後時間，例如配置：
eureka。client。registryFetchIntervalSeconds： 5 # Eureka Client更新週期 ribbon。ServerListRefreshInterval： 2000 # Ribbon更新週期
3。
服務提供者保證服務正常下線
。服務下線時使用kill或kill -15命令，避免使用kill -9命令，kill或kill -15命令殺死程序時將觸發Eureka Client的shutdown（）方法，主動刪除Server的registry和readWriteCacheMap中的註冊資訊，不必依賴Server的evict清除。
4。
服務提供者延遲下線
。服務下線之前先呼叫介面使Eureka Server中儲存的服務狀態為DOWN或OUT_OF_SERVICE後再下線，二者時間差根據快取機制和配置決定，比如預設情況下呼叫介面後延遲90s再下線服務即可保證服務消費者不會呼叫已下線服務例項。
七、閘道器實現服務下線實時感知
在軟體工程中，沒有一個問題是中間層解決不了的，而閘道器是服務提供者和服務消費者的中間層。以Spring Cloud Zuul閘道器為例，閘道器作為Eureka Client儲存了服務註冊資訊，服務消費者透過閘道器將請求轉發給服務提供者，只需要做到服務提供者下線時通知閘道器在自己儲存的服務列表中使該服務失效。為了保持閘道器的獨立性，可實現一個獨立服務接收下線通知並協調閘道器叢集。
下篇文章將詳細介紹閘道器如何實現服務下線實時感知
，敬請期待！
作者：馮永彪
內容來源：
