工作中對Zookeeper都是間接
比較淺
的使用，性能也沒太高的要求所以對它的缺點也沒太深的認識，從網上評價看，它還是有不少問題的。
1. 原生客戶端坑太多，Curator（Curator是Netflix公司開源的一個Zookeeper客戶端，與Zookeeper提供的原生客戶端相比，Curator的抽象層次更高，簡化了Zookeeper客戶端的開發量）今日的江湖地位一定程度要歸功於原生客戶端的難用。
2. Zookeeper的社區不太活躍，發版節奏跟etcd和consul沒法比。一些Major bug提了也給了fix patch，遲遲沒有review（如ZOOKEEPER-2101, 15年的Major bug到現在還是沒有resolved)
3. 監控工具不給力，社區除了Zimmerman大神操刀的Exhibitor，以及多年不更新的taokeeper外，沒有多少選擇；
4. Zookeeper不能保證跨session的強一致性；
5. Scalability很弱，3.5.0之前的版本修改任何配置還得要rolling update；3.5.0之后新增支持動態reconfiguration。
總結，Zookeeper最大的缺陷是：只提供基礎的操作，並且客戶端、API不好用。
Zookeeper目標實現：provide a simple and high performance kernel for building more complex coordination primitives at the client，也就是說提供更通用，更原子的原材料，而將更多的事留給使用者。
Zookeeper設計本來就是充着做協調服務的然而，協調服務是各異的，基本上沒有統一算法框架或者服務架構可言。要說最基礎的分布式協調服務的大概只有election，這個Zookeeper提供了，然而也只是Zookeeper的quorum。(HBase的election是HBase另外寫的。比較難的寫一致性問題 ，Zookeeper也幫你解了，就是zab了。實際上，Zookeeper只給你提供了一堆操作，大部分都是基於znode，還有重要的watch機制。怎么利用它來做協調服務都是要開發者自己實現。類比就是食材給你了，怎么煮你自己來。
因此，很多架構會用到Zookeeper，Hadoop, HBase, Kafka, etc.但
看下源碼，都會有獨立的package關於Zookeeper的，
里面就是各開發者的"炮制"配方。
但凡吐槽某個架構下Zookeeper的使用情景效能問題的，只能說明該架構的開發者對待“食材”，“煮”的“不太好吃”。那些都是開發者自己寫的，不是Zookeeper的鍋。覺得不ok去社區吐槽，貢獻代碼。Zookeeper其實什么都沒做。它只是提供操作而已。