Consul

Consul教程 - 梯子教程网 (tizi365.com)

Consul安装与部署 - 梯子教程网 (tizi365.com)

Consul Watches 监控服务变化 - 梯子教程网 (tizi365.com)

 

【Consul】Consul架构-简介_consul 哪个机构发明的-CSDN博客

 

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

高级话题：本节主要讲解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请求服务器的请求/响应机制。

 

拆解开这个体系，从每一个组件开始了解。首先，可以看到有两个数据中心，分别标记为“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。

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

 

 

consul 中 agent 的作用

Consul中的Agent是Consul的核心进程，扮演着至关重要的角色。以下是Agent在Consul中的主要作用：

1. 维护成员关系信息

• Agent负责维护Consul集群中各个节点之间的成员关系信息。这包括节点的加入、离开、故障等状态变化，以及节点间的通信和协作。

2. 注册服务

• Agent允许服务提供者（Producer）注册自己的信息（如IP地址和端口号）到Consul中。这样，服务消费者（Consumer）就可以通过Consul发现并使用这些服务。

3. 健康检查

• Agent会定期向已注册的服务发送健康检查请求，以验证这些服务是否仍然可用。这有助于确保服务消费者不会访问到已经失效的服务。

4. 响应查询

• 当服务消费者需要发现服务时，它们会向Consul发送查询请求。Agent会响应这些请求，并提供有关服务的详细信息，如服务的IP地址、端口号以及健康状态等。

5. 转发RPC请求

• 在Consul集群中，Client Agent会将所有的RPC请求转发到Server Agent进行处理。这样，Client Agent可以专注于执行LAN gossip pool等轻量级任务，而Server Agent则负责处理更复杂的逻辑和存储持久化数据。

6. 参与集群选举和一致性维护

• 当Agent以Server模式运行时，它们会参与集群的选举过程，并维护集群的一致性。在Raft协议的支持下，Server Agent能够确保集群中的数据在多个节点之间保持一致。

7. 广播消息

• Agent还负责在Consul集群中广播消息。这包括节点状态的变化、服务的注册和注销等事件。通过广播消息，Consul集群中的每个节点都能够及时了解到集群的最新状态。

8. 生命周期管理

• 每个Agent都会经历一个生命周期，包括启动、加入集群、处理请求、离开集群等阶段。了解Agent的生命周期对于建立agent交互智能模型和处理节点故障等问题非常有用。

9. 收割死节点

• 为了防止死节点的积累（故障或离开状态的节点），Agent将自动删除catalog中的死节点。这个过程被称为收割（reaping），默认配置的时间间隔为72小时（不建议更改reaping间隔，可能导致集群中断）。

综上所述，Consul中的Agent通过维护成员关系信息、注册服务、健康检查、响应查询、转发RPC请求、参与集群选举和一致性维护、广播消息以及生命周期管理等多种方式，为Consul集群的正常运行提供了有力支持。

 

1.3 深入了解

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

consensusprotocol

gossip protocol

documentation