工作中对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其实什么都没做。它只是提供操作而已。