ZooKeeper、Eureka、Consul、Nacos的選型對比
常見注冊中心和發展
【最常見的服務注冊中心就4個】
zookeeper、eureka、consul、nacos
【最常見的是】zookeeper和eureka，consul用的沒那么多，nacos現在用的越來越多，以后也會是一個大的趨勢，但是現在可能還沒那么的普及
四種常用注冊中心
zookeeper
zookeeper的基礎知識以及基本的架構原理，互聯網Java工程師面試突擊第三季，里面是有講過zk的一些架構原理，如果大家不了解的話，可以去看一下
【leader+follower的架構】
【服務主要是2個動作，一個是服務發現，一個是服務發現，別人要讀取服務相關的一些信息】
【服務注冊就是向ZK Leader寫入數據。ZK集群是基於ZAB協議，ZAB協議跟raft協議有點類似，但是不太一樣，ZK自己搞的分布式算法。基於ZAB協議進行數據一致性的同步】
【服務發現就是一個讀取數據的過程，可以找Leader讀，也可以找Follower讀】
【服務注冊只能找Leader，但是服務發現可以找Follower，因為會同步】
zookeeper的原理，leader+follower，leader寫，同步到follower，follower可以讀，保證順序一致性，就是基本盡量保證到數據一致的，主動推送，典型的CP【有個同步過程，不是強一致性的，有可能Leader和Follower不一樣（很短時間內）】，leader崩潰的時候，為了保證數據一致性，盡量不要讀到不一致的數據，此時要重新選舉leader以及做數據同步，此時集群會短暫的不可用，CP
CP和AP的選擇
服務注冊中心選型對比的時候，其他的分布式系統選型的時候，CP，AP
P簡單來說就是任何分布式系統一般都會滿足，他就是分區容錯性；CP，C，一致性，盡可能的去保證你讀取到的數據是一致的，犧牲掉一個A，可用性，一旦leader崩潰，【崩潰的時候可能不同的Follower數據是不一致的】zk可能會有一個短時間內，幾十s有可能，集群不可用，此時需要重新選舉一個leader，然后再做數據同步，保證數據一致性之后再開放讓你來讀取
【CP就是Leader崩潰后犧牲可用性，犧牲A】
consistency，availability【C和A】
eureka
【eureka是AP】
關於eureka的一些架構原理，21天互聯網Java工程師面試訓練營（分布式篇），儒猿技術窩，重點講解了eureka的一些架構原理
eureka的原理，peer-to-peer【每個節點的角色是一樣的，都可以寫數據】，大家都能寫也都能讀，每個節點都要同步給其他節點，但是是異步復制的，所以隨時讀任何一個節點，可能讀到的數據都不一樣，任何一個節點宕機，其他節點正常工作，可用性超高，但是數據一致性不行，AP
Consul
Consul也是基於raft算法的CP模型
Nacos
Nacos也是基於raft算法的CP模型，同時也支持配置成類似eureka的AP
選用
其實CP或者AP也都行，CP就是偶爾可能短時間不可用，AP就是可能數據不一致，兩個都有問題，但是在生產環境下，無論CP還是AP其實都用的很多
演變
其實說白了，zk作為注冊中心是早期dubbo時代的標配；后續spring cloud進入國內市場，大家就都用eureka了，但是spring cloud也推薦了consul，所以consul也有不少人在用，zk、eureka、consul，其實都有人用
但是未來還是建議大家用nacos，因為nacos的功能最為完善，包括了雪崩保護、自動注銷實例、監聽支持、多數據中心、跨注冊中心同步、spring cloud集成、dubbo集成、k8s集成，這些都支持，其他的幾個技術基本都支持部分罷了
【建議選用raft算法的CP。AP可能會引發混亂】