为什么用Eureka不用ZooKeeper

为什么不应该使用ZooKeeper做服务发现
【编者的话】本文作者通过ZooKeeper与Eureka作为Service发现服务（注：WebServices体系中的UDDI就是个发现服务）的优劣对比，分享了Knewton在云计算平台部署服务的经验。本文虽然略显偏激，但是看得出Knewton在云平台方面是非常有经验的，这篇文章从实践角度出发分别从云平台特点、CAP原理以及运维三个方面对比了ZooKeeper与Eureka两个系统作为发布服务的优劣，并提出了在云平台构建发现服务的方法论。
背景
很多公司选择使用ZooKeeper作为Service发现服务（Service Discovery），但是在构建Knewton（Knewton是一个提供个性化教育平台的公司、学校和出版商可以通过Knewton平台为学生提供自适应的学习材料）平台时，我们发现这是个根本性的错误。在这边文章中，我们将用我们在实践中遇到的问题来说明，为什么使用ZooKeeper做Service发现服务是个错误。
请留意服务部署环境
让我们从头开始梳理。我们在部署服务的时候，应该首先考虑服务部署的平台（平台环境），然后才能考虑平台上跑的软件系统或者如何在选定的平台上自己构建一套系统。例如，对于云部署平台来说，平台在硬件层面的伸缩（注：作者应该指的是系统的冗余性设计，即系统遇到单点失效问题，能够快速切换到其他节点完成任务）与如何应对网络故障是首先要考虑的。当你的服务运行在大量服务器构建的集群之上时（注：原话为大量可替换设备），则肯定会出现单点故障的问题。对于knewton来说，我们虽然是部署在AWS上的，但是在过往的运维中，我们也遇到过形形色色的故障；所以，你应该把系统设计成“故障开放型”（expecting failure）的。其实有很多同样使用AWS的公司跟我们遇到了（同时有很多书是介绍这方面的）相似的问题。你必须能够提前预料到平台可能会出现的问题如：意外故障（注：原文为box failure，只能意会到作者指的是意外弹出的错误提示框），高延迟与网络分割问题（注：原文为network partitions。意思是当网络交换机出故障会导致不同子网间通讯中断）——同时我们要能构建足够弹性的系统来应对它们的发生。

永远不要期望你部署服务的平台跟其他人是一样的！当然，如果你在独自运维一个数据中心，你可能会花很多时间与钱来避免硬件故障与网络分割问题，这是另一种情况了；但是在云计算平台中，如AWS，会产生不同的问题以及不同的解决方式。当你实际使用时你就会明白，但是，你最好提前应对它们（