Consul 简明教程

Consul - Architecture

在一处数据中心中使用的 Consul 架构图可以最贴切地描述为以下内容 −

The architecture diagram for consul working in one datacenter can be best described as shown below −

正如我们所见，有 Consul 管理的三台不同的服务器。工作架构使用 Raft 算法工作，这算法有助于我们从这三台不同的服务器中选出一位领导者。然后按标签对这些服务器进行标注，例如 Follower 和 Leader 。顾名思义，追随者的职责是执行领导者的决定。这三台服务器还进一步相互连接，以便进行任何通信。

As we can observe, there are three different servers, which are managed by Consul. The working architecture works by the using raft algorithm, which helps us in electing a leader out of the three different servers. These servers are then labelled according to the tags such as Follower and Leader. As the name suggests, the follower is responsible for following the decisions of the leader. All these three servers are further connected with each other for any communication.

每台服务器使用 RPC 概念与其自己的客户端进行交互。客户端之间的通信是通过 Gossip Protocol 实现的，如下文所述。可以使用 TCP 或流言蜚语通信方法来实现与互联网设施的通信。此通信直接与这三台服务器中的任意一台发生联系。

Each server interacts with its own client using the concept of RPC. The Communication between the Clients is possible due to Gossip Protocol as mentioned below. The Communication with the internet facility can be made available using TCP or gossip method of communication. This communication is in direct contact with any of the three servers.

Raft Algorithm

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

Raft is a consensus algorithm for managing a replicated log. It relies on the principle of CAP Theorem, which states that in the presence of a network partition, one has to choose between consistency and availability. Not all the three fundamentals of the CAP Theorem can be achieved at any given point of time. One has to tradeoff for any two of them at the best.

一个 Raft Cluster 通常包含数量为奇数的服务器。例如，如果我们有五台服务器，那么它将允许系统容忍两个故障。在任何给定时间，每台服务器都处于三种状态中的某一种： Leader, Follower 或 Candidate 。在正常操作中，只有一个领导者，所有其他服务器都是追随者。这些追随者处于被动状态，即它们不会自己发出请求，而只是响应领导者和候选人的请求。

A Raft Cluster contains several servers, usually in the odd number count. For example, if we have five servers, it will allow the system to tolerate two failures. At any given time, each server is in one of the three states: Leader, Follower, or Candidate. In a normal operation, there is exactly one leader and all of the other servers are followers. These followers are in a passive state, i.e. they issue no requests on their own, but simply respond to requests from leaders and the candidate.

以下插图描述了 Raft 算法工作的流程模型 −

The following illustration describes the workflow model using which the raft algorithm works −

Key Value Data

自 Consul 0.7.1 版以来，引入了单独的关键值数据。KV 命令用于通过命令行与 Consul 的键值存储进行交互。它公开了来自存储的 Inserting, Updating, Reading 和 Deleting 的顶级命令。要获取 Key/Value 对象存储，我们调用为 Consul 客户端提供的 KV 方法 −

Since the Consul’s version 0.7.1, there has been an introduction of separate key value data. The KV command is used to interact with the Consul’s key-value store via the command line. It exposes top-level commands for Inserting, Updating, Reading and Deleting from the store. To get the Key/Value object store, we call the KV method available for the consul client −

kv := consul.KV()

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

The KVPair Structure is used to represent a single key/value entry. We can view the structure of Consul KV Pair in the following program.

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

这里，上述代码中提到的各种结构可以定义如下 −

Here, the various structures mentioned in the above code can be defined as follows −

Key − It is a slash URL name. For example – sites/1/domain.
CreateIndex − Index number assigned when the key was first created.
ModifyIndex − Index number assigned when the key was last updated.
LockIndex − Index number created when a new lock acquired on the key/value entry
Flags − It can be used by the app to set the custom value.
Value − It is a byte array of maximum 512kb.
Session − It can be set after creating a session object.

Types of Protocol

Consul 中有两种协议类型，分别称为 −

There are two types of protocol in Consul, which are called as −

Consensus Protocol and
Gossip Protocol

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

Let us now understand them in detail.

Consensus Protocol

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

Consensus protocol is used by Consul to provide Consistency as described by the CAP Theorem. This protocol is based on the Raft Algorithm. When implementing Consensus protocol, the Raft Algorithm is used where raft nodes are always in any one of the three states: Follower, Candidate or Leader.

Gossip Protocol

Gossip 协议可用来管理成员资格、发送和接收群集中的消息。Consul 中的 Gossip 协议以两种方式使用， WAN （无线区域网络）和 LAN （局域网络）。有三种已知的库，这些库可以实现 Gossip Algorithm，从而在对等网络中发现节点 −

The gossip protocol can be used to manage membership, send and receive messages across the cluster. In consul, the usage of gossip protocol occurs in two ways, WAN (Wireless Area Network) and LAN (Local Area Network). There are three known libraries, which can implement a Gossip Algorithm to discover nodes in a peer-to-peer network −

teknek-gossip − It works with UDP and is written in Java.
gossip-python − It utilizes the TCP stack and it is possible to share data via the constructed network as well.
Smudge − It is written in Go and uses UDP to exchange status information.

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

Gossip protocols have also been used for achieving and maintaining a distributed database consistency or with other types of data in consistent states, counting the number of nodes in a network of unknown size, spreading news robustly, organizing nodes, etc.

Remote Procedure Calls

RPC 可表示为 Remote Procedure Calls 的简称。这是一个协议，一个程序使用它从另一个程序请求服务。此协议可以位于网络上的另一台计算机中，而无需确认网络详细信息。

The RPC can be denoted as the short form for Remote Procedure Calls. It is a protocol that one program uses to request a service from another program. This protocol can be located in another computer on a network without having to acknowledge the networking details.

在 Consul 中使用 RPC 的真正好处在于，它可以帮助我们避免延迟问题，而大多数发现服务工具在一段时间之前都存在此问题。在出现 RPC 之前，Consul 过去只有基于 TCP 和 UDP 的连接，这对于大多数系统来说是好的，但在分布式系统中则不行。RPC 通过缩短信息包从一个地方传输到另一个地方的时间段来解决此类问题。在该领域中，Google 推出的 GRPC 是一个非常棒的工具，可在需要观察基准或比较性能时使用。

The real beauty of using RPC in Consul is that, it helps us avoid the latency issues which most of the discovery service tools did have some time ago. Before RPC, Consul used to have only TCP and UDP based connections, which were good with most systems, but not in the case of distributed systems. RPC solves such problems by reducing the time-period of transfer of packet information from one place to another. In this area, GRPC by Google is a great tool to look forward in case one wishes to observe benchmarks and compare performance.