consul和eureka為服務註冊中心，它們一般是集群部署的
1.consul提供了cp一致性、分割槽容錯性，對於consul集群來說，consul註冊中心分為leader和fellow，服務註冊和發現會落地到leader去提供，當乙個專案a想要註冊到consul時，leader需要保證a服務註冊資訊同步到半數以上的fellow consul節點才算註冊成功，之後才可以被其他服務發現並呼叫。當leader掛掉後，需要選舉出新的leader節點，選舉過程中consul集群不可用；eureka提供ap可用性、分割槽容錯性，eureka集群並沒有leader和follow的概念，當乙個服務註冊到其中乙個eureka節點後，它可能在其他eureka節點並沒有該服務的註冊資訊，eurake節點之間會相互註冊，同時會互相同步註冊資訊。由上可以看出，consul服務註冊資訊的資料一致性較高，但是它的註冊過程會慢一些，因為需要將註冊資訊同步到其他節點，而eureka的註冊比較快，因為不需要實時同步註冊資訊。並且一般在服務的defaultzone欄位會配置集群中的多個eureka節點（註冊到任意乙個都可以，並且節點之間會互相註冊同步註冊資訊），eureka集群保證服務的可用性，可以容忍一段時間內的註冊資訊不一致
2.節點健康檢查的方式不同
eureka集群中每個client服務隔一段時間就需要傳送心跳到erueka server，用於表示自己可以正常提供服務，該erueka節點會將心跳資訊同步到其他erueka節點，eureka會定時(30s)進行檢查，如果發現一段時間(90s)內沒有收到服務心跳，就認為這個服務宕機。在這種情況下，如果有大量服務同時傳送心跳，就有可能對erueka節點造成較大的心跳請求壓力。
consul中在每乙個服務上都有乙個consul agent，使用該agent不斷傳送請求檢查服務是否健康，當服務出現故障時，會傳送訊息通知consul server leader，這樣就避免了短時間內向註冊中心server傳送大量的心跳請求
consul的安裝和測試
consul的安裝 一台伺服器端，多台客戶端。服務端 nohup consul agent server bootstrap data dir home hanxt workspace data consul bind 192.168.220.139 客戶端 nohup consul agent d...
Zookeeper和Eureka的區別！
著名的cap理論指出，乙個分布式系統不可能同時滿足c 一致性 a 可用性 和p 分割槽容錯性 由於分割槽容錯性p在分布式系統中必須要保證的，因此我們只能在a和c之間進行權衡。因此 zookeeper保證的是cp，eureka則是ap。zoopkeeper保證cp 當向註冊中心查詢服務列表時，我們可以...
ZooKeeper和Eureka的區別
1 cap理論 乙個分布式系統不可能同時滿足c 一致性 a 可用性 和p 分割槽容錯性 zookeeper保證的是cp，而eureka則是ap。2 zookeeper保證cp 當註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊資訊，但是不能接受服務直接down掉不可用。也就是說，...