Eureka! Why You Shouldn’t Use ZooKeeper for Service Discovery

Eureka! Why You Shouldn’t Use ZooKeeper for Service Discovery(未翻译完成)

Written by Peter Kelley
原文链接

许多公司使用ZooKeeper作为服务发现。在Knewton，我们认为这是一个根本上有缺陷的方法。在本文中我将会介绍在使用ZooKeeper上的事故，告诉您为什么不应该将它用于服务发现，并解释为什么Eureka是更好的解决方案。

记住你正在构造的是什么（Remember What You’re Building On）

让我们回过来。当你决定用什么软件或者构造自己的软件之前，首先最重要的是要讨论的是用什么样的目标环境。在云平台中，设备的弹性和网络故障是主要需要考虑的。当你通过大量的可替换硬件来运行你的软件时，在其中一个硬件的某些时候回发生故障是不可避免的。在Knewton，我们运行在AWS上，而且我们遇到过很多不同类型的故障。你需要设计好你的系统可能出现的故障。软件运行在AWS上的其他公司也同意这一观点。您必须预测机箱故障，高延迟和网络分区-并在你的系统中构建针对它们的弹性
不要认为您的环境与其他人的相同。当然，如果您在运维您自己的数据中心，那么您很可能会投入时间和金钱去最小化硬件故障和网络分区。但是，像AWS这样的云环境做出了不同的权衡。你将会遇到这些问题，你最好为它们做好准备。

使用ZooKeeper的故障（Failures with ZooKeeper）

ZooKeeper是一个很棒的软件项目。它已经成熟，已经有一个大型的社区支持，并且被很多团队用于生产。但它是解决服务发现问题的错误方案。
在CAP术语中，ZooKeeper表示CP，这意味着它在分区面前是一致的，不可用。对于ZooKeeper所做的很多事情，这是一个必要的权衡。由于ZooKeeper首先是协调服务，因此具有最终一致的设计(即AP)将会是一个很可怕的设计决策。因此它的核心共识性算法Zab就是一致性。

反馈与建议

如有翻译错误之处，欢迎指正。
- 邮箱：alpherkingsly@sina.com.cn

---

感谢阅读这份文档