为什么不使用ZooKeeper构建云平台发现服务.docxVIP

为什么不使用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，会产生不同的问题以及不同的解决方式。当你实际使用时你就会明白，但是，你最好提前应对它们(注：指的是上一节说的意外故障、高延迟与网络分割问题)的发生。ZooKeeper作为发现服务的问题ZooKeeper(注：ZooKeeper是著名Hadoop的一个子项目，旨在解决大规模分布式应用场景下，服务协调同步(Coordinate Service)的问题;它可以为同在一个分布式系统中的其他服务提供：统一命名服务、配置管理、分布式锁服务、集群管理等功能)是个伟大的开源项目，它很成熟，有相当大的社区来支持它的发展，而且在生产环境得到了广泛的使用;但是用它来做Service发现服务解决方案则是个错误。在分布式系统领域有个著名的 CAP定理(C- 数据一致性;A-服务可用性;P-服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个);ZooKeeper是个 CP的，即任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性;但是它不能保证每次服务请求的可用性(注：也就是在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果)。但是别忘了，ZooKeeper是分布式协调服务，它的职责是保证数据(注：配置数据，状态数据)在其管辖下的所有服务之间保持同步、一致;所以就不难理解为什么ZooKeeper被设计成CP而不是AP特性的了，如果是AP的，那么将会带来恐怖的后果(注：ZooKeeper就像交叉路口的信号灯一样，你能想象在交通要道突然信号灯失灵的情况吗?)。而且，作为ZooKeeper的核心实现算法Zab，就是解决了分布式系统下数据如何在多个服务之间保持同步问题的。作为一个分布式协同服务，ZooKeeper非常好，但是对于Service发现服务来说就不合适了;因为对于Service发现服务来说就算是返回了包含不实的信息的结果也比什么都不返回要好;再者，对于Service发现服务而言，宁可返回某服务5分钟之前在哪几个服务器上可用的信息，也不能因为暂时的网络故障而找不到可用的服务器，而不返回任何结果。所以说，用ZooKeeper来做Service发现服务是肯定错误的，如果你这么用就惨了!而且更何况，如果被用作Service发现