consul架构

在将应用程序迁移到动态预配置的基础架构时，将面临扩展服务和管理它们之间的通信的挑战。 Consul通过提供服务发现来帮助动态应用程序的组件彼此通信。它监视每个节点和应用程序的运行状况，以便仅将运行状况正常的实例公开为可发现的。 Consul的分布式键值存储使您可以在全球基础架构中进行运行时配置更新。

本文档推荐了最佳实践，并提供了参考体系结构，包括针对Consul生产部署的系统要求，数据中心设计，网络和性能优化。

基础设施要求

consul server

Consul server agent 维护集群状态，响应RPC查询（读取操作），并处理所有写入操作。由于Consul server agent承担了大部分繁重的工作，因此其主机大小对于Consul集群的整体性能，效率和运行状况至关重要。

下表提供了服务器主机准则。特别要注意的是，强烈建议避免使用非固定性能的CPU，或 “Burstable CPU”。

• 小资源类型适用于大多数初始生产部署或开发/测试环境。
• 大资源类型适用于工作负载持续较高的生产环境。

架构

数据中心设计

可以在单个物理数据中心或跨多个数据中心部署Consul集群（通常是三或五个服务器加上客户端代理）。对于具有高运行时间读写的大型集群，将服务器部署在相同的物理位置可以提高性能。在云环境中，您可以跨多个可用性区域（即，每个服务器位于单个主机上单独的可用性区域中）部署单个数据中心。 Consul还通过通过WAN链接加入的单独集群支持多数据中心部署。在某些情况下，您可能还会在同一LAN环境中部署两个或多个Consul集群。

单数据中心

对于部署在同一数据中心中的应用程序，我们建议使用单个Consul群集。 Consul支持传统的三层应用程序以及微服务。

通常，您将需要三到五台服务器来平衡可用性和性能。这些服务器一起运行Raft驱动的一致状态存储，以更新目录，会话，准备好的查询，ACL和KV状态。

单个数据中心的建议最大集群大小为5,000个节点。对于大量写入和/或大量读取的集群，您可能需要进一步减少最大节点数，具体取决于KV对的数量和大小以及监视的数量。当您添加更多客户端计算机时，gossip将花费更多时间。同样，当新服务器加入具有大型KV存储的现有数千节点集群时，可能需要更多时间才能将存储复制到新服务器的日志中，并且更新率可能会提高。

对于繁重的集群，请考虑使用较大的计算机实例和较低的延迟存储垂直扩展。

服务标签可帮助您对集群进行必要的查询。它们可以帮助您区分不同的服务或同一服务的不同版本。没有它们，就不可能基于特定服务进行节点搜索。

如果agents由于网络分段而无法彼此通信，则可以使用Consul的网段（仅限Consul Enterprise）来创建共享同一集群中Raft服务器的多个租户。每个租户都有自己的gossip池，并且不与该池外的代理进行通信。但是，所有租户都共享KV存储。如果您无权访问Consul网段，则可以创建离散的Consul数据中心以将代理彼此隔离。

多数据中心

您可以通过WAN链接加入在不同数据中心中运行相同服务的Consul集群。集群独立运行，并且仅通过端口8302上的WAN通信。除非通过CLI或API明确配置，否则Consul服务器将仅从其本地数据中心返回结果。 Consul不会在多个数据中心之间复制数据，但是您可以使用consul-replicate工具定期复制KV数据。

好的做法是启用TLS服务器名称检查，以避免代理意外交叉连接。

Consul Enterprise中的网络区域功能提供了高级联盟。例如，假设datacenter1（dc1）托管诸如LDAP（或ACL数据库）之类的服务，并与datacenter2（dc2）和datacenter3（dc3）共享它们。但是，由于合规性问题，dc2中的服务器不得与dc3中的服务器连接。基本的WAN联合无法将dc2与dc3隔离；它要求dc1，dc2和dc3中的所有服务器都以全网状连接，并同时打开gossip（8302 tcp / udp）和RPC（8300）端口以进行通信。

网络区域允许在数据中心之间建立对等关系，以使共享服务可以通过WAN发现。在网络区域中，dc1中的服务器可以与dc2和dc3中的服务器进行通信，而无需在dc2和dc3之间建立连接。在我们的示例用例中，这满足了组织的合规性要求。属于网络区域的服务器仅通过RPC进行通信。这消除了跨数据中心共享和维护gossip协议所使用的对称密钥的开销。由于gossip端口不再需要在安全网关或防火墙中打开，因此它也减少了gossip端口的攻击面。

Consul准备好的查询使客户端可以故障转移到另一个数据中心进行服务发现。例如，如果本地数据中心dc1中的服务下降，则准备好的查询使用户可以定义到最近数据中心的地理回退顺序，以检查同一服务的正常实例。

Consul集群必须是WAN链接的，才能进行预准备的查询以跨数据中心工作。

默认情况下，准备好的查询会首先在本地数据中心中解析查询。它们不支持查询KV store 功能，并且可以使用ACL。准备好的查询配置/模板在Raft中保持一致，并在服务器上执行。

网络连接

LAN gossip 发生在单个数据中心的所有代理之间，每个代理向其成员列表中的随机代理发送定期探测。客户端代理和服务器代理都参与了gossip。初始探测每秒通过UDP发送一次。如果节点在200ms内未确认，代理将通过TCP ping通。如果TCP探测失败（10秒超时），它将要求可配置数量的随机节点探测同一节点（也称为间接探测）。如果没有来自对等方的关于节点状态的响应，则该代理被标记为已关闭。

代理的状态直接影响服务发现结果。如果代理关闭，则它正在监视的服务也将标记为关闭。

此外，代理还通过TCP定期执行完整状态同步，此过程使每个代理了解其周围的成员列表（节点名称，IP地址和运行状况）。相对于上述标准gossip协议，这些操作昂贵，并且以集群大小确定的速率执行以保持较低的开销。通常在30秒到5分钟之间。有关更多详细信息，请参阅Serf Gossip文档。

在跨L3个网段的较大网络中，流量通常会穿越防火墙和/或路由器。您必须更新ACL或防火墙规则以允许以下端口：

默认情况下，代理将仅侦听本地接口上的HTTP和DNS通信。