客戶端緩存的機制：Eureka還提供了客戶端緩存的機制，即使所有的Eureka Server都掛掉，客戶端仍可以利用緩存中的信息調用服務節點的服務。Eureka一般配合Ribbon進行使用，Ribbon提供了客戶端負載均衡的功能，Ribbon利用從Eureka中讀取到的服務信息，在調用服務節點提供的... ...
Spring Cloud Eureka 是 Spring Cloud Netflix 微服務套件的一部分，基於 Netflix Eureka 做了二次封裝，主要負責完成微服務架構中的服務治理功能，服務治理可以說是微服務架構中最為核心和基礎的模塊，他主要用來實現各個微服務實例的自動化註冊與發現
- 服務註冊：在服務治理框架中，通常都會構建一個註冊中心，每個服務單元向註冊中心登記自己提供的服務，將主機與埠號、版本號、通信協議等一些附加信息告知註冊中心，註冊中心按照服務名分類組織服務清單，服務註冊中心還需要以心跳的方式去監控清單中的服務是否可用，若不可用需要從服務清單中剔除，達到排除故障服務的效果。
- 服務發現：由於在服務治理框架下運行，服務間的調用不再通過指定具體的實例地址來實現，而是通過向服務名發起請求調用實現。
Eureka通過心跳檢測、健康檢查、客戶端緩存等機制，保證了系統具有高可用和靈活性。
Spring Cloud Eureka 使用 Netflix Eureka 來實現服務註冊與發現，即包括了服務端組件，也包含了客戶端組件，並且服務端和客戶端均採用Java編寫，所以Eureka主要適用與通過Java實現的分散式系統，或是與JVM相容語言構建的系統，但是，由於Eureka服務端的服務治理機制提供了完備的RESTful API，所以他也支持將非Java語言構建的微服務納入Eureka的服務治理體系中來。
- Eureka服務端：我們也稱為服務註冊中心，他同其他服務註冊中心一樣，支持高可用配置。同時Eureka有心跳機制，當某個節點服務在規定時間內沒有發送心跳信號時，Eureka會從服務註冊表中把這個服務節點移除。
- Eureka客戶端：主要處理服務的註冊和發現，客戶端服務通過註冊和參數配置的方式，嵌入在客戶端應用程式的代碼中，在應用程式運行時，Eureka客戶端向註冊中心註冊自身提供的服務並周期性的發送心跳來更新他的服務租約。
- 客戶端緩存的機制：Eureka還提供了客戶端緩存的機制，即使所有的Eureka Server都掛掉，客戶端仍可以利用緩存中的信息調用服務節點的服務。Eureka一般配合Ribbon進行使用，Ribbon提供了客戶端負載均衡的功能，Ribbon利用從Eureka中讀取到的服務信息，在調用服務節點提供的服務時，會合理的進行負載。
著名的CAP理論指出，一個分散式系統不可能同時滿足C(一致性)、A(可用性)和P(分區容錯性)。由於分區容錯性在是分散式系統中必須要保證的，因此我們只能在A和C之間進行權衡。在此Zookeeper保證的是CP, 而Eureka則是AP。
4.1 Zookeeper保證CP
當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊信息，但不能接受服務直接down掉不可用。也就是說，服務註冊功能對可用性的要求要高於一致性。但是zk會出現這樣一種情況，當master節點因為網路故障與其他節點失去聯繫時，剩餘節點會重新進行leader選舉。問題在於，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk集群都是不可用的，這就導致在選舉期間註冊服務癱瘓。在雲部署的環境下，因網路問題使得zk集群失去master節點是較大概率會發生的事，雖然服務能夠最終恢復，但是漫長的選舉時間導致的註冊長期不可用是不能容忍的。
4.2 Eureka保證AP
Eureka看明白了這一點，因此在設計時就優先保證可用性。Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點依然可以提供註冊和查詢服務。而Eureka的客戶端在向某個Eureka註冊或時如果發現連接失敗，則會自動切換至其它節點，只要有一臺Eureka還在，就能保證註冊服務可用(保證可用性)，只不過查到的信息可能不是最新的(不保證強一致性)。除此之外，Eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認為客戶端與註冊中心出現了網路故障，此時會出現以下幾種情況：
1. Eureka不再從註冊列表中移除因為長時間沒收到心跳而應該過期的服務
2. Eureka仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其它節點上(即保證當前節點依然可用)
3. 當網路穩定時，當前實例新的註冊信息會被同步到其它節點中
因此， Eureka可以很好的應對因網路故障導致部分節點失去聯繫的情況，而不會像zookeeper那樣使整個註冊服務癱瘓。
