Zookeeper满足ca原则-分布式中几种服务注册与发现组件的原理与比较

点击上方“芋道源码”，选择“置顶公众号”

技术文章第一时间送达！

源码精品专栏

、、的基本原理与比较。

前言

在云计算和容器化技术发展火热的当下，对于微服务架构，服务注册与发现组件是必不可少的。在传统的服务架构中，服务的规模处于运维人员的可控范围内。当部署服务的多个节点时，一般使用静态配置的方式实现服务信息的设定。在微服务应用中，服务实例的数量和网络地址都是动态变化的，这对系统运维提出了巨大的挑战。因此，动态的服务注册与发现就显得尤为重要。

解决的问题

在一个分布式系统中，服务注册与发现组件主要解决两个问题：服务注册和服务发现。

除此之外，服务注册与发现需要关注监控服务实例运行状态、负载均衡等问题。

CAP

CAP原则，指的是在一个分布式系统中，(一致性)、(可用性)、 (分区容错性)，不能同时成立。

一般来讲，基于网络的不稳定性，分布容错是不可避免的，所以我们默认CAP中的P总是成立的。

一致性的强制数据统一要求，必然会导致在更新数据时部分节点处于被锁定状态，此时不可对外提供服务，影响了服务的可用性，反之亦然。因此一致性和可用性不能同时满足。

我们接下来介绍的服务注册和发现组件中Zookeeper满足ca原则，满足了其中的AP，和满足了其中的CP。

是在Java语言上，基于 Api开发的服务注册与发现组件，由开源。遗憾的是，目前仅开源到1.X版本，2.X版本已经宣布闭源。

采用的是/的模式进行设计。扮演了服务注册中心的角色，为提供服务注册和发现的功能，维护着注册到自身的的相关信息，同时提供接口给获取到注册表中其他服务的信息。将有关自己的服务的信息通过一定的方式登记到上，并在正常范围内维护自己信息的一致性，方便其他服务发现自己，同时可以通过获取到自己的依赖的其他服务信息，从而完成服务调用。

它的架构图如下所示：

：作为Zookeeper满足ca原则，扮演了服务的提供者，提供业务服务，向注册和更新自己的信息，同时能从的注册表中获取到其他服务的信息。

中没有使用任何的数据强一致性算法保证不同集群间的的数据一致，仅通过数据拷贝的方式争取注册中心数据的最终一致性，虽然放弃数据强一致性但是换来了的可用性，降低了注册的代价，提高了集群运行的健壮性。

是由基于Go语言开发的支持多数据中心分布式高可用的服务发布和注册服务软件，采用Raft算法保证服务的一致性，且支持健康检查。

采用主从模式的设计，使得集群的数量可以大规模扩展，集群间通过RPC的方式调用(HTTP和DNS)。它的结构图如下所示：

Raft算法

Raft算法将分为三种类型：、和。处理所有的查询和事务，并向同步事务。会将所有的RPC查询和事务转发给处理，它仅从接受事务的同步。数据的一致性以中的数据为准实现。

在节点初始启动时，节点的Raft状态机将处于状态等待来来自节点的心跳。如果在一定时间周期内没有收到节点的心跳，节点将发起选举。

节点选举时会将自己的状态切换为，然后向集群中其它节点发送请求，询问其是否选举自己成为。当收到来自集群中过半数节点的接受投票后，节点即成为，开始接收的事务处理和查询并向其它的节点同步事务。节点会定时向发送心跳来保持其地位。

协议

协议是为了解决分布式环境下监控和事件通知的瓶颈。协议中的每个Agent会利用协议互相检查在线状态，分担了服务器节点的心跳压力，通过广播的方式发送消息。

所有的Agent都运行着协议。服务器节点和普通Agent都会加入这个集群，收发消息。每隔一段时间，每个节点都会随机选择几个节点发送消息，其他节点会再次随机选择其他几个节点接力发送消息。这样一段时间过后，整个集群都能收到这条消息。