SpringCloud Eureka設計理念(二)

AP優於CP

　　Eureka設計者認爲，在雲端，特別是大規模部署的狀況下，失敗是不可避免的，可能由於Eureka自身部署失敗，致使註冊服務不可用，或者網絡分區致使服務不可用，所以Eureka選擇知足Availability這個特性。即Eureka全部節點都是對等的，即便掛掉幾個節點，其餘正常的幾點仍能提供服務。

Peer to Peer 對等架構

　　Eureka Server採用的就是Peer to Peer的複製模式。

　　Eureka Server自己依賴客戶端，也就是每一個Eureka Server做爲其餘Eureka Server的Client。在單個Eureka Server啓動的時候，會有一個syncUp的操做，經過Eureka Client請求其餘的Eureka Server節點中的一個節點獲取註冊的應用實例信息，而後複製到其餘的peer節點。

　　Eureka Server在執行復制操做的時候，使用HEADER_REPLICATION的http header來將這個請求操做與普通應用實例的正常請求操做區分來。經過HEADER_REPLICATION來標誌複製請求，這樣其餘peer節點收到請求的時候，就不會對它的peer節點進行復制操做，避免死循環。

　　Eureka Client客戶端使用quarantineSet維護了一個不可用的Eureka Server列表，進行請求的時候，優先從列表中進行選擇，若是請求失敗則切換到下一個Eureka Server進行重試，重試的次數默認爲3次。另外爲了防止客戶端都按配置文件指定的順序進行請求形成Eureka Server節點請求分佈不均衡的狀況，客戶端有個定時任務（默認5分鐘執行一次）來刷新並隨機化Eureka Server列表。

Eureka解決複製衝突的方式

　　針對數據的一致性，通常是經過版本號機制來解決，最後在不一樣版本之間只須要判斷請複製數據的版本號與本地數據的版本號高低就能夠了。Eureka沒有直接使用版本號的屬性，而是採用一個叫作lastDirtyTimestamp的字段來對比。

　　若是開啓SyncWhenTimestampDiffers配置（默認開啓），當lastDirtyTimestamp不爲空時，進行如下處理：

1. 若是請求的lastDirtyTimestamp值大於Server本地該實例的lastDirtyTimestamp值，則表示Eureka Server之間的數據衝突，這個時候返回404，要求應用實例從新進行register操做；
2. 若是請求的lastDirtyTimestamp值小於Server本地該實例的lastDirtyTimestamp值，若是是peer節點的複製請求，則表示數據出現衝突，返回409給peer節點，要求其同步本地實例最新的數據。

　　peer節點的相互複製並不能保證全部操做都能成功，所以Eureka還經過應用實例與Server之間的heartbeat(心跳)也就是renewLease（租約）操做來進行數據的最終恢復，即若是發現應用實例數據與某個server的數據出現不一致，則Server返回404，應用實例從新進行register操做。

Zone以及Region的設計

　　Eureka Server默認設置了4個Region，在每一個Region下面還分了多個AvailabilityZone；每一個Region是相互獨立及隔離的，默認狀況下資源只在單個Region之間的AvailabilityZone之間複製，所以Eureka Server的高可用主要就在與Region下的AvailabilityZone。

　　Eureka Client支持preferSameZone,也就是Eureka Server的serviceUrl優先拉取跟應用實例在同一個AvailabilityZone的Eureka Server地址列表。

SELF PRESERVATION 自我保護機制設計

　　Eureka Server與Eureka Client端之間有個租約，Client要定時發送心跳來維持這個租約，表示本身還活着。Eureka Server端經過當前註冊的實例數，去計算每分鐘應該從應用實例接收到的心跳數，若是最近一分鐘接收到的續約的次數小於指定的閾值，則關閉租約失效剔除，禁止定時任務剔除失效的實例，從而保護註冊信息。