首先，那么為什么說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