微服务作为一项在云中部署应用和服务的新技术已成为当下最新的热门话题。现就微服务中注册中心的选型做一下记录。
当下实现微服务主要有两种选择，DUBBO和Spring Cloud，他们分别选择zookeeper和eureka作为注册中心。
一、什么是CAP定理
在分布式系统领域有个著名的CAP定理：C——数据一致性，A——服务可用性，P——服务对网络分区故障的容错性。这三个特性在任何分布式系统中不能同时满足，最多同时满足两个。
二、Zookeeper
Zookeeper是著名Hadoop的一个子项目，很多场景下Zookeeper也作为Service发现服务解决方案。
很多场景下Zookeeper也作为Service发现服务解决方案。Zookeeper保证的是CP，即任何时刻对Zookeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是它不能保证每次服务请求的可用性。从实际情况来分析，在使用Zookeeper获取服务列表时，如果zookeeper正在选主，或者Zookeeper集群中半数以上机器不可用，那么将就无法获得数据了。所以说，Zookeeper不能保证服务可用性。
诚然，对于大多数分布式环境，尤其是涉及到数据存储的场景，数据一致性应该是首先被保证的，这也是zookeeper设计成CP的原因。
三、Eureka
Eureka本身是Netflix开源的一款提供服务注册和发现的产品，并且提供了相应的Java封装。Eureka保证的AP，在它的实现中，节点之间是相互平等的，部分注册中心的节点挂掉也不会对集群造成影响，即使集群只剩一个节点存活，也可以正常提供发现服务。哪怕是所有的服务注册节点都挂了，Eureka Clients上也会缓存服务调用的信息。这就保证了我们微服务之间的互相调用是足够健壮的。
对于服务发现场景来说：针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。因为对于服务消费者来说，能消费才是最重要的——拿到可能不正确的服务实例信息后尝试消费一下，也好过因为无法获取实例信息而不去消费。
所以，对于服务发现而言，可用性比数据一致性更加重要——AP胜过CP。