Spring cloud--服務注冊和服務發現-Eureka 的使用

消費者

# server

注意：

EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.

分析：是由於Eureka進入了保護模式。

在保護模式下，Eureka Server將會嚐試保護其服務注冊表中的信息，暫時不會注銷服務注冊表中的服務。

四、基本流程：

1、  最左邊的client（即服務提供者）發起us-east-1c注冊請求；

2、  Eureka Server集群中的其他兩個node（us-east-1d和us-east-1e進行Replicate複製）；

3、  圖下放的兩個client（即服務消費者）分別向三個server獲取注冊信息及Get Registry。

五、和Zookeeper的對比

1、分布式係統的CAP理論：

一致性（C）：所有的節點上的數據時刻保持同步。

可用性（A）：每個請求都能接受到一個響應，無論響應成功或失敗。

分區容錯性（P）：係統應該能持續提供服務，即使係統內部有消息丟失（分區）。

 

由於分區容錯性在是分布式係統中必須要保證的，因此我們隻能在A和C之間進行權衡。

在此Zookeeper保證的是CP, 而Eureka則是AP。

 

2、Zookeeper保證CP

ZooKeeper是個 CP的，即任何時刻對ZooKeeper的訪問請求能得到一致的數據結果，同時係統對網絡分割具備容錯性、但是它不能保證每次服務請求的可用性(注：也就是在極端環境下，ZooKeeper可能會丟棄一些請求，消費者程序需要重新請求才能獲得結果)。

例如：當master節點因為網絡故障與其他節點失去聯係時，剩餘節點會重新進行leader選舉。問題在於，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk集群都是不可用的，這就導致在選舉期間注冊服務癱瘓。

 

3、Eureka保證AP

Eureka看明白了這一點，因此在設計時就優先保證可用性。我們可以容忍注冊中心返回的是幾分鍾以前的注冊信息，但不能接受服務直接down掉不可用。也就是說，服務注冊功能對可用性的要求要高於一致性。

如果Eureka服務節點在短時間裏丟失了大量的心跳連接(注：可能發生了網絡故障)，那麼這個 Eureka節點會進入“自我保護模式”，同時保留那些“心跳死亡”的服務注冊信息不過期。此時，這個Eureka節點對於新的服務還能提供注冊服務，對於“死亡”的仍然保留，以防還有客戶端向其發起請求。當網絡故障恢複後，這個Eureka節點會退出“自我保護模式”。Eureka的哲學是，同時保留“好數據”與“壞數據”總比丟掉任何數據要更好。

 

4、總結

Eureka作為單純的服務注冊中心來說要比zookeeper更加“專業”，因為注冊服務更重要的是可用性，我們可以接受短期內達不到一致性的狀況。

當然，這也要看具體的使用場景。