注册中心——Zookeeper、Eureka孰优孰劣

最近在看Dubbo的源码和基本原理，看得我一脸懵逼、不知所以然。回忆起之前学习Spring Cloud的时候，也是同样的体会，可能这就是学习新知识、接触新领域的必经阶段吧。我觉得，学习新知识并不是“洗脑”学习，而是通过比较以往经验教训，对比加深理解，所以就挑了“注册中心”作为学习的切入点，在此基础上逐步去理解微服务架构，也是为了避免直接阅读调试源码容易带来的厌烦感。本篇文章参考了其他博主的文章，具体参考文章如下：

Spring Cloud：Zookeeper和Eureka的区别在哪？
对于注册中心，ZooKeeper、Eureka哪个更合适？

1、CAP原理

接触注册中心，需要事先了解下CAP原理，以下引用百度百科

CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

• 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
• 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
• 分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。Eureka遵循着AP原则，Zookeeper遵循着CP原则。对于分布式系统，分区容忍性是必须要实现的，所以一致性和可用性需要根据实际业务情况进行取舍。

2、Zookeeper

Zookeeper遵循CP，也就是说，无论何时Zookeeper的访问请求都要得到一致性的数据反馈，并且系统对网络分割具备容错性，但不能够保证每次服务访问请求的可用性。但要注意一点，Zookeeper不是强一致。举个例子，客户端A提交一个写操作，Zookeeper在超过半数节点操作成功后就可以返回，但如果客户端B同时发起读请求客户端A尚未同步到的节点，那么客户端B读取的就是A最新提交的数据。所以如果为了强一致，需要客户端B在发起读请求之前，先执行一下sync，与leader节点先同步数据再去读取客户端A的数据。

说到leader节点，这恰好是Zookeeper的一个缺点，当master节点因为网络故障与其他节点失去联系，其他节点会重新进行leader节点选举，如果恰巧选举时间过长，整个Zookeeper集群会处于瘫痪状态。就实际使用场景来说，涉及到数据存储的分布式环境，一致性（C）肯定是首选保证的，但作为服务注册中心，从服务发现角度去看，可用性（A）反而是首选。因为作为服务消费者，能消费才是最重要的。从这几年的双十一来看，AP确实优于CP。

3、Eureka

Eureka遵循的是AP原则。相较于Zookeeper的选举leader过程，Eureka采用Peer To Peer对等通信。是一种去中心化架构，没有master和slave区分，每一个Peer都是对等的。这种架构中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的serviceUrl指向其他节点。

假设某个Eureka服务器宕机了，Eureka Client的请求会自动切换到新的Eureka Server节点，当宕机的服务器恢复后，Eureka会再次将其纳入服务器集群管理之中。当节点开始接受客户端请求时，所有操作都会进行节点复制操作，将请求复制到其他Eureka Server的所有节点中。

并且Eureka有一种自我保护机制，如果在15mins内超过85%的节点都没有正常的ping心跳，那么Eureka就认定客户端和注册中心出现了网络故障。出现以下几种情况：

• Eureka不再从注册列表中溢出，因为长时间没有收到ping心跳而应该过期的服务
• Eureka仍然能够接受心服务的注册和查询请求，但不会被同步到其他节点上，也就是保证当前节点依然可用
• 网络稳定后，当前实例新的注册信息将会被同步到其他节点中
  因此，相较于Zookeeper那样整个注册服务瘫痪，Eureka可以很好应对网络故障引发的部分节点失去联系的情况。

小结

理论上说，无论是从服务注册角度，还是网络故障处理角度，Eureka更适合做注册中心，但国内开发环境，大部分项目还会使用Zookeeper，主要还是因为集群还不够大，并且基本不会遇到充当注册中心的机器一半以上宕机的情况，综合考虑成本，Zookeeper使用也没什么问题。