Consul 入门

Consul 简介

Consul 解决了各种规模的组织在微服务架构中遇到的挑战。包括各种分布式环境下及跨地理位置下的所有应用程序流量的保护，它关注计算网络层。

Consul 是一个服务网格解决方案，它的核心功能主要包含：

• Service Discovery - 服务发现：Consul 的客户端可以注册服务，例如 api 或 mysql，其他客户端可以使用 Consul 发现给定服务的提供者。使用 DNS 或 HTTP，应用程序可以轻松找到它们所依赖的服务。
• Health Checking - 健康检查：Consul 客户端可以提供任意数量的健康检查，或者与给定服务相关联（“网络服务器是否返回 200 OK”），或者与本地节点相关联（“内存利用率是否低于 90%”）。操作员可以使用此信息来监控集群的健康状况，服务发现组件使用它将流量路由到健康的主机。
• KV Store - KV 存储：应用程序可以将 Consul 的分层键/值存储用于任意数量的目的，包括动态配置、特征标记、协调、领导者选举等。简单的 HTTP API 也使其易于使用。
• Secure Service Communication - 安全服务通信：Consul 可以为服务生成和分发 TLS 证书以建立相互 TLS 连接。Intentions 可用于定义允许通信的服务。可以通过实时更改意图轻松管理服务分段，而不是使用复杂的网络拓扑和静态防火墙规则。
• Multi Datacenter - 多数据中心：Consul 开箱即用地支持多个数据中心。这意味着 Consul 的用户不必担心构建额外的抽象层以扩展到多个区域。

Consul 旨在对 DevOps 社区和应用程序开发人员都友好，使其非常适合现代、弹性的基础设施。

Consul 词汇

本节收集了 Consul 和 Consul Enterprise 文档中使用的一些技术术语的简要定义，以及在整个 Consul 社区的对话中经常出现的一些术语。

Agent

代理 - Agent 是 Consul 集群每个成员上长时间运行的守护进程，代理负责节点上的服务以及节点本身的健康检查。它是通过运行 consul agent 启动的。代理可以在客户端或服务器模式下运行。由于所有节点都必须运行代理，发现其他服务或获取/设置键/值数据不需要运行代理，因此将节点称为客户端或服务器更简单，但还有其他代理实例。所有代理都可以运行 DNS 或 HTTP 接口，并负责运行检查和保持服务同步。

Client

客户端 - Client 是将所有 RPC 转发到服务器的代理。客户端是相对无状态的。客户端执行的唯一后台活动是参与 LAN gossip 池。这具有最小的资源开销并且仅消耗少量的网络带宽。

Server

服务器 - Server 是具有扩展职责集的代理，包括参与 Raft 仲裁、维护集群状态、响应 RPC 查询、与其他数据中心交换 WAN gossip、并将查询转发给领导者或远程数据中心。

Datacenter

我们将数据中心定义为私有、低延迟和高带宽的网络环境。这不包括穿越公共互联网的通信，但就我们而言，单个 EC2 区域内的多个可用区将被视为单个数据中心的一部分。

Access Control List (ACL)

访问控制列表 - Access Control List (ACL) 是文件、文件夹或其他对象的用户权限列表。它定义了哪些用户和组可以访问对象以及他们可以执行哪些操作。

Consul 使用访问控制列表 (ACL) 来保护 UI、API、CLI、服务通信和代理通信。

访问 Consul ACL 文档和指南。

Consul 架构

俯视整个 Consul ，它的架构是这样的：

让我们分解这张图片并描述每一块。首先，我们可以看到有两个数据中心，分别标记为“DATACENTER 1”和“DATACENTER 2”。 Consul 对多个数据中心有最高级别的支持，并希望这是常见的使用情况。

在每个数据中心内，我们混合了客户端和服务器。预计将有三到五台服务器。这在故障情况下的可用性和性能之间取得了平衡，因为随着添加更多机器，共识将变得越来越慢。但是，客户端数量没有限制，它们可以轻松扩展到数千或数万。

数据中心中的所有代理都参与 gossip 协议。这意味着有一个 gossip 池包含给定数据中心的所有代理。这有几个目的：首先，不需要使用服务器地址配置客户端；发现是自动完成的。其次，检测代理故障的工作不是放在服务器上而是分布式的。这使得故障检测比简单的心跳方案更具可扩展性。它还为节点提供故障检测；如果代理不可访问，则节点可能遇到故障。第三，它用作消息传递层，以在发生领导者选举等重要事件时进行通知。

每个数据中心中的服务器都是单个 Raft 对等集的一部分。这意味着他们一起工作来选举一个领导者，领导者为一个有额外职责的选定服务器。领导者负责处理所有查询和事物。作为共识协议的一部分，事物还必须复制到所有对等点。由于这个要求，当一个非领导服务器收到一个 RPC 请求时，它会将它转发给集群领导。

服务器代理还作为 WAN gossip 池的一部分运行。此池与 LAN 池不同，因为它针对 Internet 的更高延迟进行了优化，并且只期待与其他 Consul 服务器代理交互。这个池的目的是允许数据中心以低接触的方式发现彼此。使新数据中心上线就像加入现有的 WAN gossip 池一样简单。因为服务器都在这个池中运行，所以它也支持跨数据中心请求。当服务器收到对不同数据中心的请求时，它会将其转发到正确数据中心中的随机服务器。该服务器然后可以转发给本地领导。

这导致数据中心之间的耦合非常低，但由于故障检测、连接缓存和多路复用，跨数据中心请求相对快速和可靠。

通常，不同的 Consul 数据中心之间不会复制数据。当对另一个数据中心中的资源发出请求时，本地 Consul 服务器会将 RPC 请求转发到该资源的远程 Consul 服务器并返回结果。如果远程数据中心不可用，那么这些资源也将不可用，但这不会影响本地数据中心。在某些特殊情况下，可以复制有限的数据子集，例如使用 Consul 的内置 ACL 复制功能，或使用 consul-replicate 等外部工具。

在某些地方，客户端代理可能会缓存来自服务器的数据，以使其在本地可用以提高性能和可靠性。比如连接证书和意图，它们允许客户端代理对入站连接请求做出本地决策，而无需往返服务器。一些 API 端点还支持可选的结果缓存。这有助于提高可靠性，因为即使与服务器的连接中断或服务器暂时不可用，本地代理也可以继续响应某些查询，如服务发现或缓存中的连接授权。

共识协议 - Consensus Protocol

Consul 使用共识协议来提供一致性（由 CAP 定义）。共识协议基于“Raft：寻找可理解的共识算法”。有关 Raft 的可视化解释，请参阅数据的秘密生活。

Raft 协议概述

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

在讨论 Raft 时，有几个关键术语需要了解：

• Log - Raft 系统中的主要工作单元是日志条目。一致性问题可以分解为复制日志。日志是有序的条目序列。条目包括任何集群更改：添加节点、添加服务、新的键值对等。如果所有成员都同意条目及其顺序，我们认为日志是一致的。
• FSM - 有限状态机（Finite State Machine）。FSM 是有限状态的集合，它们之间有转换。随着新日志的应用，FSM 被允许在状态之间转换。应用相同的日志序列必须导致相同的状态，这意味着行为必须是确定性的。
• Peer set - 对等集是所有参与日志复制的成员的集合。出于 Consul 的目的，所有服务器节点都在本地数据中心的对等集中。
• Quorum - 法定人数是来自对等集合的大多数成员：对于大小为 N 的集合，法定人数至少需要 (N/2)+1 名成员。例如，如果对等集中有 5 个成员，我们将需要 3 个节点来形成法定人数。如果法定节点因任何原因不可用，则集群将不可用且无法提交新日志。
• Committed Entry - 当条目持久地存储在法定节点上时，该条目被视为已提交。一旦一个条目被提交，它就可以被应用。
• Leader - 在任何给定时间，peer set 都会选择一个节点作为领导者。领导者负责摄取新的日志条目，复制到追随者，并管理条目何时被视为已提交。

Raft 是一个复杂的协议，这里不会详细介绍（对于那些想要更全面处理的人，可以在本文中找到完整的规范）。然而，我们将尝试提供可能对构建心智模型有用的高级描述。

Raft 节点始终处于以下三种状态之一：跟随者（follower）、候选者（candidate）或领导者（leader）。所有节点最初都是从跟随者开始的。在这种状态下，节点可以接受来自领导者的日志条目并投票。如果一段时间内没有收到条目，节点会自我提升到候选状态。在候选状态中，节点向其对等节点请求投票。如果候选人获得法定人数的选票，则将其提升为领导者。领导者必须接受新的日志条目并复制到所有其他追随者。此外，如果陈旧读取是不可接受的，则所有查询也必须在领导者上执行。

一旦集群有了领导者，它就能够接受新的日志条目。客户端可以请求领导者附加一个新的日志条目（从 Raft 的角度来看，日志条目是一个不透明的二进制 blob）。领导者然后将条目写入持久存储并尝试复制到法定人数的追随者。一旦日志条目被认为已提交，就可以将其应用于有限状态机。这允许 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 in Consul

只有 Consul 服务器节点参与 Raft 并且是 peer set 的一部分。所有客户端节点将请求转发到服务器。这种设计的部分原因是，随着更多成员添加到对等集中，法定人数的大小也会增加。这会引入性能问题，因为您可能正在等待数百台机器就一个条目而不是少数机器达成一致。

开始时，单个 Consul 服务器被置于“引导 - bootstrap”模式。这种模式允许它自选为领导者。一旦选举出领导者，其他服务器可以以保持一致性和安全性的方式添加到对等集中。最终，一旦添加了前几台服务器，就可以禁用引导模式。有关更多详细信息，请参阅此文档。

由于所有服务器都作为对等集的一部分参与，因此它们都知道当前的领导者。当 RPC 请求到达非领导服务器时，请求被转发给领导者。如果 RPC 请求是查询类型，意味着它是只读的，则领导者会根据 FSM 的当前状态生成结果。如果 RPC 是事务类型，这意味着它会修改状态，则领导者会生成一个新的日志条目并使用 Raft 应用它。一旦日志条目提交并应用到 FSM，事务就完成了。

由于 Raft 复制的性质，性能对网络延迟很敏感。出于这个原因，每个数据中心都会选举一个独立的领导者并维护一个不相交的对等集。数据是按数据中心划分的，所以每个领导者只对自己数据中心的数据负责。当收到远程数据中心的请求时，该请求将转发给正确的领导者。这种设计允许在不牺牲一致性的情况下实现更低的延迟事务和更高的可用性。

一致性模式

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

三种读取模式是：

• default - Raft 使用了领导者租期 - leasing，提供了一个时间窗口，领导者在其中扮演稳定的角色。但是，如果领导者与其余对等体分开，则可能会在旧领导者持有租期时选出新领导者。这意味着有 2 个领导节点。不存在脑裂的风险，因为旧的领导者将无法提交新的日志。但是，如果旧的领导者仍然为任何读取提供服务，则这些值可能是陈旧的。默认的一致性模式仅依赖于领导者租期，将会给客户端暴露潜在的陈旧值。我们进行这种权衡是因为读取速度很快，通常具有很强的一致性，并且仅在难以触发的情况下才会失效。过时读取的时间窗口也是有界的，因为领导者将因分区而下台。
• consistent - 这种模式提供强一致性。它要求领导者与法定人数的对等方一起验证它仍然是领导者。这引入了到所有服务器节点的额外往返。权衡的利：总是一致的读取，弊：由于额外的往返行程而增加了延迟。
• stale - 这种模式允许任何服务器为读取提供服务，而不管它是否是领导者。这意味着读取可以任意陈旧，但通常在领导者的 50 毫秒内。权衡是非常快速和可扩展的读取，但具有过时的值。这种模式允许在没有领导者的情况下进行读取，这意味着不可用的集群仍然能够响应。

有关使用这些不同模式的更多文档，请参阅 HTTP API。

部署表

下表显示了各种集群大小的法定人数大小和容错能力。推荐的部署是 3 或 5 个服务器。强烈建议不要使用单个服务器部署，因为在故障情况下数据丢失是必然的。

Servers - 服务器数量	Quorum Size - 法定人数大小	容忍故障的服务器数量
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2
6	4	2
7	4	3

Gossip 协议

Paxos、Raft、ZAB 等分布式算法经常会被称作是“强一致性”的分布式共识协议，其实这样的描述扣细节概念的话是很别扭的，会有语病嫌疑，但我们都明白它的意思其实是在说“尽管系统内部节点可以存在不一致的状态，但从系统外部看来，不一致的情况并不会被观察到，所以整体上看系统是强一致性的”。与它们相对的，还有另一类被冠以“最终一致性”的分布式共识协议，这表明系统中不一致的状态有可能会在一定时间内被外部直接观察到。一种典型且极为常见的最终一致的分布式系统就是DNS 系统，在各节点缓存的 TTL 到期之前，都有可能与真实的域名翻译结果存在不一致。在本节中，笔者将介绍在比特币网络和许多重要分布式框架中都有应用的另一种具有代表性的“最终一致性”的分布式共识协议：Gossip 协议。

Gossip 最早由施乐公司（Xerox，现在可能很多人不了解施乐了，或只把施乐当一家复印产品公司看待，这家公司是计算机许多关键技术的鼻祖，图形界面的发明者、以太网的发明者、激光打印机的发明者、MVC 架构的提出者、RPC 的提出者、BMP 格式的提出者……） Palo Alto 研究中心在论文《Epidemic Algorithms for Replicated Database Maintenance》中提出的一种用于分布式数据库在多节点间复制同步数据的算法。从论文题目中可以看出，最初它是被称作“流行病算法”（Epidemic Algorithm）的，只是不太雅观，今天 Gossip 这个名字已经用得更为普遍了，除此以外，它还有“流言算法”、“八卦算法”、“瘟疫算法”等别名，这些名字都是很形象化的描述，反应了 Gossip 的特点：要同步的信息如同流言一般传播、病毒一般扩散。

上图是 Gossip 传播过程的示意图，根据示意图和 Gossip 的过程描述，我们很容易发现 Gossip 对网络节点的连通性和稳定性几乎没有任何要求，它一开始就将网络某些节点只能与一部分节点部分连通（Partially Connected Network）而不是以全连通网络（Fully Connected Network）作为前提；能够容忍网络上节点的随意地增加或者减少，随意地宕机或者重启，新增加或者重启的节点的状态最终会与其他节点同步达成一致。Gossip 把网络上所有节点都视为平等而普通的一员，没有任何中心化节点或者主节点的概念，这些特点使得 Gossip 具有极强的鲁棒性，而且非常适合在公众互联网中应用。

同时我们也很容易找到 Gossip 的缺点，消息最终是通过多个轮次的散播而到达全网的，因此它必然会存在全网各节点状态不一致的情况，而且由于是随机选取发送消息的节点，所以尽管可以在整体上测算出统计学意义上的传播速率，但对于个体消息来说，无法准确地预计到需要多长时间才能达成全网一致。另外一个缺点是消息的冗余，同样是由于随机选取发送消息的节点，也就不可避免的存在消息重复发送给同一节点的情况，增加了网络的传输的压力，也给消息节点带来额外的处理负载。

达到一致性耗费的时间与网络传播中消息冗余量这两个缺点存在一定对立，如果要改善其中一个，就会恶化另外一个，由此，Gossip 设计了两种可能的消息传播模式：反熵（Anti-Entropy）和传谣（Rumor-Mongering），这两个名字都挺文艺的。熵（Entropy）是生活中少见但科学中很常用的概念，它代表着事物的混乱程度。反熵的意思就是反混乱，以提升网络各个节点之间的相似度为目标，所以在反熵模式下，会同步节点的全部数据，以消除各节点之间的差异，目标是整个网络各节点完全的一致。但是，在节点本身就会发生变动的前提下，这个目标将使得整个网络中消息的数量非常庞大，给网络带来巨大的传输开销。而传谣模式是以传播消息为目标，仅仅发送新到达节点的数据，即只对外发送变更信息，这样消息数据量将显著缩减，网络开销也相对较小。

Consul 使用 gossip 协议 来管理成员并向集群广播消息。所有这些都是通过使用 Serf 库提供的。Serf 使用的 gossip 协议基于“SWIM: Scalable Weakly-consistent Infection-style Process Group Membership Protocol”，做了一些小的修改。这里有关于 Serf 协议的更多细节。

Gossip in Consul

Consul 使用了两个不同的 gossip 池。我们将每个池分别称为 LAN 或 WAN 池。每个数据中心 Consul 都有一个 LAN gossip 池，其中包含数据中心的所有成员，包括客户端和服务器。LAN 池有几个用途。其中成员信息允许客户端自动发现服务器，从而减少所需的配置量；分布式故障检测允许故障检测的工作由整个集群共享，而不是集中在少数服务器上；最后，gossip 池允许可靠且快速的事件广播。

WAN 池是全局唯一的，因为无论数据中心如何，所有服务器都应参与 WAN 池。 WAN 池提供的成员信息允许服务器执行跨数据中心请求。集成的故障检测允许 Consul 优雅地处理丢失连接的整个数据中心，或仅处理远程数据中心中的单个服务器。

所有这些功能都是通过利用 Serf 提供的。它用作嵌入式库以提供这些功能。从用户的角度来看，这并不重要，因为抽象而被 Consul 屏蔽。然而，作为开发人员，了解如何利用该库是很有用的。

Lifeguard 增强

SWIM 假设本地节点是健康的，因为可以对数据包进行软实时处理。但是，在本地节点遇到 CPU 或网络耗尽的情况下，可能会违反此假设。结果就是 serfHealth 检查状态偶尔会抖动，导致错误的监控警报，给远程监测增加误判，并会导致整个集群浪费 CPU 和网络资源来诊断可能并不真正存在的故障。

Lifeguard 通过对 SWIM 的特别增强完全解决了这个问题。

有关 Lifeguard 的更多详细信息，请参阅 Lifeguard 博客文章【使 gossip 更健壮】，其中提供了 HashiCorp 研究论文 Lifeguard：SWIM-ing with Situational Awareness 的高级概述。Serf gossip 协议指南还提供了一些关于 gossip 协议和 Lifeguard 的较低级别的详细信息。

反墒 - Anti-Entropy

Consul 使用一种先进的方法来维护服务和健康信息。此页面详细介绍了如何注册服务和检查、如何填充目录以及如何在更改时更新健康状态信息。

组件

首先了解服务和健康检查中涉及的移动部分很重要：agent 和 catalog。下面从概念上描述了这些，以使反熵更容易理解。

Agent

每个 Consul 代理维护自己的一组服务并检查注册以及健康信息。代理负责执行自己的健康检查并更新其本地状态。

代理上下文中的服务和检查具有一组丰富的可用配置选项。这是因为代理负责通过使用健康检查生成有关其服务及其健康状况的信息。

Catalog

Consul 的服务发现由服务目录支持。该目录由代理提交的信息聚合而成。该目录维护集群的高级视图，包括哪些服务可用、哪些节点运行这些服务、运行状况信息等。该目录用于通过 Consul 提供的各种接口公开此信息，包括 DNS 和 HTTP。

与代理相比，目录上下文中的服务和检查的字段集更为有限。这是因为目录只负责记录和返回有关服务、节点和健康状况的信息。

目录仅由服务器节点维护。这是因为目录是通过 Raft 日志复制的，以提供集群的统一和一致的视图。

Anti-Entropy

熵是系统变得越来越无序的趋势。 Consul 的反熵机制旨在对抗这种趋势，即使在其组件出现故障时也能保持集群的状态有序。

如上所述，Consul 在全局服务目录和代理的本地状态之间有明确的分离。反熵机制调和了这两种世界观：反熵是本地代理状态和目录的同步。例如，当用户注册新服务或向代理进行检查时，代理会依次通知目录此新服务存在。同样，当从代理中删除服务时，它也会从目录中删除。

反熵也用于更新可用性信息。当代理运行他们的健康检查时，他们的状态可能会发生变化，在这种情况下，他们的新状态会同步到目录中。使用此信息，目录可以根据节点和服务的可用性智能地响应有关其节点和服务的查询。

在此同步过程中，还会检查目录的正确性。如果目录中存在代理不知道的任何服务或检查，它们将被自动删除，以使目录反映该代理的正确服务和健康信息集。 Consul 将代理的状态视为权威；如果代理视图和目录视图之间存在任何差异，将始终使用代理本地视图。

定期同步

除了在代理发生更改时运行之外，反熵也是一个长期运行的过程，它会定期唤醒以同步服务并检查目录状态。这可确保目录与代理的真实状态密切匹配。即使在数据完全丢失的情况下，这也允许 Consul 重新填充服务目录。

为避免饱和，周期性反熵运行之间的时间量将根据集群大小而变化。下表定义了集群大小和同步间隔之间的关系：

集群大小	同步周期间隔
1 - 128	1 minute
129 - 256	2 minutes
257 - 512	3 minutes
513 - 1024	4 minutes
…	…

上面的间隔是近似值。每个 Consul 代理将在间隔窗口内选择一个随机交错的开始时间，以避免雷鸣般的羊群。

最大努力交付

反熵可能会在多种情况下失败，包括代理或其操作环境的错误配置、I/O 问题（磁盘满、文件系统权限等）、网络问题（代理无法与服务器通信）等。因此，代理会尝试以最大努力的方式进行同步。

如果在反熵运行期间遇到错误，则会记录该错误并继续运行代理。反熵机制会定期运行以自动从这些类型的瞬态故障中恢复。

启用标签覆盖

可以部分修改服务注册的同步，以允许外部代理更改服务的标签。这在需要外部监控服务作为标签信息真实来源的情况下非常有用。比如 Redis 数据库和它的监控服务 Redis Sentinel 就有这种关系。 Redis 实例负责其大部分配置，但哨兵决定 Redis 实例是主实例还是辅助实例。使用 Consul 服务配置项 enable_tag_override 可以指示运行 Redis 数据库的 Consul 代理在反熵同步期间不更新标签。有关更多信息，请参阅服务页面。

所需端口

Consul 需要多达 6 个不同的端口才能正常工作，其中一些使用 TCP、UDP 或两种协议。下面我们记录了每个端口的要求。

端口表

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

用途	默认端口号
DNS: The DNS server (TCP and UDP)	8600
HTTP: The HTTP API (TCP Only)	8500
HTTPS: The HTTPs API	disabled (8501)*
gRPC: The gRPC API	disabled (8502)*
LAN Serf: The Serf LAN port (TCP and UDP)	8301
Wan Serf: The Serf WAN port (TCP and UDP)	8302
server: Server RPC address (TCP Only)	8300
Sidecar Proxy Min: 用于自动分配的边车服务注册的最小端口号。	21000
Sidecar Proxy Max: 用于自动分配的边车服务注册的最大端口号。	21255

*对于 HTTPS 和 gRPC，表中指定的端口只是建议。

端口信息

DNS 接口 用于解析 DNS 查询。

HTTP API 客户端使用它来与 HTTP API 对话，包括 UI 访问。

HTTPS API（可选）默认关闭，但端口 8501 是各种工具使用的默认约定。

gRPC API（可选）。目前 gRPC 仅用于向 Envoy 代理公开 xDS API。默认情况下它是关闭的，但端口 8502 是各种工具使用的默认约定。在 -dev 模式下默认为 8502。

Serf LAN 用于处理 LAN 中的 gossip。所有 agent 代理都需要该端口。

Serf WAN 服务器使用它来通过 WAN 向其他服务器进行 gossip。从 Consul 0.8 开始，WAN 加入泛洪功能要求 Serf WAN 端口（TCP/UDP）同时监听 WAN 和 LAN 接口。另请参阅：Consul 0.8.0 CHANGELOG 和 GH-3058。

服务器 RPC 服务器使用它来处理来自其他代理的传入请求。

请注意，可以在代理配置中更改默认端口。

原文链接：Consul 入门