如何理解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的命令"有了更深的了解，不妨来实际操作一番吧！这里是网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
