1. 著名的CAP理论指出，在分布式系统中，一致性（C）、可用性（A）和分区容错性（P）三者不可能同时得到满足。由于分区容错性是分布式系统必须保证的，因此我们通常需要在A和C之间做出权衡。Zookeeper倾向于保证CP，而Eureka则更偏向于AP。
2. 在查询服务列表时，我们可以容忍注册中心返回的是几分钟前的信息，但不能接受服务直接宕机。换句话说，服务注册的可用性要求高于一致性。然而，Zookeeper在master节点与其它节点失去联系时，需要重新进行leader选举，这个过程可能持续30到120秒，而且在这期间整个Zookeeper集群都是不可用的。这在云环境中的网络问题导致的master节点失联是较常发生的情况，这样的选举过程对注册服务的长期不可用性是不能接受的。
3. Eureka理解到了这一点，因此在设计时优先考虑了可用性。Eureka的各个节点都是平等的，一些节点的故障不会影响到其他正常节点的工作，剩余的节点仍然可以提供注册和查询服务。Eureka的客户端在遇到连接失败的节点时，会自动切换到其他节点，只要还有一台Eureka在运行，就能提供注册服务（保证可用性），尽管可能无法获取到最新的信息（不保证强一致性）。
4. Eureka还具备一种自我保护机制，如果在15分钟内超过85%的节点没有正常的心跳，Eureka会认为客户端与注册中心的网络出现了问题。在这种情况下，Eureka不会删除长时间没有心跳应该过期的服务，仍然可以接受新服务的注册和查询请求，但不会同步到其他节点（保证当前节点可用）。当网络稳定后，新的注册信息会被同步到其他节点。
5. 因此，Eureka能更有效地应对因网络问题导致的节点失联情况，而不会像Zookeeper那样导致整个注册服务瘫痪。作为专门的服务注册中心，Eureka更加注重可用性，我们可以在短期内接受不一致性。不过，Eureka目前1.X版本是基于servlet的Java Web应用，其性能受限。期待正在开发的2.X版本能够独立于servlet，成为可以独立部署的服务。