1.趨勢(shì)
zookeeper和eureka，consul用的沒那么多，nacos現(xiàn)在用的越來越多，以后也會(huì)是一個(gè)大的趨勢(shì)，但是現(xiàn)在可能還沒那么的普及
2.CAP理論
CAP原則又稱CAP定理，指的是在一個(gè)分布式系統(tǒng)中，[一致性]、[可用性]、分區(qū)容錯(cuò)性（Partition tolerance）。CAP 原則指的是，這三個(gè)要素最多只能同時(shí)實(shí)現(xiàn)兩點(diǎn)，不可能三者兼顧。
分區(qū)容錯(cuò)性：指的分布式系統(tǒng)中的某個(gè)節(jié)點(diǎn)或者網(wǎng)絡(luò)分區(qū)出現(xiàn)了故障的時(shí)候，整個(gè)系統(tǒng)仍然能對(duì)外提供滿足一致性和可用性的服務(wù)。也就是說部分故障不影響整體使用。
可用性： 一直可以正常的做讀寫操作。簡單而言就是客戶端一直可以正常訪問并得到系統(tǒng)的正常響應(yīng)。用戶角度來看就是不會(huì)出現(xiàn)系統(tǒng)操作失敗或者訪問超時(shí)等問題。
一致性：在分布式系統(tǒng)完成某寫操作后任何讀操作，都應(yīng)該獲取到該寫操作寫入的那個(gè)最新的值。相當(dāng)于要求分布式系統(tǒng)中的各節(jié)點(diǎn)時(shí)時(shí)刻刻保持?jǐn)?shù)據(jù)的一致性。
3.zookeeper原理
zookeeper的原理，leader+follower，leader寫，同步到follower，follower可以讀，保證順序一致性，就是基本盡量保證到數(shù)據(jù)一致的，主動(dòng)推送，典型的CP，leader崩潰的時(shí)候，為了保證數(shù)據(jù)一致性，盡量不要讀到不一致的數(shù)據(jù)，此時(shí)要重新選舉leader以及做數(shù)據(jù)同步，此時(shí)集群會(huì)短暫的不可用，CP
4.服務(wù)注冊(cè)中心選型
- 服務(wù)注冊(cè)中心選型對(duì)比的時(shí)候，其他的分布式系統(tǒng)選型的時(shí)候，一般要滿足cp或者ap
- P簡單來說就是任何分布式系統(tǒng)一般都會(huì)滿足，他就是分區(qū)容錯(cuò)性；CP，C，一致性，盡可能的去保證你讀取到的數(shù)據(jù)是一致的，犧牲掉一個(gè)A，可用性，一旦leader崩潰，zk可能會(huì)有一個(gè)短時(shí)間內(nèi)，幾十s有可能，集群不可用，此時(shí)需要重新選舉一個(gè)leader，然后再做數(shù)據(jù)同步，保證數(shù)據(jù)一致性之后再開放讓你來讀取
5.eureka的原理
eureka的原理，peer-to-peer，大家都能寫也都能讀，每個(gè)節(jié)點(diǎn)都要同步給其他節(jié)點(diǎn)，但是是異步復(fù)制的，所以隨時(shí)讀任何一個(gè)節(jié)點(diǎn)，可能讀到的數(shù)據(jù)都不一樣，任何一個(gè)節(jié)點(diǎn)宕機(jī)，其他節(jié)點(diǎn)正常工作，可用性超高，但是數(shù)據(jù)一致性不行，AP
5.Nacos和Consul
Consul也是基于raft算法的CP模型
Nacos也是基于raft算法的CP模型，同時(shí)也支持配置成類似eureka的AP
總結(jié)
其實(shí)CP或者AP也都行，CP就是偶爾可能短時(shí)間不可用，AP就是可能數(shù)據(jù)不一致，兩個(gè)都有問題，但是在生產(chǎn)環(huán)境下，無論CP還是AP其實(shí)都用的很多
但是未來還是建議大家用nacos，因?yàn)閚acos的功能最為完善，包括了雪崩保護(hù)、自動(dòng)注銷實(shí)例、監(jiān)聽支持、多數(shù)據(jù)中心、跨注冊(cè)中心同步、spring cloud集成、dubbo集成、k8s集成，這些都支持，其他的幾個(gè)技術(shù)基本都支持部分罷了
