爲何阿里的dubbo註冊中心要放棄zookeeper, 而用Nacos？

首先，那麼爲何說zookeeper不適合作服務註冊中心呢？

 

從CAP角度來看

有個思考，從CAP角度考慮，服務註冊中心是CP系統仍是AP系統呢？

 

首先，服務註冊中心是爲了服務間調用服務的，那麼絕對不容許由於服務註冊中心出現了問題而致使服務間的調用出問題。

再者， 假若有node1,node2,node3,集羣節點。 保存着可用服務列表ip1，ip2，ip3，試想若是此時不一致，好比node1只保存了ip1,ip2，此時服務讀取node1的節點，那麼會形成什麼影響？

調用node1的服務，頂多就是負載均衡時不會有流量打到ip3， 而後等 node1同步回ip3後，又一致了，這對服務其實沒什麼太大影響。

因此，推出服務註冊中心應該是個AP系統。

 

 

zookeeper是個CP系統，強一致性。

 

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

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

場景2， 分區可用。試想，有3個機房，若是其中機房3和機房1，2網絡斷了， 那麼機房3的註冊中心就不能註冊新的機器了麼，這顯然也不合理

從健康檢查來看

 

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

但TCP的活性並不表明服務是可用的，但TCP活性就說明服務是可用的麼，答案顯然是否認的，如： 鏈接池已經滿了，DB掛了等

 

 

那麼理想的註冊中心是什麼樣的呢，思考下

 

1， 起碼服務的自動註冊，發現。 最好有新的服務註冊上去時還能推送到調用端

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

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

4， 若是再好點，能夠看到是否有其餘調用服務正在訂閱註冊上來的服務

5，若是可以帶上些除了IP外的其它信息，那就更好了

--------------------------------------------------------------

 

2019. 1.22

一段時間後，補充點想法

ZooKeeper其實比我想象的還要更多瓶頸，最近有遇到說下

1. ZooKeeper寫是不可擴展的，當註冊節點必定時，寫性能會是瓶頸，發佈應用時出現排隊現象，表現出來的現象就是，應用的啓動變得十分緩慢

2. ZooKeeper不支持跨機房的路由，不像eureka，有zone的概念，優先本地路由，當本機房路由，當本機房出現問題時，能夠路由到另外一個機房

3. ZooKeeper當節點過多時，若是有服務節點變動，須要同時通知機器，會發生「驚羣效應」， 瞬間打滿網卡，且容易重複通知

 

----------------------------

關於 Nacos

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

 

歡迎關注下個人公衆號， JVM和微服務方面