常用注册中心原理及比较

        目前比较常用的注册中心有Eureka、Zookeeper、Consul和Nacos。最近对这四种注册中心的整体框架和实现进行了学习，并主要针对Nacos从源码角度学习了服务注册和订阅的具体实现。最后比较了这四种注册中心的区别。

一．Eureka

• 左上角的Eureka Client是服务提供者：向Eureka Server注册和更新自己的信息，同时能从Eureka Server注册表中获取到其他服务的信息。具体有以下四种操作： 
• Register注册：Client端向Server端注册自身的元数据以供服务发现；
• Renew续约：通过发送心跳到Server以维持和更新注册表中服务实例元数据的有效性。当在一定时长内，Server没有收到Client的心跳信息，将默认服务下线，会把服务实例的信息从注册表中删除； 
• Cancel下线：Client在关闭时主动向Server注销服务实例元数据，这时Client的服务实例数据将从Server的注册表中删除；
• Get Registry获取注册表：Client向Server请求注册表信息，用于服务发现，从而发起服务间远程调用。
• Eureka Server服务注册中心：提供服务注册和发现的功能。每个Eureka Client向Eureka Server注册自己的信息，也可以通过Eureka Server获取到其他服务的信息达到发现和调用其他服务的目的。
• Eureka Client服务消费者：通过Eureka Server获取注册到其上其他服务的信息，从而根据信息找到所需的服务发起远程调用。
• Replicate同步复制：Eureka Server之间注册表信息的同步复制，使Eureka Server集群中不同注册表中服务实例信息保持一致。由于集群间的同步复制是通过HTTP的方式进行，基于网络的不可靠性，集群中的Eureka Server间的注册表信息难免存在不同步的时间节点，不满足CAP中的C(数据一致性)。
• Make Remote Call远程调用：服务客户端之间的远程调用。

二．Zookeeper

2.1 Zookeeper整体框架

• Leader：zookeeper 集群工作的核心，事务请求（写操作）的唯一调度和处理者，保证集群事务处理的顺序性；集群内部各个服务的调度者。 对于 create，set data，delete 等有写操作的请求，则需要统一转发给 leader 处理，leader 需要决定编号、执行操作，这个过程称为一个事务。
• Follower：处理客户端非事务（读操作）请求 转发事务请求给 Leader 参与集群 leader。 
• Observer：观察者角色是针对访问量较大的 zookeeper 集群新增的角色。观察zookeeper集群的最新状态变化并将这些状态同步过来，其对于非事务请求可以进行独立处理，对于事务请求，则会转发给Leader服务器处理。不会参与任何形式的投票只提供服务，通常用于在不影响集群事务处理能力的前提下提升集群的非事务处理能力，用于增加并发的请求。

2.2 Zookeeper存储结构

        下图描述了用于内存表示的ZooKeeper文件系统的树结构。ZooKeeper节点称为 znode。每个znode由一个名称标识，并用路径(/)序列分隔。在图中，首先有一个由“/”分隔的znode。在根目录下有两个逻辑命名空间 config 和 workers 。config 命名空间用于集中式配置管理，workers 命名空间用于命名。 

        在config命名空间下，每个znode最多可存储1MB的数据。这与UNIX文件系统相类似，除了父znode也可以存储数据。这种结构的主要目的是存储同步数据并描述znode的元数据。此结构称为 ZooKeeper数据模型。ZooKeeper命名空间中的每个节点都由路径标识。

        znode兼具文件和目录两种特点。既像文件一样维护着数据长度、元信息、ACL、时间戳等数据结构，又像目录一样可以作为路径标识的一部分：

• 版本号 - 每个znode都有版本号，这意味着每当与znode相关联的数据发生变化时，其对应的版本号也会增加。当多个zookeeper客户端尝试在同一znode上执行操作时，版本号的使用就很重要。
• 操作控制列表(ACL) - ACL基本上是访问znode的认证机制。它管理所有znode读取和写入操作。

• 时间戳 - 时间戳表示创建和修改znode所经过的时间。它通常以毫秒为单位。ZooKeeper从“事务ID"(zxid)标识znode的每个更改。Zxid 是唯一的，并且为每个事务保留时间，以便你可以轻松地确定从一个请求到另一个请求所经过的时间。
• 数据长度 - 存储在znode中的数据总量是数据长度。最多可以存储1MB的数据。

        ZooKeeper还具有短暂节点的概念。只要创建znode的会话处于活动状态，这些znode就存在。会话结束时，将删除znode。

2.3 Zookeeper监视功能

        ZooKeeper支持watch的概念，客户端可以在znode上设置观察。znode更改时，将触发并删除监视。触发监视后，客户端会收到一个数据包，说明znode已更改。如果客户端和其中一个ZooKeeper服务器之间的连接断开，则客户端将收到本地通知。3.6.0中的新增功能：客户端还可以在znode上设置永久性的递归监视，这些监视在触发时不会删除，并且会以递归方式触发注册znode以及所有子znode的更改。

2.4 Zookeeper选举过程

        ZooKeeper至少需要三个节点才能工作，Zookeeper节点状态一般认为有4个：　　

• LOOKING：表示正在进行选举的节点，处于该状态需要进入选举流程
• LEADING：领导者状态，处于该状态的节点说明是角色已经是Leader

• FOLLOWING：跟随者状态，表示Leader已经选举出来，当前节点角色是follower
• OBSERVER：观察者状态，表明当前节点角色是observer，observer表示不会进入选举，仅仅只是接受选举结果，也就是说不会成为Leader节点，但是是follower节点一样提供服务。

        推选Leader过程如下图所示：

        在集群初始化阶段，当有一台服务器 ZK1 启动时，无法单独进行和完成 Leader 选举，当第二台服务器 ZK2 启动时，此时两台机器可以相互通信，每台机器都试图找到 Leader，于是进入 Leader 选举过程。选举过程开始，过程如下：　　

(1) 每个Server发出一个投票。由于是初始情况，ZK1 和 ZK2 都会将自己作为 Leader 服务器来进行投票，每次投票会包含所推举的服务器的 ID 和 ZXID（事务ID），使用(ID, ZXID)来表示，此时ZK1的投票为(1, 0)，ZK2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。　　

(2) 接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器。　　

(3) 处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行比较，规则如下：　　　　

• 优先检查 ZXID。ZXID 比较大的服务器优先作为 Leader。
• 如果 ZXID 相同，那么就比较服务器 ID 。ID 较大的服务器作为Leader服务器。

    对于 ZK1 而言，它的投票是(1, 0)，接收 ZK2 的投票为(2, 0)，首先会比较两者的 ZXID，均为 0，再比较 ID，此时 ZK2 的 ID更大，于是 ZK2 胜。ZK1 更新自己的投票为(2, 0)，并将投票重新发送给 ZK2。　　

(4) 统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于 ZK1、ZK2 而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出 ZK2 作为Leader。