引用文章
对于注册中心,ZooKeeper、Eureka哪个更合适?
我理解的注册中心是提供服务发现功能,服务检查上线下线的中间件,能支持动态服务上下线,并推送ip列表变化到客户端的注册中心服务。
所以它要记录的数据模型:
- 服务名
- ip
- 上下线状态
- 权重
我们先理解ZooKeeper、Eureka是什么服务,第二:ZooKeeper、Eureka对这需求实现。
在分布式系统中有个著名的CAP定理(C-数据一致性;A-服务可用性;P-服务对网络分区故障的容错性,这三个特性在任何分布式系统中不能同时满足,最多同时满足两个);
ZooKeeper
- ZooKeeper 是一个开源的分布式协调服务。
- 采用master slave架构。
- 采用ZAB协议虽然保证了数据的强一致。
- 基于CP来设计的,任何时刻对Zookeeper的访问请求能得到一致的数据结果,同时系统对网络分割具备容错性,但是它不能保证每次服务请求的可用性。 A 可用性不能保证,比如获取服务列表时候,zk正在选举则服务不可用。
- Zookeeper没有针对服务发现设计数据模型,它的数据是以一种更加抽象的树形K-V组织的,因此理论上可以存储任何语义的数据。
Eureka
- Eureka本身是Netflix开源的一款提供服务注册和发现的产品。
- 设计Eureka时遵守的就是AP原则,即保证可用性和容错性。
- 采用的是Peer to Peer对等通信。这是一种去中心化的架构,无master/slave区分,每一个Peer都是对等的。
- 心跳检查机制,Eureka client 发送心跳给Eureka Server ,让其了解服务状态。Eureka server 收到请求后完成该服务的续约,如果Eureka Server在一定时间内(默认90秒)没有接收到某个微服务实例的心跳,Eureka Server将会移除该实例。
- 数据模型Eureka做到了实例级别的数据扩展。
基于以上几点,我们对比发现, Zookeeper本身并不能很善于完成注册中心的功能。
- 现有流行的分布式架构Zookeeper+dubbo 组合,需要dubbo框架完善。 也仅是利用Zookeeper的临时节点,需要定时发送心跳给zookeeper 节点续约,并允许服务下限,摘除不可用的服务。
- 数据模型是更加抽象的树形KV组织,需要技术人员再定义数据模型。
- 一旦master节点宕机,它的不能保证可用。