SpringCloud Eureka認知(一)

Eureka簡介

　　Eureka是Nerflix公司開源的一款服務發現（或註冊中心）組件，該組件提供的服務發現能夠爲負載均衡、failover等提供支持。

　　Eureka包括Eureka Server和Eureka Client。Eureka Server提供REST服務，Eureka Client則是使用Java編寫的客戶端，用於簡化與Eureka Server的交互。

服務發現組件對比

名稱	類型	AP或CP	語言	依賴	集成	一致性算法
Zookeeper	General	CP	Java	JVM	Client Binding	Paxos
Doozer	General	CP	GO		Client Binding	Paxos
Consul	General	CP	GO			Raft
Etcd	General	CP	GO			Raft
SmarkStack	Dedicated	AP	Ruby	Zookerper
Eureka	Dedicated	AP	Java	JVM	Java Client

CAP理論

　　分佈式領域有個重要的CAP理論：

1. Consistency：數據一致性，即數據存在多個副本的狀況下，可能因爲網絡、機器故障、軟件系統等問題致使數據寫入部分副本成功，部分副本失敗，進而形成副本之間的數據不一致，存在衝突。知足數據一致性要求對數據的更新操做成功後，多副本的數據報保持一致。
2. Availability：高可用，即任什麼時候候客戶端對集羣進行讀寫操做時，請求能正常響應，即在必定的延遲內完成。
3. Partition Tolerance：分區容忍性，即發生通訊故障時，整個分區被分割爲多個相互獨立的沒法通訊的分區時，集羣仍可用。

　　對於分佈式系統，通常網絡條件不可控，出現網絡分區是不可避免的，所以系統必須具有分區容忍性。

分佈式系統的數據在多個副本之間的複製方式

　　通常而言，分佈式系統的數據在多個副本之間的複製方式可分爲主從複製和對等複製。

　　主從複製即Master-Slave模式，即有一個主副本，其餘副本爲從副本。全部對數據的寫操做都提交到主副本，最後再由主副本更新到從副本，具體的更新方式有同步更新、異步更新、同步及異步混合。對於主從複製模式，寫操做的壓力主要都在主副本，從副本幫主副本分擔讀操做請求。

　　對等複製即Peer to Peer，即任何副本都是對等的，任何副本均可以接收寫操做請求，而後每一個副本進行數據更新。

Zookeeper的CP原則

　　Zookeeper默認並非嚴格的強一致性，好比客戶端A提交一個寫操做，Zookeeper在半數節點操做成功後就返回，此時假設客戶端B讀操做請求的剛好是A寫操做還沒有同步到的節點，那麼讀取到的就不是客戶端A寫操做成功後的數據。

　　若是須要保證數據的強一致性，則須要在讀取數據的時候先執行一下sync操做，即與leader節點先同步下數據。

　　Zookeeper不知足高可用特性，當 master 節點(主副本)由於網絡故障與其餘節點失去聯繫時，剩餘節點會從新進行 leader 選舉。問題在於，選舉 leader 的時間太長，30 ~ 120s, 且選舉期間整個 zookeeper 集羣都是不可用的，這就致使在選舉期間註冊服務癱瘓。

Eureka的AP原則

　　Eureka各個節點都是平等的,幾個節點掛掉不會影響正常節點的工做，剩餘的節點依然能夠提供註冊和查詢服務。

　　而Eureka的客戶端在向某個Eureka註冊或時若是發現鏈接失敗,則會自動切換至其它節點,只要有一臺Eureka還在,就能保證註冊服務可用(保證可用性),只不過查到的信息可能不是最新的(不保證強一致性)。

　　除此以外, Eureka還有一種自我保護機制,若是在15分鐘內超過85%的節點都沒有正常的心跳,那麼Eureka就認爲客戶端與註冊中心出現了網絡故障,此時會出現如下幾種狀況

1. Eureka再也不從註冊列表中移除由於長時間沒收到心跳而應該過時的服務
2. Eureka仍然可以接受新服務的註冊和查詢請求,可是不會被同步到其它節點上(即保證當前節點依然可用)
3. 當網絡穩定時,當前實例新的註冊信息會被同步到其它節點中.

　　所以, Eureka能夠很好的應對因網絡故障致使部分節點失去聯繫的狀況,而不會像zookeeper那樣便整個註冊服務癱瘓。