【Consul】Consul架构-简介

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请求服务器的请求/响应机制。

 

1.2 10000英尺看到的视图

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

【Consul】Consul架构-简介_第1张图片


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

documentation

你可能感兴趣的:(微服务,Consul修炼)