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模型
Nacos也是基於raft算法的CP模型，同時也支持配置成類似eureka的AP
總結
其實CP或者AP也都行，CP就是偶爾可能短時間不可用，AP就是可能數據不一致，兩個都有問題，但是在生產環境下，無論CP還是AP其實都用的很多
但是未來還是建議大家用nacos，因爲nacos的功能最爲完善，包括了雪崩保護、自動註銷實例、監聽支持、多數據中心、跨註冊中心同步、spring cloud集成、dubbo集成、k8s集成，這些都支持，其他的幾個技術基本都支持部分罷了