Consul 架构(译)

时间:2021-08-07 19:58:26

Consul 架构

此篇文章主要对consul的相关内部技术细节进行简要概述。

»术语

  • 代理 - 代理是指consul集群中运行的consul实例,通过执行 consul agent 命令来启动. 代理可以运行于客户端或者服务端。通过执行DNS或者HTTP接口来执行健康检查和服务同步。

  • 客户节点 - 客户节点负责将向服务节点发送RPC请求,相对来说是无状态的.。客户节点唯一要执行的后台活动是参与LAN gossip pool。当然这只会消耗很少的资源和网络带宽。

  • 服务节点 - 服务节点主要职责包括参与Raft算法,维护集群状态,处理RPC查询,和其它的数据中心交换WLAN gossip及向领导者或者远程数据中心转发查询请求。

  • 数据中心 – …

  • 维护一致性- 包括领导者选举及事务执行顺序方面的一致性。

  • Gossip - Consul是建立在Serf之上的,支持全部的gossip protocol(节点间随机通信,主要通过UDP)。Serf 提供关系管理, 失败检测及事件分发功能. Consul gossip应用详情可以访问连接gossip documentation

  • LAN Gossip - 本地局域网或数据中心节点间Gossip应用.

  • WAN Gossip – WAN 范围(不同数据中心,主要通过internet或者wan通信)内服务器节点间Gossip应用。

  • RPC - 远程过程调用,请求/回复机制。

»基本架构

Consul 架构(译)

如上图所示,Consul先天支持多数据中心应用:multiple datacenters

数据中心中包含客户节点和服务节点,通常建议三到五个服务节点。因为随着节点的增加,服务同步会变得相对更慢,同时考虑到服务失败和性能要求等方面因素。但是对于客户节点数量,则没有限制。

数据中心中的所有节点都会参数gossip protocol. 也就是说包括数据中心中所有的节点。这样做有几个目的,首先, 无需给客户节点配置服务节点地址,就可以自动发现。其次,失效节点检测是分布式的,相对于心跳检测模式更具伸缩性。最后,事件分发是以消息模式分发处理的。

节点之间利用Raft协议选举领导者,领导者负责处理所有的查询和事务请求。同时根据Gossip协议,事务请求需要分发到所有的协议节点。所有当一个非领导者服务节点收到一个Rpc请求时,它会将其转发至集群领导者进行后续处理。

服务节点同时也是WAN gossip pool的一部分。相对于LAN pool,WAN pool是专门为高延迟因特网而优化使用的,它只包含服务节点,提供数据中心之间低接触式发现机制。它支持跨数据中心请求,当一个数据中心接到请求其它数据中心数据的请求时,它会将其转发至目标数据中心中随机的一个服务节点。

由此,大大的降低了数据中心的耦合度。但是,因为有相应的失败检测,连接缓存和复用,数据中心之间的交互也相对快捷可靠。

通常来说,数据中心之间是不进行数据交换的,当一个数据中心接收到一个请求其它数据中心资源的请求时,它会将其进行转发,由相应的数据中心进行处理。当目标数据中心不可用,也就意味着所请求的资源不可用。但也有一些特俗情况,会造成数据的分发,如,consul的内置ACL replication功能,及其它相关的外部工具。

一致性模型
 
默认(特定的旧leader的时间窗口内,旧leader处理读请求):Raft使用leader leasing,提供一个时间窗口,这个时间内,leader假定他的leader角色是稳定的。然而,如果这个leader和余下的节点分隔开。在旧leader持有时间窗口的同时,集群就会选出一个新的leader。这就意味着,集群有两个leader节点。发生裂闹现象并没有风险,因为旧leader不能提交新的条目。然而,对于只读请求,旧leader很大可能性上会返回过期数据。默认的一致性模型依赖于leader leasing,客户端有可能会获取到过期的数据的风险。我们之所以做这种妥协是因为,只读请求通常很快,并且是强一致性的。只会在hard-to-trigger情况下会返回过期数据。会返回过期数据的时间窗口长度也是有限的,因为旧的leader会因为分裂的发生降级。
 
一致性(consistent):强一致性模型,这个模型需要leader处理读请求钱,通过询问quorum检查自己的leader合法性,因此增加了一轮RPCs,好处是,读请求的一致性,但是却增加了延迟。
 
过期(stale):这种模型,允许所有的节点处理客户端的读请求。无论是否是leader节点。这就意味着读取过期数据更加普遍,但是也仅仅是在leader的最小超时时间50ms内。好处是,处理只读请求块,适用于大规模请求,但是伴随着普遍的过期数据。模型在没有leader的情况下依然可以处理来此客户端的读请求。
 
Consul Agent:
 
consul agent是consul的核心,负责维护成员关系信息,注册服务,运行健康检查,提供查询等。每个集群的节点都需要部署consul agent。
两种模式:client,server。相较于client,serer模式agent,参与Raft一致性算法。负责提供,保持集群的强一致性及可用性。server agent和数据及系统资源有更多的交互,因此需要运行在专用的节点上。client agent则比较轻量,大多数操作只需要请求server agent去完成,只需要维护相对很少的状态。
 
D:\consul>consul agent -server -bootstrap-expect=1  -data-dir=data -node=server0 -bind=127.0.0.1 -client 0.0.0.0 -ui
BootstrapExpect is set to 1; this is the same as Bootstrap mode.
bootstrap = true: do not enable unless necessary
==> Starting Consul agent...
==> Consul agent running!
           Version: 'v1.0.2'
           Node ID: '1ad0d5d0-80df-29ed-e795-ce50bfd70f2f'  //节点唯一ID
         Node name: 'server0'  //节点名称,默认为机器的主机名,可以通过 -node 进行设置
        Datacenter: 'dc1' (Segment: '<all>')   //所在数据中心,单数据中心默认为dc1,可以通过 -datacenter 设置。
            Server: true (Bootstrap: true)  //运行模式,
       Client Addr: [0.0.0.0] (HTTP: 8500, HTTPS: -1, DNS: 8600)  // 客户端地址,服务于HTTP DNS接口,默认绑定localhost
      Cluster Addr: 127.0.0.1 (LAN: 8301, WAN: 8302) // 和集群内成员通信的地址和端口,LAN WAN
           Encrypt: Gossip: false, TLS-Outgoing: false, TLS-Incoming: false
 
==> Log data will now stream in as it occurs:
 
停止:
gracefully:ctrl-c 和 kill -INT。agent告知集群自己将要离开集群。建议
forcefully:kill -9 立即停止实例,集群通过失败检测发现
 
生命周期:
节点启动
=》join命令,或者通过配置,加入集群
=》成员变更信息通过gossip协议传播到集群其它成员,最终所有其它成员都将获悉节点的加入
=》如果是server 节点,则其它服务几点将进行日志复制
=》如果发生网络问题,节点信息无法获悉(无论是因为网络问题无法通讯还是节点宕机)。则失联节点标记为失效,其它节点更新集群成员信息
=》节点离开,则集群标记节点状态为“已离开”,区别于节点失败(所有节点上注册的服务会立即被注销),如果是server节点,则复制过程停止
=》为了防止死节点信息的堆积,consul会自动将这些信息从成员信息列表中移除,称之为收割。目前配置的时间隔72小时执行一次,当此时,类似于节点失败,移除的节点信息上注册的服务会被注销。