我理解的注册中心是提供服务发现功能，服务检查上线下线的中间件，能支持动态服务上下线，并推送ip列表变化到客户端的注册中心服务。
所以它要记录的数据模型：

  • 服务名
  • ip
  • 上下线状态
  • 权重

我们先理解ZooKeeper、Eureka是什么服务，第二：ZooKeeper、Eureka对这需求实现。

在分布式系统中有个著名的CAP定理（C-数据一致性；A-服务可用性；P-服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个）；

ZooKeeper

  1. ZooKeeper 是一个开源的分布式协调服务。
  2. 采用master slave架构。
  3. 采用ZAB协议虽然保证了数据的强一致。
  4. 基于CP来设计的，任何时刻对Zookeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是它不能保证每次服务请求的可用性。 A 可用性不能保证，比如获取服务列表时候，zk正在选举则服务不可用。
  5. Zookeeper没有针对服务发现设计数据模型，它的数据是以一种更加抽象的树形K-V组织的，因此理论上可以存储任何语义的数据。

Eureka

  1. Eureka本身是Netflix开源的一款提供服务注册和发现的产品。
  2. 设计Eureka时遵守的就是AP原则，即保证可用性和容错性。
  3. 采用的是Peer to Peer对等通信。这是一种去中心化的架构，无master/slave区分，每一个Peer都是对等的。
  4. 心跳检查机制，Eureka client 发送心跳给Eureka Server ，让其了解服务状态。Eureka server 收到请求后完成该服务的续约，如果Eureka Server在一定时间内（默认90秒）没有接收到某个微服务实例的心跳，Eureka Server将会移除该实例。
  5. 数据模型Eureka做到了实例级别的数据扩展。

基于以上几点，我们对比发现， Zookeeper本身并不能很善于完成注册中心的功能。

  1. 现有流行的分布式架构Zookeeper+dubbo 组合，需要dubbo框架完善。 也仅是利用Zookeeper的临时节点，需要定时发送心跳给zookeeper 节点续约，并允许服务下限，摘除不可用的服务。
  2. 数据模型是更加抽象的树形KV组织，需要技术人员再定义数据模型。
  3. 一旦master节点宕机，它的不能保证可用。