eureka介紹：
eureka是netflix的乙個子模組，也是核心模組之一。eureka是乙個基於rest的服務，用於定位服務，以實現雲端中間層服務發現和故障轉移，服務註冊與發現對於微服務來說是非常重要的，有了服務發現與註冊，只需要使用服務的識別符號，就可以訪問到服務，而不需要修改服務呼叫的配置檔案了，功能類似於dubbo的註冊中心，比如zookeeper;
springcloud整合了eureka，並提供了開箱即用的支援。其中eureka又可細分為eureka server 和eureka client.
eureka基本原理：
伺服器啟動後向eureka註冊，eureka server會將註冊資訊向其他eureka server進行同步，當服務消費者需要呼叫服務提供者時，會向註冊中心獲取服務提供者的位址，然後將位址快取到本地，下次呼叫的時候，直接從本地快取中去取，完成一次呼叫，當註冊中心檢測到服務提供者宕機或者網路不可用的時候，會向訂閱者發布服務提供者的狀態，訂閱過的服務消費者會更新本地快取。服務提供者在啟動後，週期性（預設30秒）向eureka server傳送心跳，以證明當前服務是可用狀態。eureka server在一定的時間（預設90秒）未收到客戶端的心跳，則認為服務宕機，登出該例項。
eureka與zookeeper的區別：
首先了解一下：
關係型資料庫(mysql, oracle,sqlserver等)遵循的原則是：acid原則。
a：原子性
c：一致性
i：隔離性
d：永續性
nosql(redis, mogodb等)非關係型資料庫遵循的原則是：cap。
c：強一致性
a：可用性
p：分割槽容錯性(服務對網路分割槽故障的容錯性)
在分布式領域中有乙個很著名的cap定理，在這個特性中任何分布式系統只能保證兩個。
zookeeper保證的是cp
當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊資訊，但不能接受服務直接宕機不可用，即服務註冊功能對可用性的要求要高於一致性，但是zk會出現這樣一種情況，當master節點因為網路故障與其他節點失去聯絡時，剩餘節點會重新進行leader選舉，問題在於，選舉leader的時間太長30~120s，且選舉期間整個zk集群都是不可用的，這就導致在選舉期間註冊服務癱瘓。在雲部署的環境下，因為網路問題使得zk集群失去master節點是較大概率會發生的事件，雖然服務最終能夠恢復，但是漫長的選舉時間導致的註冊長期不可用是不能容忍的。
eureka保證的是ap
eureka看明白了這一點，因此在設計時就優先保證可用性。eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點依然可以提供註冊和查詢服務。而eureka的客戶端在向某個eureka註冊時，如果發現連線失敗，則會自動切換至其他節點，只要有一台eureka還在，就能保住註冊服務的可用性，只不過查到的資訊可能不是最新的，除此之外，eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼eureka就認為客戶端與註冊中心出現了網路故障，此時會出現以下幾種情況：
1.eureka不再從註冊列表中移除因為長時間沒收到心跳而應該過期的服務
2. eureka仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其它節點(即保證當前節點依然可用)
3. 當網路穩定時，當前例項新的註冊資訊會被同步到其他節點中
因此，eureka可以很好的應對因網路故障導致部分節點失去聯絡的情況，而不會像zookeeper那樣使整個註冊服務癱瘓。
zookeeper的設計理念就是分布式協調服務，保證資料（配置資料，狀態資料）在多個服務系統之間保證一致性，這也不難看出zookeeper是屬於cp特性。eureka是吸取zookeeper問題的經驗，先保證可用性。
Eureka 簡介及與Zookeeper對比
簡單介紹 spring cloud spring cloud 是乙個基於spring boot實現的微服務開發工具。到目前為止我運用到生產中的常用的元件如下。與dubbo的服務治理做比較和分析，如圖 eureka服務治理機制 dubbo服務治理機制 eureka服務治理機制 服務提供者 取消租約 下...
Zookeeper 與 eureka的區別
1.cap定理 從圖中我們可以看到,zk為cp,erreka為ap 2.可用性.zk主從設計,如果zk節點有一半吧節點宕機或者有節點正在選舉,此時zk集群不可用.eureka,p2p點對點設計,每個點的資訊都可以使用者接入,每個點如果資訊變化,它內部會自動同步所有資料,eureka即使所有節點都宕機...
Eureka與Zookeeper的區別
當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊資訊，但不能接受服務直接down掉不可用。也就是說，服務註冊功能對可用性的要求要高於一致性。但是zk會出現這樣一種情況，當master節點因為網路故障與其他節點失去聯絡時，剩餘節點會重新進行leader選舉。問題在於，選舉lea...