consul基础

一 consul介绍

官方文档：https://www.consul.io/docs/intro

Consul 是一种服务网格解决方案，提供具有服务发现、配置和分段功能的全功能控制平面。这些功能中的每一个都可以根据需要单独使用，也可以一起使用以构建完整的服务网格。Consul 需要一个数据平面并支持代理和本地集成模型。Consul 附带一个简单的内置代理，因此一切都可以开箱即用，而且还支持 3rd 方代理集成，例如 Envoy。

基于golang开发的开源工具，主要面向分布式，服务化的系统听服务注册、服务发现和配置管理的功能。

Consul 使用共识协议 来提供一致性（由 CAP 定义）。

二 consul特点

• 服务发现：Consul 的客户端可以注册一个服务，例如 api或mysql，其他客户端可以使用 Consul 来发现给定服务的提供者。使用 DNS 或 HTTP，应用程序可以轻松找到它们所依赖的服务。

• 健康检查：Consul 客户端可以提供任意数量的健康检查，要么与给定的服务相关联（“网络服务器是否返回 200 OK”），要么与本地节点（“内存利用率是否低于 90%”）相关联。操作员可以使用此信息来监视集群健康状况，并且服务发现组件可以使用它来将流量从不健康的主机路由出去。

• KV 存储：应用程序可以将 Consul 的分层键/值存储用于多种目的，包括动态配置、功能标记、协调、领导选举等。简单的 HTTP API 使其易于使用。

• 安全服务通信：Consul 可以为服务生成和分发 TLS 证书，以建立相互的 TLS 连接。 目的可用于定义允许哪些服务进行通信。可以通过实时更改意图轻松管理服务分段，而不是使用复杂的网络拓扑和静态防火墙规则。

• 多数据中心：Consul 支持开箱即用的多个数据中心。这意味着 Consul 的用户不必担心构建额外的抽象层以扩展到多个区域。

三 Raft 协议概述

Raft 是一种基于Paxos的共识算法 。与 Paxos 相比，Raft 被设计为具有更少的状态和更简单、更易于理解的算法。

2.1 raft术语

• 日志 - Raft 系统中的主要工作单元是日志条目。一致性问题可以分解为复制日志。日志是有序的条目序列。条目包括任何集群更改：添加节点、添加服务、新的键值对等。如果所有成员都同意条目及其顺序，我们认为日志是一致的。

• FSM-有限状态机。FSM 是有限状态的集合，它们之间有转换。随着新日志的应用，FSM 被允许在状态之间转换。应用相同的日志序列必须导致相同的状态，这意味着行为必须是确定性的。

• 对等集 - 对等集是所有参与日志复制的成员的集合。出于 Consul 的目的，所有服务器节点都在本地数据中心的对等集中。

• 法定人数 - 法定人数是来自对等集合的大多数成员：对于大小为 的集合N，法定人数至少需要(N/2)+1成员。例如，如果对等集中有 5 个成员，我们将需要 3 个节点来形成法定人数。如果仲裁节点因任何原因不可用，则集群将不可用且无法提交新日志。

• 已提交条目 - 当条目持久存储在仲裁节点上时，该条目被视为已提交。一旦一个条目被提交，它就可以被应用。

• 领导者 - 在任何给定时间，对等集都会选择一个节点作为领导者。领导者负责摄取新的日志条目，复制到跟随者，并管理条目何时被提交。

2.2 raft节点状态

• follower（跟随者）
• candidate（候选者）
• leader（领导者）

2.3 选举流程

• 所有节点最初都是从跟随者开始的。在这种状态下，节点可以接受来自领导者的日志条目并投票。如果一段时间内没有收到条目，节点会自我提升到候选状态。在候选状态中，节点向其对等节点请求投票。如果候选人获得法定人数的选票，则将其提升为领导者。领导者必须接受新的日志条目并复制到所有其他追随者。此外，如果过时读取是不可接受的，则所有查询也必须在领导者上执行。
• 一旦集群有了领导者，它就能够接受新的日志条目。客户端可以请求领导者附加一个新的日志条目（从 Raft 的角度来看，日志条目是一个不透明的二进制 blob）。然后领导者将条目写入持久存储并尝试复制到法定人数的追随者。一旦日志条目被认为已 提交，就可以将其应用于有限状态机。有限状态机是特定于应用程序的；在 Consul 的案例中，我们使用 MemDB来维护集群状态。Consul 的 writes 阻塞，直到它被提交和应用。当与查询的一致性模式一起使用时，这实现了先读后写语义。
• Raft 提供了一种机制，通过它可以对当前状态进行快照并压缩日志。由于 FSM 抽象，恢复 FSM 的状态必须导致与旧日志重播相同的状态。这允许 Raft 在某个时间点捕获 FSM 状态，然后删除用于达到该状态的所有日志。这是在没有用户干预的情况下自动执行的，可以防止无限制的磁盘使用，同时最大限度地减少重放日志所花费的时间。使用 MemDB 的优点之一是它允许 Consul 继续接受新事务，即使在对旧状态进行快照时，也可以防止任何可用性问题。
• 共识是容错的，直到法定人数可用。如果仲裁节点不可用，则无法处理日志条目或有关对等成员资格的原因。例如，假设只有 2 个对等节点：A 和 B。仲裁大小也是 2，这意味着两个节点必须同意提交日志条目。如果 A 或 B 失败，则现在不可能达到法定人数。这意味着集群无法添加或删除节点或提交任何其他日志条目。这将导致 不可用。此时，需要手动干预以删除 A 或 B 并以引导模式重新启动剩余节点。
• 3 个节点的 Raft 集群可以容忍单个节点故障，而 5 个节点的集群可以容忍 2 个节点故障。推荐的配置是每个数据中心运行 3 或 5 个 Consul 服务器。这在不极大地牺牲性能的情况下最大化了可用性。
• 在性能上，Raft 与 Paxos 不相上下。假设领导稳定，提交日志条目需要单次往返集群的一半。因此，性能受磁盘 I/O 和网络延迟的约束。尽管 Consul 不是设计为高吞吐量的写入系统，但它应该每秒处理数百到数千个事务，具体取决于网络和硬件配置。

四 一致性模式

尽管对复制日志的所有写入都通过 Raft，但读取更加灵活。为了支持开发人员可能想要的各种权衡，Consul 支持 3 种不同的读取一致性模式。

三种读取模式是：

• default- Raft 使用了leader 租用，提供了一个时间窗口，在这个窗口中，leader 扮演的角色是稳定的。但是，如果领导者与其余对等体分开，则可能会在旧领导者持有租约时选出新领导者。这意味着有 2 个领导节点。不存在裂脑的风险，因为旧的领导者将无法提交新的日志。但是，如果旧的领导者服务任何读取，则这些值可能是陈旧的。默认的一致性模式仅依赖于领导者租用，将客户端暴露给潜在的陈旧值。我们进行这种权衡是因为读取速度很快，通常具有很强的一致性，并且仅在难以触发的情况下才会失效。过时读取的时间窗口也是有界的，因为领导者将因分区而下台。

• consistent- 这种模式非常一致，没有警告。它要求领导者与法定人数的对等方一起验证它仍然是领导者。这引入了到所有服务器节点的额外往返。权衡总是一致的读取，但由于额外的往返行程而增加了延迟。

• stale- 这种模式允许任何服务器为读取提供服务，而不管它是否是领导者。这意味着读取可以任意陈旧，但通常在领导者的 50 毫秒内。权衡是非常快速和可扩展的读取，但具有陈旧的值。这种模式允许在没有领导者的情况下进行读取，这意味着不可用的集群仍然能够响应。

五 consul架构

• 首先，我们可以看到有两个数据中心，分别标记为“一”和“二”。Consul 对多个数据中心有一流的支持，并希望这是常见的情况。
• 在每个数据中心内，我们混合了客户端和服务器。预计将有三到五台服务器。这在故障情况下的可用性和性能之间取得了平衡，因为随着更多机器的加入，共识变得越来越慢。但是，客户端数量没有限制，它们可以轻松扩展到数千或数万。
• 数据中心中的所有代理都参与 gossip protocol.。这意味着有一个gossip pool 包含给定数据中心的所有代理。这有几个目的：首先，不需要使用服务器地址配置客户端；发现是自动完成的。其次，检测代理故障的工作不是放在服务器上而是分布式的。这使得故障检测比简单的心跳方案更具可扩展性。它还为节点提供故障检测；如果代理不可访问，则节点可能遇到故障。第三，它用作消息传递层，以在发生领导者选举等重要事件时进行通知。
• 每个数据中心中的服务器都是单个 Raft 对等集的一部分。这意味着他们一起工作来选举一个领导者，一个有额外职责的选定服务器。领导者负责处理所有查询和交易。作为共识协议的一部分，交易还必须复制到所有对等点。由于这个要求，当一个非领导服务器收到一个 RPC 请求时，它会将它转发给集群领导。
• 服务器代理还作为 WAN 八卦池的一部分运行。该池与 LAN 池不同，因为它针对 Internet 的更高延迟进行了优化，并且预计仅包含其他 Consul 服务器代理。这个池的目的是允许数据中心以低接触的方式发现彼此。使新数据中心上线就像加入现有的 WAN 八卦池一样简单。因为服务器都在这个池中运行，所以它也支持跨数据中心请求。当服务器收到对不同数据中心的请求时，它会将其转发到正确数据中心中的随机服务器。然后该服务器可以转发给本地领导。
• 这导致数据中心之间的耦合非常低，但由于故障检测、连接缓存和多路复用，跨数据中心请求相对快速和可靠。
• 通常，不同的 Consul 数据中心之间不会复制数据。当对另一个数据中心中的资源发出请求时，本地 Consul 服务器会将 RPC 请求转发到该资源的远程 Consul 服务器并返回结果。如果远程数据中心不可用，那么这些资源也将不可用，但这不会影响本地数据中心。在某些特殊情况下，可以复制有限的数据子集，例如使用 Consul 的内置 ACL 复制功能，或使用consul-replicate等外部工具。
• 在某些地方，客户端代理可能会缓存来自服务器的数据，以使其在本地可用以提高性能和可靠性。示例包括连接证书和意图，它们允许客户端代理对入站连接请求做出本地决策，而无需往返服务器。一些 API 端点还支持可选的结果缓存。这有助于提高可靠性，因为即使与服务器的连接中断或服务器暂时不可用，本地代理也可以继续响应某些查询，如服务发现或缓存中的连接授权。

六 部署表

服务器	法定人数	容错
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2
6	4	2
7	4	3

七 端口列表

Use	Default Ports
DNS：DNS 服务器（TCP 和 UDP）	8600
HTTP：HTTP API（仅限 TCP）	8500
HTTPS：HTTPS API	禁用 (8501) *
gRPC：gRPC API	禁用 (8502) *
LAN Serf：Serf LAN 端口（TCP 和 UDP）	8301
Wan Serf：Serf WAN 端口（TCP 和 UDP）	8302
服务器：服务器 RPC 地址（仅限 TCP）	8300
Sidecar Proxy Min：用于自动分配的 sidecar 服务注册的最小端口号。	21000
Sidecar Proxy Max：用于自动分配的 sidecar 服务注册的包含最大端口号。	21255

* ForHTTPS和gRPC表中指定的端口是推荐的。

八 consul启动命令参数

官方地址：https://www.consul.io/docs/agent/options

• server- 提供此标志指定您希望代理以服务器模式启动。
• -bootstrap-expect- 这会告诉 Consul 服务器数据中心总共应该有多少台服务器。在引导复制日志之前，所有服务器都将等待此数字加入，从而使所有服务器的数据保持一致。由于您要设置单服务器数据中心，因此您需要将此值设置为1。
• -node- 数据中心中的每个节点都必须有一个唯一的名称。默认情况下，Consul 使用机器的主机名，但您将手动覆盖它，并将其设置为 agent-one.
• -bind- 这是此代理将侦听其他领事成员通信的地址。它必须可供数据中心内的所有其他节点访问。如果你没有设置绑定地址，Consul 将尝试侦听所有 IPv4 接口，如果发现多个私有 IP，它将无法启动。由于生产服务器通常有多个接口，因此您应该始终提供绑定地址。在本例中，它是172.20.20.10，您将其指定为 Vagrantfile 中第一个 VM 的地址。
• data-dir- 这个标志告诉 Consul 代理他们应该在哪里存储他们的状态，其中可以包括敏感数据，比如服务器和客户端的 ACL 令牌。在生产部署中，您应该注意此目录的权限。
• config-dir- 这个标志告诉 consul 在哪里寻找它的配置。您将其设置为标准位置：/etc/consul.d。

九 常用词汇

Consul datacenter

在大多数情况下，Consul 数据中心被定义为单个物理数据中心或单个云区域。虽然这条规则有例外，但其基本理念是 Consul 数据中心是一种 LAN 结构，并针对 LAN 延迟进行了优化。服务器进程用于协调其操作以及服务器和客户端进程相互通信的通信协议针对 LAN 带宽进行了优化。

Gossip

Consul 使用 gossip 协议来管理集群的组成员资格并发送广播消息。Consul 使用的 Gossip 版本已从分布式系统中常用的其他版本进行了改进。

Consensus

共识是在硬件和软件不可靠的世界中进行可靠的分布式计算所必需的组件之一。分布式系统必须能够达成某种共识；关于哪些节点负责、当前状态、已提交事务等的协议——即使所有节点不共享相同的状态或环境视图。分布式系统通常使用一种算法（即定义的过程）来达成共识。

Consul 利用 Raft 共识算法。Raft 协议允许节点处于 3 种状态之一：领导者、追随者或候选者。只有 Consul 服务器代理使用共识协议，因为客户端代理仅将请求转发给服务器代理。Raft 利用 RPC 在服务器代理和客户端代理之间进行通信。

Raft

Raft 是 Consul 用来响应客户端请求并在服务器代理之间复制信息（日志）的共识算法。信息从领导者单向流动到其他服务器代理。

Failure domain

故障域标识服务提供商期望包含某些故障以及某些可用性和性能特征保持真实的范围。由于 Consul 是一种高可用的集群服务，因此最可靠的 Consul 部署分布在多个故障域中。在 Consul 集群的上下文中，故障域可以表示可用区、可用性集、区域和物理机架或数据中心。下表描述了主要云提供商和本地资源位置的各种类型的故障域。

资源位置	故障域	故障范围	潜伏
AWS	可用区 (AZ)、区域	数据中心，地区	AZ 之间 1-2 毫秒， 区域之间 10 到 100 毫秒
Azure	可用性集 (AS)、可用区、区域	物理服务器机架、数据中心、区域	可用性集之间 <1 毫秒，可用区之间 <2 毫秒，区域 之间 10 到 100 毫秒
GCP	可用区、区域	数据中心，地区	可用区之间 < 1 毫秒，数据中心之间 10 到 100 毫秒
On-premises	独立的机架，高可用的网络/冷却反关联规则	物理机架、物理交换机、冷却设备、VM/Container 高可用性	<1 ms 延迟 *这可能因环境细节而异

 

Availability zone

在云环境中，“可用区”代表地理上独立的基础设施，它们之间具有快速、低延迟的网络。在本地基础架构中，这相当于将物理服务器机架（在单个数据中心内）与它们自己的独立网络、电源和冷却系统分开。

Region

区域是低延迟网络上一个或多个可用区的集合。区域通常相隔很远的距离。一个区域可以托管一个或多个 Consul 集群，但由于网络延迟问题，单个 Consul 集群不会分布在多个区域中。