SOA之路 -- 为什么Eureka比ZooKeeper更适合做服务发现与注册服务

CAP是Consistency、Availablity和Partition Tolerance的缩写。一般的分布式系统最多满足其中两条。而Partition Tolerance是分布式系统的关键，因此都会保留此特性。

Eureka是基于AP原则构建的，而ZooKeeper是基于CP原则构建的。这些可以从他们的特性中得到体现。

ZK有一个Leader，而且在Leader无法使用的时候通过Paxos（ZAB）算法选举出一个新的Leader。这个Leader的目的就是保证写信息的时候只向这个Leader写入，Leader会同步信息到Followers。这个过程就可以保证数据的一致性。

对比下ZK，Eureka不用选举一个Leader。每个Eureka服务器单独保存服务注册地址，Eureka也没有Leader的概念。这也因此产生了无法保证每个Eureka服务器都保存一直数据的特性。当Eureka与注册者心跳无法保持的时候，依然保存注册列表的信息很长一段时间。当然了，客户端中必须用有效的机制屏蔽坏掉的服务器，这个Spring Cloud中的体现是Ribbon。

Eureka因为没有选举过程来选举Leader，因此写的信息可以独立进行。因此有可能出现数据信息不一致的情况。但是当网络出现问题的时候，每台服务器也可以完成独立的服务。当然了，一些客户端的负载平衡和Fail Over机制需要来辅助完成额外的功能。相较之下，ZK因为基于CP原则，能保证很好的数据一致性，但是可用性支持力度不高。而在一个内部系统中，主要是服务的注册与发现，而不是配置（文件）共享，因此Eureka更适用于内部服务的建设。