Consul实战：术语和命令解释

这篇文章主要说下Consul里面用到最多的术语然后再说明下启动命令背后发生的故事，为后面搭建一个Consul集群做准备。

Agent

Consul集群中在后台长时间运行的进程就是代理。代理通过consul agent启动。代理能够以客户端或服务端模式运行。因为集群中每个节点都必须有一个代理，因此将节点称为客户端或服务器更为简单。所有的代理都可以有DNS或HTTP接口，负责健康检查和保持服务同步。

Client

客户端是将所有RPC请求转发到服务端的代理。客户端是相对无状态的。客户端跑的唯一后台程序就是参与LAN的gossip池。这种活动资源开销最小，并且仅消耗少量的网络带宽。

Server

服务端是有扩展职责集的代理，扩展功能包括参与Raft仲裁，维护集群状态，响应RPC请求，与其他数据中心交换WAN gossip，以及将查询转发给集群leader或远程数据中心。

Datacenter

数据中心是一个私有的，低延迟的，高带宽的网络环境。当然这不包括穿越公网的通信，但出于我们的目的，单个EC2区域内的多个可用区将被视为单个数据中心的一部分。

Consensus

共识协议就是集群选举leader的一致性协议和交易顺序的协议。由于这些事务适用于有限状态机，因此我们对一致性的定义意味着复制状态机的一致性。共识在Wikipedia上有更详细的描述，后面的文章会说Consul的实现。

Gossip

Consul建立在Serf之上，Serf提供了完整的，可用于多种目的Gossip协议。Serf提供了成员管理，故障检测和事件广播等功能。后面会重点说Gossip协议。Gossip会涉及到随机的节点到节点的UDP通信。

LAN Gossip

指的是局域网Gossip池，其中包含的节点都位于同一局域网或数据中心上。

WAN Gossip

指仅包含服务端的WAN Gossip池。这些Consul服务端主要位于不同的数据中心上，一般通过Internet或广域网进行通信。

RPC

远程过程调用。一种请求/响应模式，允许客户端向服务器发出请求。

serf

serf 和Consul一样，也是出自 Hashicorp 的开源项目， 实现了去中心化的 gossip协议，其中 gossip 协议定义了一种类似病毒感染的消息传播过程。一些著名的开源项目，如 Docker 和这里说的 Consul，网络管理和服务发现的核心组件是基于 serf 实现的，然而它们背后的 serf 似乎还鲜为人知，一方面其复杂的理论以及不完善的文档让人望而却步;另一方面，gossip 协议天然的数据 弱一致性 也制约了 serf 的使用场景。想深入了解的可以看这里：

https://www.infoq.cn/article/principle-and-impleme-of-de-centering-system-in-serf

https://www.serf.io/intro/index.html

创建一个数据中心，需要先创建一个服务端集群。创建一个服务端的推荐方法是使用-bootstrap-expect选项。此选项是创建的Consul服务器节点的预期数量，并在有那么多服务器可用时自动引导。为避免出现不一致和脑裂(多个服务器将其视为leader的集群)情况，必须要把-bootstrap-expect指定相同的值，或者在所有服务器上完全不指定任何值。只有指定值的服务器才会尝试引导群集。

假设正在启动一个三个服务节点的集群。可以通过分别提供-bootstrap-expect 3的标识来启动节点A，节点B和节点C。节点启动后，可以在服务输出中看到一条警告消息。

[WARN] raft: EnableSingleNode disabled, and no known peers. Aborting election. 

警告表明节点期望有2个对等节点，但还不知道。下篇文章会介绍如何启动一个三个几点的Consul集群，到时候会用到这个命令。

接上一篇文章的启动命令

docker run \ 
    -d \ 
    -p 8500:8500 \ 
    -p 8600:8600/udp \ 
    --name=badger \ 
    consul agent -server -ui -node=server -bootstrap-expect=1 

之前在创建Consul节点的时候，指定了bootstrap-expect的值为1，这里就是一个单节点的Consul集群，因为是实验性的课程，所以这里设置了1，1个节点也是可以的，同样可以作为服务使用，只是在生产环境别这样设置，sh

端口

一个服务端Consul节点最多需要6个不同的端口才能正常工作，某些端口需要使用TCP，UDP或同时使用这两种协议。

在运行Consul之前，应该确保可以访问以下绑定端口。

用途	默认端口
DNS: DNS服务 (TCP 或者 UDP)	8600
HTTP: HTTP接口(只有TCP)	8500
HTTPS: HTTPs接口	建议端口 ，默认关闭(8501)*
gRPC：gRPC接口	建议端口，默认关闭 (8502)*
LAN Serf:    局域网端口(TCP和UDP)	8301
Wan Serf：Serf WAN端口（TCP和UDP）	8302
服务器：服务器RPC地址（仅TCP）	8300
Sidecar Proxy Min：包含的最小端口号，用于自动分配的sidecar服务注册。	21000
Sidecar Proxy Max:  包含的最大端口号，用于自动分配的sidecar服务注册。	21255

端口用途

• DNS接口 用于解析DNS查询
• HTTP API 客户端通过HTTP API请求服务端
• HTTPS API(可选)默认情况下处于关闭状态，但8501端口是多种工具默认使用的。
• gRPC API(可选)当前，gRPC仅用于将xDS API公开给Envoy代理。默认情况下它是关闭的，但是端口8502是各种工具默认使用的。在-dev模式下默认为8502。
• Serf LAN 用于处理LAN中的gossip协议。所有代理都需要。
• Serf WAN 服务器广域网服务器使用它来通过广域网传播到其他服务器。从Consul 0.8开始，WAN连接泛洪功能要求Serf WAN端口(TCP / UDP)在WAN和LAN接口上进行监听。
• RPC 服务器用来处理来自其他代理(agent)的请求。

总结

本文主要介绍了后面会用到的一些术语和一些启动命令选项，还有就Consul会用到的几个端口，通过了解这些，方便在后面的文章中学习Consul铺开道路。

本文转载自微信公众号「码小菜」，可以通过以下二维码关注。转载本文请联系码小菜公众号。

本文转载自网络，原文链接：https://mp.weixin.qq.com/s/D8RjiobxuvO6YQQIDANXDw
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！