作為服務註冊中心，eureka比zookeeper區別
著名的cap理論指出，乙個分布式系統不可能同時滿足c(一致性)、a(可用性)和p(分割槽容錯性)。由於分割槽容錯性在是分布式系統中必須要保證的，因此我們只能在a和c之間進行權衡。在此zookeeper保證的是cp, 而eureka則是ap
1. zookeeper保證cp
當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊資訊，但不能接受服務直接down掉不可用。也就是說，服務註冊功能對可用性的要求要高於一致性。但是zk會出現這樣一種情況，當master節點因為網路故障與其他節點失去聯絡時，剩餘節點會重新進行leader選舉。問題在於，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk集群都是不可用的，這就導致在選舉期間註冊服務癱瘓
2 .eureka保證ap
eureka看明白了這一點，因此在設計時就優先保證可用性。eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點依然可以提供註冊和查詢服務。而eureka的客戶端在向某個eureka註冊或時如果發現連線失敗，則會自動切換至其它節點，只要有一台eureka還在，就能保證註冊服務可用(保證可用性)，只不過查到的資訊可能不是最新的(不保證強一致性)。除此之外，eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼eureka就認為客戶端與註冊中心出現了網路故障，此時會出現以下幾種情況：
eureka不再從註冊列表中移除因為長時間沒收到心跳而應該過期的服務
eureka仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其它節點上(即保證當前節點依然可用)
當網路穩定時，當前例項新的註冊資訊會被同步到其它節點中因此， eureka可以很好的應對因網路故障導致部分節點失去聯絡的情況，而不會像zookeeper那樣使整個註冊服務癱瘓。
5. 總結eureka
. 作為單純的服務註冊中心來說要比zookeeper更加「專業」，因為註冊服務更重要的是可用性，我們可以接受短期內達不到一致性的狀況。
Eureka服務註冊中心
1.適用場景有侷限 如果服務提供者的網路位址 ip和埠 發生變化，將會影響服務消費者。2.無法動態伸縮 每個微服務一般都會部署多個例項，從而實現實現容災和負載均衡，微服務系統需要具備自動伸縮的能力。如何解決上述方案 1 需要乙個強大的服務發現機制，服務消費者使用這種機制獲取服務提供者的網路資訊，及時...
eureka搭建服務註冊中心
org.springframework.boot spring boot starter parent 2.0.6.release utf 8 utf 8 1.8finchley.sr1 org.springframework.cloud spring cloud starter netflix e...
微服務 Eureka註冊中心
我們來解決微服務的第一問題，服務的管理。服務中心對外提供服務，需要對外暴露自己的位址。而consumer 呼叫者 需要記錄服務提供者的位址。將來位址出現變更，還需要及時更新。這在服務較少的時候並不覺得有什麼，但是在現在日益複雜的網際網路環境，乙個專案肯定會拆分出十幾，甚至數十個微服務。此時如果還人為...