【Consul】Consul架构-简介

骑猪看日落 2022-06-14 09:37 263阅读 0赞

Consul是一个复杂的系统，有许多不同的移动部件。为了帮助用户和Consul的开发人员更深入的了解consul是如何工作的，本文介绍consul的系统[架构][Link 1]。

**高级话题：**本节主要讲解consul内部技术细节，使用consul不需要必须了解这些细节的。这些文章是为那些不愿意深入源代码但是希望技术细节的人准备的。

## 1.1 术语 ##

在描述的体系结构之前，首先介绍本技术系列文档使用的术语词汇表，以帮助澄清模糊点：

•Agent，Agent是长期运行在每个consul集群成员节点上守护进程。通过命令consul agent启动。Agent有client和server两种模式。由于每个节点都必须运行agent，所有节点要么是client要么是server。所有的Agent都可以可以调用DNS或HTTP API，并负责检查和维护服务同步。

•client 运行client模式的Agent，将所有的RPCs转发到Server。Client是相对无状态的。Client唯一所做的是在后台参与LAN gossip pool。只消耗少量的资源，少量的网络带宽。

•Server 运行Server模式的Agent，参与Raft quorum，维护集群的状态，响应RPC查询，与其他数据中心交互WAN gossip，转发查询到Leader或远程数据中心。

•datacenter  数据中心的定义似乎是显而易见的，有一些细节是必须考虑的。例如，在EC2，多个可用性区域是否被认为组成了单一的数据中心？我们定义数据中心是在同一个网络环境中——私有的，低延迟，高带宽。这不包括基于公共互联网环境，但是对于我们而言，在同一个EC2的多个可用性区域会被认为是一个的数据中心。

•Consensus - 当本系列文档中，consensus，意味着leader election协议，以及事务的顺序。由于这些事务是基于一个有限状态机，consensus的定义意味着复制状态机的一致性。

•Gossip – consul是建立在Serf之上，提供了完成的Gossip协议，用于成员维护故障检测、事件广播。详细细节参见*[gossip documentation][]*。这足以知道gossip是基于UDP协议实现随机的节点到节点的通信，主要是在UDP。

•LAN Gossip，指的是LAN gossip pool，包含位于同一个局域网或者数据中心的节点。

•WAN Gossip，指的是WAN gossip pool，只包含server节点，这些server主要分布在不同的数据中心或者通信是基于互联网或广域网的。

•RPC，远程过程调用。是允许client请求服务器的请求/响应机制。

## 1.2 10000英尺看到的视图 ##

从10000万英尺的高度看consul架构：

![Center][]

拆解开这个体系，从每一个组件开始了解。首先，可以看到有两个数据中心，分别标记为“one”和“two”。Consul是支持多数据中心一流，并且是常用业务场景。

每个数据中心都是由Server和client组成。建议有3~5 Server——基于故障处理和性能的平衡之策。**如果增加越多的机器，则Consensus会越来越慢。**对client没有限制，可以很容易地扩展到成千上万或数万。

同一个数据中心的所有节点都要加入Gossip协议。这意味着gossip pool包含给定数据中心的所有节点。有以下目的：首先，没有必要为client配置服务器地址参数；发现是自动完成的。第二，节点故障检测的工作不是放置在服务器上，而是分布式的。这使故障检测比心跳机制更可扩展性。第三，可用来作为消息层通知重要的事件，如leader选举。

每个数据中心的服务器都是属于一个Raft peer。这意味着，他们一起工作，选出一个的Leader，Leader server是有额外的职责。负责处理所有的查询和事务。事务也必须通过Consensus协议复制到所有的伙伴。由于这一要求，当非Leader Server接收到一个RPC请求，会转发到集群的leader。

Server节点也是作为WAN gossip pool的一部分。这个pool是与LAN gossip pool是不同的，它为具有更高延迟的网络响应做了优化，并且可能包括其他consul集群的server节点。设计WANpool的目的是让数据中心能够以low-touch的方式发现彼此。将一个新的数据中心加入现有的WAN Gossip是很容易的。因为池中的所有Server都是可控制的，这也使跨数据中心的要求。当一个Serfer接收到不同的数据中心的要求时，它把这个请求转发给相应数据中心的任一Server。然后，接收到请求的Server可能会转发给Leader。

多个数据中心之间是低耦合，但由于故障检测、连接缓存复用、跨数据中心要求快速和可靠的响应。

## 1.3 深入了解 ##

本节中，只是从框架上了解consul，对于每一个子系统的细节接下来详细介绍：

[consensusprotocol][]

[gossip protocol][gossip documentation]

[documentation][]

[Link 1]: http://lib.csdn.net/base/architecture
[gossip documentation]: https://www.consul.io/docs/internals/gossip.html
[Center]: /images/20220614/9c5f0c56c5ee4c4082228713e2b22ba6.png
[consensusprotocol]: https://www.consul.io/docs/internals/consensus.html
[documentation]: https://www.consul.io/docs/internals/security.html