spring cloud Eureka 服務的管理和spring cloud consul有什麼區別？

12-20

感覺consul好麻煩還得安裝客戶端，雖然consul支持跨平台

主要區別的話，看CAP選擇，大部分註冊中心，就是在這個定理去選擇的，具體怎麼選擇，看下文（覺得不錯就點個贊）

CAP定理：指的是在一個分散式系統中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可同時獲得。

一致性（C）：在分散式系統中的所有數據備份，在同一時刻是否同樣的值。（所有節點在同一時間的數據完全一致，越多節點，數據同步越耗時）

可用性（A）：負載過大後，集群整體是否還能響應客戶端的讀寫請求。（服務一直可用，而且是正常響應時間）

分區容錯性（P）：分區容忍性，就是高可用性，一個節點崩了，並不影響其它的節點（100個節點，掛了幾個，不影響服務，越多機器越好）

再進一步解釋CAP理論：就是說在分散式存儲系統中，最多只能實現上面的兩點。而由於當前的網路硬體肯定會出現延遲丟包等問題，所以分區容忍性是我們必須需要實現的。所以我們只能在一致性和可用性之間進行權衡

C A 滿足的情況下，P不能滿足的原因：

數據同步(C)需要時間，也要正常的時間內響應(A)，那麼機器數量就要少，所以P就不滿足

CP 滿足的情況下，A不能滿足的原因：

數據同步(C)需要時間, 機器數量也多(P)，但是同步數據需要時間，所以不能再正常時間內響應，所以A就不滿足

AP 滿足的情況下，C不能滿足的原因：

機器數量也多(P)，正常的時間內響應(A)，那麼數據就不能及時同步到其他節點，所以C不滿足

使用場景就是樓主的註冊中心選擇：

Zookeeper和Consul ：CP設計，保證了一致性，集群搭建的時候，某個節點失效，則會進行選舉行的leader，或者半數以上節點不可用，則無法提供服務，因此可用性沒法滿足

Eureka：AP原則，無主從節點，一個節點掛了，自動切換其他節點可以使用，去中心化

結論：分散式系統中P,肯定要滿足，所以只能在CA中二選一

沒有最好的選擇，最好的選擇是根據業務場景來進行架構設計

如果要求一致性，則選擇zookeeper、Consul，如金融行業

如果要去可用性，則Eureka，如電商系統

原創碼字不易，理解的哥們點個讚唄

最大的區別是Eureka保證AP, Consul為CP。

Consul強一致性(C)帶來的是：

Eureka保證高可用(A)和最終一致性：

服務註冊相對要快，因為不需要等註冊信息replicate到其他節點，也不保證註冊信息是否replicate成功
當數據出現不一致時，雖然A, B上的註冊信息不完全相同，但每個Eureka節點依然能夠正常對外提供服務，這會出現查詢服務信息時如果請求A查不到，但請求B就能查到。如此保證了可用性但犧牲了一致性。

其他方面，eureka就是個servlet程序，跑在servlet容器中; Consul則是go編寫而成。

同樣關注，也存在同樣的疑惑。