1.趨勢

zookeeper和eureka，consul用的沒那麼多，nacos現在用的越來越多，以後也會是一個大的趨勢，但是現在可能還沒那麼的普及

2.CAP理論

CAP原則又稱CAP定理，指的是在一個分散式系統中，[一致性]、[可用性]、分割槽容錯性（Partition tolerance）。CAP 原則指的是，這三個要素最多隻能同時實現兩點，不可能三者兼顧。

分割槽容錯性：指的分散式系統中的某個節點或者網路分割槽出現了故障的時候，整個系統仍然能對外提供滿足一致性和可用性的服務。也就是說部分故障不影響整體使用。

可用性： 一直可以正常的做讀寫操作。簡單而言就是客戶端一直可以正常訪問並得到系統的正常響應。使用者角度來看就是不會出現系統操作失敗或者訪問超時等問題。

一致性：在分散式系統完成某寫操作後任何讀操作，都應該獲取到該寫操作寫入的那個最新的值。相當於要求分散式系統中的各節點時時刻刻保持資料的一致性。

3.zookeeper原理

zookeeper的原理，leader+follower，leader寫，同步到follower，follower可以讀，保證順序一致性，就是基本儘量保證到資料一致的，主動推送，典型的CP，leader崩潰的時候，為了保證資料一致性，儘量不要讀到不一致的資料，此時要重新選舉leader以及做資料同步，此時叢集會短暫的不可用，CP

4.服務註冊中心選型

• 服務註冊中心選型對比的時候，其他的分散式系統選型的時候，一般要滿足cp或者ap
• P簡單來說就是任何分散式系統一般都會滿足，他就是分割槽容錯性；CP，C，一致性，儘可能的去保證你讀取到的資料是一致的，犧牲掉一個A，可用性，一旦leader崩潰，zk可能會有一個短時間內，幾十s有可能，叢集不可用，此時需要重新選舉一個leader，然後再做資料同步，保證資料一致性之後再開放讓你來讀取

5.eureka的原理

eureka的原理，peer-to-peer，大家都能寫也都能讀，每個節點都要同步給其他節點，但是是非同步複製的，所以隨時讀任何一個節點，可能讀到的資料都不一樣，任何一個節點宕機，其他節點正常工作，可用性超高，但是資料一致性不行，AP

5.Nacos和Consul

Consul也是基於raft演算法的CP模型

總結

其實CP或者AP也都行，CP就是偶爾可能短時間不可用，AP就是可能資料不一致，兩個都有問題，但是在生產環境下，無論CP還是AP其實都用的很多

但是未來還是建議大家用nacos，因為nacos的功能最為完善，包括了雪崩保護、自動登出例項、監聽支援、多資料中心、跨註冊中心同步、spring cloud整合、dubbo整合、k8s整合，這些都支援，其他的幾個技術基本都支援部分罷了