目錄
Eureka和Zookeeper原則對比（數據庫ACID、CAP基礎學習）
作爲服務註冊中心，Eureka比Zookeeper好在哪裏？
Eureka是什麼？
- Eureka是Netflix的一個子模塊，也是核心模塊之一。Eureka是一個基於REST的服務，用於定位服務，以實現雲端中間層服務發現和故障轉移。服務註冊與發現對於微服務架構來說是非常重要的，有了服務發現與註冊，只需要使用服務的標識符，就可以訪問到服務，而不需要修改服務調用的配置文件了。功能類似於dubbo的註冊中心，比如Zookeeper。
Eureka的基本架構
- Eureka採用了C-S的設計架構，Eureka Server作爲服務註冊功能的服務器，它是服務註冊中心
- 而系統中的其他微服務，使用 Eureka 的客戶端連接到 Eureka Server並維持心跳連接。這樣系統的維護人員就可以通過 Eureka Server 來監控系統中各個微服務是否正常運行。SpringCloud 的一些其他模塊（比如Zuul）就可以通過 Eureka Server 來發現系統中的其他微服務，並執行相關的邏輯。
對比Dubbo的註冊中心Zookeeper?
Eureka和Zookeeper架構圖
Eureka架構圖：
Zookeeper架構圖：
Eureka和Zookeeper原則對比（數據庫ACID、CAP基礎學習）
- RBDMS（mysql,oracle/sqlServer）===>ACID
- NOSQL (redis/mongdb) ===>CAP
![]()
- Netflix在設計Eureka時遵守的就是AP原則
Zookeeper保證的是CP，Eureka保證的AP
CAP深入學習
- CAP按現在的發展最多隻能同時較好的滿足兩個
- CAP理論的核心是：一個分佈式系統不可能同時很好的滿足一致性，可用性，分區容錯性這三個需求，因此，根據CAP原理將NOSQL數據庫分成了滿足CA原則，滿足CP原則和滿足AP原則三大類
- CA-單點集羣，滿足一致性，可用性的系統，通常在可擴展性上不太強大
- CP-滿足一致性，分區容忍性的系統，通常性能不是特別高
- AP-滿足可用性，分區容忍性的系統，通常對一致性要求低一
作爲服務註冊中心，Eureka比Zookeeper好在哪裏？
- Zookeeper保證的是CP，Eureka保證的AP
-
1、Zookeeper保證CP
當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊信息，但不能接受服務直接down掉不可用。也就是說，服務註冊功能對可用性的要求要高於一致性。 -
但是zk會出現這樣一種情況，當master節點因爲網絡故障與其他節點失去聯繫時，剩餘節點會重新進行leader選舉。問題在於，選舉leader的時間太長，30~120s，且選舉期間整個zk集羣都是不可用的，這就導致在選舉期間註冊服務癱瘓。在雲部署的環境下，因網絡問題使得zk集羣失去master節點是較大概率會發生的事，雖然服務能夠最終恢復，但是漫長的選舉時間導致的註冊長期不可用是不能容忍的
-
2、Eureka保證AP
Eureka看明白了這一點，因此在設計時就有限保證可用性，Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點依然可以提供註冊和查詢服務，而Eureka的客戶端在向某個Eureka註冊或時如果發現連接失敗，則會自動切換至其他節點，只要有一臺Eureka還在，就能保證註冊服務可用（保證可用性），只不過查到的信息可能不是最新的（不保證強一致性）。除此之外，Eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認爲客戶端和你與註冊中心出現了網絡故障！ -
此時會出現以下幾種情況
- （1）Eureka不再從註冊列表中移除一位內長時間沒收到心跳而應該過期的服務
- （2）Eureka仍然能後接受新服務的註冊和查詢請求，但是不會被同步到其它節點（即保證當前節點依然可用）
- （3）當網絡穩定時，當前實例新的註冊信息會被同步到其他節點中
-
因此：Eureka可以很好的應對因網絡故障導致部分節點失去聯繫的情況，而不會像zookeeper那樣使整個註冊服務癱瘓
Eureka包含兩個組件：
- Eureka Server
- Eureka Client
原理
Eureka是一個Java客戶端，用於建華Eureka Server的交互，客戶端同時也具備一個內置的，使用輪詢（round-robin）負載算法的負載均衡器，在應用啓動之後，將會向Eureka Server發送心跳（默認週期爲30秒）。如果Eureka Server在多個心跳週期內沒有接收到某個節點的心跳，EurekaServer將會從服務註冊表中把這個服務節點移除（默認90秒）
自我保護機制
- 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不會立刻清理，依舊會對該微服務的信息進行保存
- 在自我保護模式中，Eureka Server會保護服務註冊表中的信息，不再註銷任何服務實例，當它收到的心跳數重新恢復到閾值以上時，該Eureka Server會自動退出自我保護模式。它的設計哲學就是寧可保留錯誤的服務註冊信息，也不盲目註銷任何可能健康的服務實力，
- 一句話講解：好死不如賴活着
怎麼搭建？