首先，那麼為什麼說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和微服務方面
