1：zookeeper 作用
zookeeper是hadoop下的一个子项目，旨在解决大规模分布式应用场景下，服务协调同步的问题，它可以为同一个分布式系统中的其他服务提供：统一命名，配置管理，分布式锁服务，集群管理等功能。
2：zookeeper 的劣势
在分布式系统领域中有个著名的CAP定律（C-数据一致性；A-服务可用性；P-服务对网络分区故障的容错性）这三个特定在任何分布式系统中都不能同时满足，最多同事满足2个。zookeeper是CP的。即任何时刻对zookeeper的访问请求能得到一致的数据结果，同时系统对网络分区具有容错性；但是它不保证每次服务请求都是可用的。极端环境下，zookeeper会丢弃一些请求，消费者端需要重新请求才能得到结果（zookeeper为什么不设计成AP的？）。作为zookeeper的核心算法Zab（zookeeper Atomic Broadcast，全称：原子消息广播协议），就是解决了分布式系统下数据如何在多个服务之间保持同步问题的。
zookeeper 下所有节点不可能保证任何时候都能缓存所有的服务注册信息。如果zookeeper下所有的节点都断开了，或者集群中出现了网络分割的故障，那么zookeeper将会把他们从自己的管理范围内踢除，外界就不能访问到这些节点了，即使这些节点本身是健康的可以正常提供服务，所以导致到达这些节点的服务请求被丢失了。
3：Eureka的优势
在Eureka平台中，如果某台服务器宕机，Eureka不会像zookeeper选择leader的过程，客户端请求会自动切换到新的Eureka节点，当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理中，而对于它而言，所有要做的无非是同步一些新的服务注册信息。所以不用担心“掉队”的服务器恢复以后，会从Eureka服务器集群中踢除的风险。Eureka甚至被设计用来应付范围更广的网络分割故障，并实现0宕机维护需求。（多个zookeeper之间网络出现问题，造成出现多个leader，发生脑裂），当网络分割故障发生时，每个Eureka节点，会持续的对外提供服务（zookeeper不会）接收新的服务注册同时将它们提供下游的服务发现请求，这样一来，就可以实现在同一个子网中，新发布的服务仍然可以被发现与访问。
Eureka还有客户端缓存功能（Eureka分为客户端程序与服务端程序两个部分，客户端程序负责向外提供注册与发现服务接口）所以即便Eureka集群中所有节点都失效，或者发生网络分割故障导致客户端不能访问任何一台Eureka服务器；Eureka服务的消费者仍然可以通过Eureka客户端缓存来获取现有的服务注册信息。甚至最极端的环境下，所有正常的Eureka节点都不对请求产生相应，也没有更好的服务器解决方案来解决这种问题时；得益于Eureka的客户端缓存技术，消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息，这点很重要。
