Consul 在一个数据中心内工作的架构图可以最好地描述如下:
如图所示,有三个由 Consul 管理的不同服务器。其工作架构通过使用 Raft 算法选举出三台服务器中的一个领导者。这些服务器根据标签如 Follower(跟随者)和 Leader(领导者)进行标记。顾名思义,跟随者负责遵循领导者的决策。所有这三台服务器彼此连接以进行任何通信。
每个服务器使用 RPC(远程过程调用)的概念与其客户端进行交互。客户端之间的通信通过如下所述的 Gossip Protocol(gossip 协议)进行。可以使用 TCP 或gossip 通信方法与互联网进行通信。这种通信直接与三台服务器中的任何一台进行联系。
Raft 算法
Raft 是一种用于管理复制日志的共识算法。它依赖于 CAP 定理的原理,该定理指出在存在网络分区的情况下,必须在一致性和可用性之间进行选择。CAP 定理的三个基本要素在任何时候都不能同时实现,必须在其中的任意两个之间进行权衡。
一个 Raft 集群包含若干服务器,通常是奇数个。例如,如果我们有五台服务器,系统将能够容忍两次故障。在任何给定时间,每台服务器都处于三种状态之一:领导者、跟随者或 候选者。在正常操作中,只有一个领导者,其他所有服务器都是跟随者。这些跟随者处于被动状态,即它们不发出任何请求,只对来自领导者和候选者的请求做出响应。
以下插图描述了 Raft 算法的工作流程模型:
键值数据
自 Consul 版本 0.7.1 以来,引入了独立的键值数据。KV 命令用于通过命令行与 Consul 的键值存储交互。它公开了顶级命令,用于从存储中 插入、更新、读取 和 删除 数据。要获取键/值对象存储,我们调用可用于 Consul 客户端的 KV 方法:
kv := consul.KV()
KVPair 结构用于表示单个键/值条目。我们可以在以下程序中查看 Consul KV Pair 的结构。
type KVPair struct {
Key string
CreateIndex uint64
ModifyIndex uint64
LockIndex uint64
Flags uint64
Value []byte
Session string
}
上述代码中提到的各种结构可以定义如下:
- Key:它是一个斜杠 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(Remote Procedure Calls)是远程过程调用的缩写。它是一种协议,一个程序使用它向另一个程序请求服务。该协议可以位于网络上的另一台计算机中,而无需了解网络详细信息。
在 Consul 中使用 RPC 的真正优势在于,它帮助我们避免了以前大多数发现服务工具存在的延迟问题。在 RPC 之前,Consul 仅具有基于 TCP 和 UDP 的连接,这些连接在大多数系统中表现良好,但在分布式系统中则不然。RPC 通过减少信息包从一个地方传输到另一个地方的时间段来解决这些问题。在这方面,如果希望观察基准并比较性能,GRPC 是一个值得关注的优秀工具。