Consul - 架构

Consul在一个数据中心工作的架构图如下所示：

我们可以看到，有三个不同的服务器由Consul管理。其工作架构通过使用Raft算法来实现，该算法帮助我们从三个不同的服务器中选举出一个领导者。然后根据标签（例如**跟随者**和**领导者**）对这些服务器进行标记。顾名思义，跟随者负责遵循领导者的决策。所有这三个服务器都相互连接以进行任何通信。

每个服务器都使用RPC的概念与其自己的客户端进行交互。客户端之间的通信是由于下面提到的**Gossip协议**。可以使用TCP或Gossip通信方法实现与互联网的连接。此通信直接与三个服务器中的任何一个联系。

Raft算法

Raft是一种用于管理复制日志的共识算法。它依赖于**CAP定理**的原理，该定理指出，在网络分区存在的情况下，必须在一致性和可用性之间进行选择。在任何给定时间点都不能实现CAP定理的所有三个基本要素。必须最好地权衡其中的两个。

一个**Raft集群**包含多个服务器，通常数量为奇数。例如，如果我们有五个服务器，它将允许系统容忍两次故障。在任何给定时间，每个服务器都处于三种状态之一：**领导者、跟随者**或**候选者**。在正常运行中，只有一个领导者，所有其他服务器都是跟随者。这些跟随者处于被动状态，即它们不会自行发出请求，而只是响应领导者和候选者的请求。

下图描述了Raft算法的工作流程模型：

键值数据

从Consul的0.7.1版本开始，引入了单独的键值数据。KV命令用于通过命令行与Consul的键值存储进行交互。它公开了用于从存储中**插入、更新、读取**和**删除**的顶级命令。要获取键/值对象存储，我们调用consul客户端可用的KV方法：

kv := consul.KV()

**KVPair结构**用于表示单个键/值条目。我们可以在以下程序中查看Consul KV对的结构。

type KVPair struct {
   Key string
   CreateIndex uint64
   ModifyIndex uint64
   LockIndex uint64
   Flags uint64
   Value []byte
   Session string
}

此处，上述代码中提到的各种结构定义如下：

**键** - 它是一个斜杠URL名称。例如 - sites/1/domain。
**CreateIndex** - 首次创建键时分配的索引号。
**ModifyIndex** - 上次更新键时分配的索引号。
**LockIndex** - 在键/值条目上获取新锁时创建的索引号
**Flags** - 应用可以使用它来设置自定义值。
**Value** - 它是一个最大为512kb的字节数组。
**Session** - 创建会话对象后可以设置。

协议类型

Consul中有两种类型的协议，它们被称为：

共识协议和
Gossip协议

现在让我们详细了解它们。

共识协议

Consul使用共识协议来提供CAP定理中描述的一致性。此协议基于Raft算法。在实现共识协议时，使用Raft算法，其中Raft节点始终处于三种状态之一：跟随者、候选者或领导者。

Gossip协议

Gossip协议可用于管理成员身份，在集群之间发送和接收消息。在Consul中，Gossip协议的使用有两种方式，**WAN**（无线局域网）和**LAN**（局域网）。有三个已知的库可以实现Gossip算法来发现对等网络中的节点：

**teknek-gossip** - 它与UDP一起工作，并用Java编写。
**gossip-python** - 它利用TCP堆栈，也可以通过构建的网络共享数据。
**Smudge** - 它用Go编写，并使用UDP交换状态信息。

Gossip协议也用于实现和维护分布式数据库一致性或其他类型的一致状态数据，计算未知大小网络中的节点数量，稳健地传播新闻，组织节点等。

远程过程调用

RPC可以表示为远程过程调用的缩写。它是一种程序用来请求另一程序服务的协议。此协议可以位于网络上的另一台计算机上，而无需确认网络细节。

在Consul中使用RPC的真正好处是，它帮助我们避免了大多数发现服务工具在一段时间前所遇到的延迟问题。在RPC之前，Consul仅使用基于**TCP**和**UDP**的连接，这对于大多数系统来说都很好，但在分布式系统的情况下则不然。RPC通过减少从一个地方到另一个地方的数据包信息传输时间来解决此类问题。在这个领域，谷歌的GRPC是一个很好的工具，如果希望观察基准并比较性能，可以参考它。

打印页面