三个服务注册中心对比

首先，先说明服务注册中心解决的问题
服务注册和服务发现

• 服务注册：服务实例将自身服务信息注册到注册中心。这部分服务信息包括服务所在主机IP和提供服务的Port，以及暴露服务自身状态以及访问协议等信息。
• 服务发现：服务实例请求注册中心获取所依赖的服务信息。服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求他们提供的服务。

除了这两个核心功能外，一般服务注册中心还需要监控服务实例的运行状态，负载均衡等问题。

• 监控：服务实例一直处于动态的变化中，因此我们需要监控服务实例的健康状况，从注册中心剔除无用的服务。一般实现心跳连接等。
• 负载均衡：在一个服务有多个实例的情况下，我们需要根据负载君更策略正确处理请求。

CAP原则
分布式有一个重要的理论，那就是CAP原则，指的是在一个分布式系统中，Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性），不能同时成立。

• 一致性：它要求在同一时刻点，分布式系统中的所有数据备注都处于同一状态。
• 可用性：在系统集群的一部分节点宕机后，系统已然能够响应用户的请求。
• 分区容错性：在网络区间通信出现失败，系统能够容忍。

一般来说，基于网络本身的不稳定性，分布容错是不可避免的，所以我们默认CAP中的P总是成立的。一致性的强制数据统一要求，必然会导致在更新数据时部分节点处于被锁定的状态，此时不可对外提供服务，影响了服务的可用性，反之亦然，因此一致性和可用性不能同时满足。在注册中心的发展上，一直有两个分支：一个是CP系统，追求数据的强一致性。还有一个是AP系统，追求高可用与最终一样。Eureka满足AP，Consul和Zookeeper满足CP。

Eureka

Eureka是在Java语言上，基于Restful Api开发的服务注册与发现组件，由Netflix开源。遗憾的是，目前Eureka仅开源到1.X版本，2.X版本已经停止开发。
Eureka由两个组件组成:Eureka服务器和Eureka客户端。Eureka服务器用作服务注册服务器。Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。Netflix在其生产环境中使用的是另外的客户端，它提供基于流量、资源利用率以及出错状态的加权负载均衡。
Spring Cloud封装了Netflix公司开发的Eureka模块来实现服务注册和发现。Eureka采用了C-S的设计架构。
Eureka Server作为服务注册功能的服务器，它是服务注册中心。而系统中的其他微服务，使用Eureka的客户端连接到Eureka Server,并维持心跳连接。这样系统的维护人员就可以通过Eureka Server来监控系统中各个微服务是否正常运行。Spring Cloud的一些其他模块（比如Zuul)就可以通过Eureka Server来 发现系统中的其他微服务，并执行相关的逻辑。

上图来自Eureka的官方架构图，大致描述了Eureka集群的工作过程，图中包含的组件非常多，我们来理解一下。

• Application Service:作为Eureka Client，扮演了服务的提供者，提供业务服务，向Eureka Server注册和更新自己的信息，同时能从Eureka Server的注册表中获取到其他服务的信息。
• Eureka Server:扮演服务注册中心的角色，提供服务注册和发现的功能，每个Eureka Cient向Eureka Server注册自己的信息，也可以通过Eureka Server获取到其他服务的信息达到发现和调用其他服务的目的。
• . Application Client: 作为Eureka Client，扮演了服务消费者，通过Eureka Server获取到注册到上面的其他服务的信息，从而根据信息找到所需的服务发起远程调用。
• Replicate: Eureka Server中的注册表信息的同步拷贝，保持不同的Eureka Server集群中的注册表中的服务实例信息的一致性。提供了数据的最终一致性。
• Make Remote Call:服务之间的远程调用。
• Register:注册服务实例，Client端向Server端注册自身的元数据以进行服务发现。
• Renew:续约，通过发送心跳到Server维持和更新注册表中的服务实例元数据的有效性(默认周期为30秒)。当在一定时长内Server没有收到Client的心跳信息（(默认90秒)，将默认服务下线，将服务实例的信息从注册表中删除。
• Cancel:服务下线，Client在关闭时主动向Server注销服务实例元数据，这时Client的的服务实例数据将从Server的注册表中删除。

最后我们需要注意的Eureka的缓存机制。Eureka Client会缓存Eureka Server中的信息。即使所有的Eureka Server节点都宕掉，服务消费者依然可以使用缓存中的信息找到服务提供者。Ereka Client客户端默认每30秒发送一次请求来更新缓存的注册信息。如果你并不是在Spring Cloud环境下使用这些组件(Eureka,Ribbon)，你的服务启动后并不会马上向Eureka注册，而是需要等到第一次发送心跳请求时才会注册。心跳请求的发送间隔也是30s。(Spring Cloud对此做了修改，服务启动后会马上注册)

Zookeeper

ZooKeeper 是一个开源的分布式协调服务，由雅虎创建，是 Google Chubby 的开源实现。 分布式应用程序可以基于ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协 调/通知、集群管理、Master选举、配置维护，名字服务、分布式同步、分布式锁和分布式队列 等功能。为了保证高可用，最好是以集群形态来部署ZooKeeper，这样只要集群中大部分机器是可用的（能够容忍一定的机器故障），那么 ZooKeeper 本身仍然是可用的。客户端在使用ZooKeeper 时，需要知道集群机器列表，通过与集群中的某一台机器建立 TCP 长连接来使用服务。客户端使用这个 TCP链接来发送请求、获取结果、获取监听事件以及发送心跳包。如果这个连接异常断开了，客户端可以连接到另外的机器上。

上图是ZooKeeper 官方提供的架构图，图中每一个 Server 代表一个安装 ZooKeeper 服务的服务器。组成 ZooKeeper 服务的服务器都会在内存中维护当前的服务器状态，并且每台服务器之间都互相保持着通信。集群间通过 Zab 协议（Zookeeper AtomicBroadcast）来保持数据的一致性。对于来自客户端的每个更新请求，ZooKeeper 都会分配一个全局唯一的递增编号。这个编号反应了所有事务操作的先后顺序，应用程序可以使用 ZooKeeper 这个特性来实现更高层次的同步原语。这个编号也叫做时间戳—zxid（ZooKeeper Transaction Id）。

最典型集群模式：Master/Slave 模式（主备模式）。在这种模式中，通常 Master 服务器作为主服务器提供写服务，其他的 Slave 服务器从服务器通过异步复制的方式获取 Master 服务器最新的数据提供读服务。但是，在 ZooKeeper 中没有选择传统的 Master/Slave 概念，而是引入了Leader、Follower 和 Observer 三种角色。如下图所示：

• ZooKeeper 集群中的所有机器通过一个 Leader 选举过程来选定一台称为 “Leader” 的机器。
• Leader 既可以为客户端提供写服务又能提供读服务。除了 Leader 外，Follower 和 Observer 都只能提供读服务
• Server：Server中存在两种类型：Follower和Observer。其中Follower接受客户端的请求并返回结果(事务请求将转发给Leader处理)，并在选举过程中参与投票；Observer与Follower功能一致，唯一的区别在于 Observer 机器不参与 Leader 的选举过程，也不参与写操作的“过半写成功”策略，因此 Observer 机器可以在不影响写性能的情况下提升集群的读性能。
• Client：请求发起方，Server和Client之间可以通过长连接的方式进行交互。如发起注册或者请求集群信息等。
• 集群间通过 Zab 协议（Zookeeper Atomic Broadcast）来保持数据的一致性。

Zab协议

ZAB（ZooKeeper Atomic Broadcast 原子广播）协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。ZAB 协议包括两种基本的模式，分别是崩溃恢复和消息广播。

当整个服务框架在启动过程中，或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进入恢复模式并选举产生新的 Leader 服务器。当选举产生了新的 Leader 服务器，同时集群中已经有过半的机器与该 Leader 服务器完成了状态同步之后，ZAB 协议就会退出恢复模式。其中，所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和 Leader 服务器的数据状态保持一致。当集群中已经有过半的 Follower 服务器完成了和 Leader 服务器的状态同步，那么整个服务框架就可以进人消息广播模式了。当一台同样遵守 ZAB 协议的服务器启动后加入到集群中时，如果此时集群中已经存在一个 Leader 服务器在负责进行消息广播。那么新加入的服务器就会自觉地进人数据恢复模式：找到 Leader 所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。正如上文介绍中所说的，ZooKeeper 设计成只允许唯一的一个 Leader 服务器来进行事务请求的处理。Leader 服务器在接收到客户端的事务请求后，会生成对应的事务提案并发起一轮广播协议。而如果集群中的其他机器接收到客户端的事务请求，那么这些非 Leader 服务器会首先将这个事务请求转发给 Leader 服务器。

consul

Consul是HashiCorp公司推出的开源工具，基于Go语言开发的支持多数据中心分布式高可用的服务发布和注册服务软件，采用Raft算法保证服务的一致性，且支持健康检查。因为通过Golang实现，因此具有天然可移植性(支持Linux、windows和Mac OS X)；安装包仅包含一个可执行文件，方便部署，与Docker等轻量级容器可无缝配合。Consul采用主从模式的设计，使得集群的数量可以大规模扩展，集群间通过RPC的方式调用(HTTP和DNS)。它的结构图如下所示：

• Client：作为一个代理(非微服务实例)，它将转发所有的RPC请求到Server中。作为相对无状态的服务，它不持有任何注册信息。
• Server：作为一个具备扩展功能的代理，它将响应RPC查询、参与Raft选举、维护集群状态和转发查询给Leader等。
• Leader-Server：一个数据中心的所有Server都作为Raft节点集合的一部分。其中Leader将负责所有的查询和事务(如服务注册)，同时这些事务也会被复制到所有其他的节点。
• Data Center：数据中心作为一个私有的，低延迟和高带宽的一个网络环境。每个数据中心会存在Consul集群，一般建议Server是3-5台(考虑到Raft算法在可用性和性能上取舍)，而Leader只能唯一，Client的数量没有限制，可以轻松扩展。Consul 通过 WAN 的 Gossip 协议，完成跨数据中心的同步；而且其他的产品则需要额外的开发工作来实现。

总结
下面是这三个服务注册中心的特性对比， 没有最好的服务中心， 只有最合适的，我们可以根据项目的实际情况来进行选择。