ZooKeeper是Apache基金会下的一个开源的、高可用的分布式应用协调服务。许多公司都把它用于服务发现。但在云环境中，面对设备及网络故障时的恢复能力是需要重点考虑的问题。因此，将应用部署在云上，就必须要预见到硬件故障、网络延迟以及网络分区等问题，进而构建出恢复能力强的系统。Peter Kelley是个性化教育初创公司Knewton的一名软件工程师。他认为，从根本上讲，把ZooKeeper用于服务发现是个错误的做法，理由如下：
在ZooKeeper中，网络分区中的客户端节点无法到达Quorum时，就会与ZooKeeper失去联系，从而也就无法使用其服务发现机制。因此，在用于服务发现时，ZooKeeper无法很好地处理网络分区问题。作为一个协调服务，这没问题。但对于服务发现来说，信息中可能包含错误要好于没有信息。虽然可以通过客户端缓存和其它技术弥补这种缺陷，像Pinterest和Airbnb等公司所做的那样，但这并不能从根本上解决问题，如果Quorum完全不可用，或者集群分区和客户端都恰好连接到了不属于这个Quorum但仍然健康的节点，那么客户端状态仍将丢失。
更重要地，上述做法的本质是试图用缓存提高一个一致性系统的可用性，即在一个CP系统之上构建AP系统，这根本就是错误的方法。服务发现系统从设计之初就应该针对可用性而设计。
抛开CAP理论不说，ZooKeeper的设置和维护非常困难，以致Knewton多次因为错误的使用出现问题。一些看似很简单的事情，实际操作起来也非常容易出错，如在客户端重建Watcher，处理Session和异常。另外，ZooKeeper本身确实也存在一些问题，如ZOOKEEPER-1159、ZOOKEEPER-1576。
Read full article from 为什么不要把ZooKeeper用于服务发现
No comments:
Post a Comment