首先，那么為什么說zookeeper不適合做服務注冊中心呢？

從CAP角度來看

有個思考，從CAP角度考慮，服務注冊中心是CP系統(tǒng)還是AP系統(tǒng)呢？

首先，服務注冊中心是為了服務間調(diào)用服務的，那么絕對不允許因為服務注冊中心出現(xiàn)了問題而導致服務間的調(diào)用出問題。

再者， 假如有node1,node2,node3,集群節(jié)點。 保存著可用服務列表ip1，ip2，ip3，試想如果此時不一致，比如node1只保存了ip1,ip2，此時服務讀取node1的節(jié)點，那么會造成什么影響？

調(diào)用node1的服務，頂多就是負載均衡時不會有流量打到ip3， 然后等 node1同步回ip3后，又一致了，這對服務其實沒什么太大影響。

所以，推出服務注冊中心應該是個AP系統(tǒng)。

zookeeper是個CP系統(tǒng)，強一致性。

場景1， 當master掛了，此時，zookeeper集群需要重新選舉，而此時服務需要來讀取可用服務，是不可用的。 影響到了服務的可用性

當然你可以說服務本地有緩存可用列表。然而下面這種方式就更無法處理了。

場景2， 分區(qū)可用。試想，有3個機房，如果其中機房3和機房1，2網(wǎng)絡斷了， 那么機房3的注冊中心就不能注冊新的機器了么，這顯然也不合理

從健康檢查來看

zookeeper是通過TCP的心跳判斷服務是否可用

但TCP的活性并不代表服務是可用的，但TCP活性就說明服務是可用的么，答案顯然是否定的，如： 連接池已經(jīng)滿了，DB掛了等

那么理想的注冊中心是什么樣的呢，思考下

1， 起碼服務的自動注冊，發(fā)現(xiàn)。 最好有新的服務注冊上去時還能推送到調(diào)用端

2， 能對注冊上來的機器方便的進行管理，能手工剔除（發(fā)送信號讓服務優(yōu)雅下線）、恢復機器

3，服務的健康檢查，能真正的檢測到服務是否可用

4， 如果再好點，可以看到是否有其他調(diào)用服務正在訂閱注冊上來的服務

5，如果能夠帶上些除了IP外的其它信息，那就更好了

關于 Nacos

https://yq.aliyun.com/articles/604028

歡迎關注下我的公眾號， JVM和微服務方面