Consul 是一种服务网络解决方案（service networking solution），使团队能够管理服务之间以及跨多云环境和运行时的安全化网络连接。 Consul 提供服务发现、基于身份的授权、L7 流量管理和服务到服务加密。

什么是 Consul

Consul 提供了一个控制平面，使您能够注册、查询和保护跨网络部署的服务。控制平面是网络基础设施的一部分，用于维护中央注册表以跟踪服务及其各自的 IP 地址。它是一个运行在集群节点上的分布式系统，例如物理服务器、云实例、虚拟机或容器。

Consul 通过代理与数据平面交互。数据平面是处理数据请求的网络基础设施的一部分。详细信息请参阅 Consul 架构。

Consul 的核心工作流程包括以下阶段：

1. 注册：团队将服务添加到 Consul 目录中，该目录是一个中央注册表（central registry），允许服务自动发现彼此，而不需要人工操作来修改应用程序代码、部署额外的负载均衡器或硬编码 IP 地址。它（consul）是所有服务及其地址的运行时事实来源。团队可以通过 CLI 或 API 手动定义和注册服务，或者可以在 Kubernetes 中使用服务同步自动化这个过程。服务还可以包括健康检查，以便 Consul 能够监控不健康的服务。

2. 查询：Consul 基于身份的 DNS 让您可以在 Consul 目录中找到健康的服务。注册到 Consul 的服务提供健康信息、访问点和其他数据，这些数据有助于您控制网络中的数据流。您的服务只能通过其本地代理根据您定义的基于身份的策略访问其他服务。

3. 安全：在服务定位到上游服务后，Consul 确保服务间通信是经过身份验证、授权和加密的。Consul 服务网格通过 mTLS 来保护微服务架构，并可以基于服务身份允许或限制访问，无论计算环境和运行时的差异。

Consul 提高了应用程序的弹性，延长了正常运行时间，加速了应用程序部署，并提高了服务间通信的安全性。 HashiCorp 联合创始人兼首席技术官 Armon Dadgar 解释了 Consul 如何解决网络挑战。

youtu.be/mxeMdl0KvBI

• Monolith Architecture:

  • 定义：一个大应用程序包含所有功能模块。
  • 示例：桌面银行应用。
    • Subsystem A：登录。
    • Subsystem B：显示账户余额。
    • Subsystem C：转账。
    • Subsystem D：外币兑换。
  • 问题：更新一个子系统时需要更新整个应用；一个子系统的bug可能影响整个系统。

• Microservices Architecture:

  • 定义：将大应用分解为独立的微服务，各自独立部署。
  • 优点：
    • 独立更新和部署。
    • 灵活的开发和发布周期。
    • 各开发团队可以独立工作。
  • 挑战：
    • 服务发现：如何在不同服务之间进行通信。
    • 配置管理：如何在分布式系统中管理配置。
    • 访问控制：如何确保服务之间的安全通信。

• 服务发现：

  • 传统方法：通过负载均衡器进行服务间通信。
    • 问题：负载均衡器数量多，手动管理复杂。
  • 解决方案：使用中央服务注册表。
    • 操作步骤：
      • 服务启动时注册到服务注册表。
      • 服务A需要与服务B通信时，通过注册表查找服务B的实例。
      • 直接通信而不通过负载均衡器。

• 配置管理：

  • 传统方法：使用大型XML配置文件。
    • 问题：分布式环境中难以管理。
  • 解决方案：使用中央配置存储（如Consul的key-value存储）。
    • 操作步骤：
      • 在中央位置存储配置。
      • 动态更新配置，例如切换维护模式。

• 网络分段与访问控制：

  • 传统网络结构：
    • DMZ（隔离区）：处理外部流量。
    • 应用区：应用程序所在区域。
    • 数据区：数据存储区域。
  • 现代需求：服务间复杂的东西向通信。
    • 问题：如何在分布式环境中管理服务间通信。
  • 解决方案：使用服务图（Service Graph）和连接（Connect）功能。
    • 服务图：定义服务之间的通信规则。
    • 代理（Proxy）：每个服务旁运行一个代理，用于身份验证和加密通信。

• 加密与身份验证：

  • 问题：确保服务间通信的安全。
  • 解决方案：使用TLS证书和代理。
    • 操作步骤：
      • 每个服务使用唯一的TLS证书进行身份验证。
      • 代理在服务间建立加密通道。
      • 确保数据传输的隐私和安全。

• 总结：

  • 从单体架构过渡到微服务架构，提高了开发效率和灵活性。
  • 需要解决的挑战包括服务发现、配置管理和访问控制。
  • 服务网格（Service Mesh）是实现微服务架构的关键组件。

自动化服务发现

在云基础设施上采用微服务架构是实现大规模价值交付的关键步骤，但实时了解健康服务在网络上的运行位置成为一个挑战。Consul 通过用基于身份的服务目录替代通常由负载均衡器处理的服务连接来自动化服务发现。服务目录是一个集中式的事实来源，您可以通过 Consul 的 DNS 服务器或 API 查询。目录始终知道哪些服务可用，哪些服务已被移除，以及哪些服务是健康的。

跨运行时和云提供商连接服务

现代组织可能会在多个区域内将服务部署到本地基础设施环境和公共云提供商的组合中。服务可能运行在裸机、虚拟机或 Kubernetes 集群中的容器上。

Consul 将网络流量路由到服务需要到达的任何运行时或基础设施环境。你还可以使用 Consul API 网关将流量路由进出（into and out）网络。Consul 服务网格提供了额外的功能，如在服务之间的通信安全、流量管理和可观察性，而无需更改应用程序代码。

Consul 还与 Kubernetes 进行了许多集成，使您能够在容器化环境中利用 Consul 功能。例如，Consul 可以自动将 sidecar 代理注入到 Kubernetes Pods 中，并将 Kubernetes 服务和非 Kubernetes 服务同步到 Consul 服务注册表中，而无需手动更改应用程序或更改 Pod 定义。

您还可以使用 HashiCorp Nomad 调度 Consul 工作负载，以在 Nomad 作业和任务组之间提供安全的服务到服务通信。

实现零信任网络安全

微服务架构复杂且难以防止恶意行为者的意外披露。Consul 提供了多种增强网络安全的机制，而无需更改您的应用程序代码，包括在所有服务间流量上进行的双向传输层安全（mTLS）加密和 Consul 意图，这些是您可以通过 Consul UI、API 和 CLI 管理的服务到服务权限。

当您将 Consul 部署到 Kubernetes 集群时，还可以与 HashiCorp Vault 集成以管理敏感数据。默认情况下，Kubernetes 上的 Consul 利用 Kubernetes secrets 作为后端系统。Kubernetes secrets 是 base64 编码的，未加密，且缺乏租约或生存时间属性。通过利用 Vault 作为 Kubernetes 上 Consul 的 secrets 后端，您可以在集中化的 Vault 集群中管理和存储 Consul 相关的 secrets，以便在一个或多个 Kubernetes 数据中心上使用。有关详细信息，请参阅 Vault 作为 Secrets 后端。

您还可以通过在访问控制列表（ACL）中定义安全策略来保护您的 Consul 部署本身，以控制对数据和 Consul API 的访问。

保护你的服务免受网络故障的影响

停电是不可避免的，但对于分布式系统来说，确保一个数据中心的电力故障不会中断下游服务操作是至关重要的。您可以启用自动备份、冗余区、只读副本和其他功能，以防止灾难性事件后数据丢失和停机。L7 可观察性功能还在 Consul UI 中提供服务流量指标，帮助您了解服务及其在网格中的连接状态。

动态更新网络基础设施设备

网络变更，包括日常操作任务如更新网络设备端点和防火墙或负载均衡器规则，可能导致在关键时刻中断操作的问题。您可以部署 Consul-Terraform-Sync（CTS）插件，以在服务变更时动态更新网络基础设施设备。CTS 监控存储在 Consul 中的服务信息，并在 Consul 注册变更时自动启动 HashiCorp Terraform 实例，以推动相关网络基础设施的变更，从而减少配置网络基础设施的手动工作量。

优化流量路由以用于部署和测试场景

在复杂的网络环境中推出变更可能具有风险。更新后的服务在连接到其他服务时可能不会按预期行为，导致上游或下游问题。Consul 服务网格支持第七层（L7）流量管理，使您可以将 L7 流量划分为不同的服务实例子集。这使您可以将服务池划分用于金丝雀测试、A/B 测试、蓝/绿部署和软多租户（prod/qa/staging 共享计算资源）部署。

为什么选择 Consul

HashiCorp Consul 是一个服务网络平台（service networking platform），包含多种功能来保护和简化网络服务管理（network service management）。这些功能包括服务网格、服务发现、配置管理和 API 网关功能。虽然竞争产品提供了其中一些核心功能，但 Consul 的开发是为了解决以上四个核心问题。本节中的主题概述了 Consul 的功能与市场上其他一些工具的比较。

Consul 与其他服务网格软件的比较

示例：Istio、Solo Gloo Mesh、Linkerd、Kong/Kuma、AWS App Mesh

Consul 的服务网格允许组织在多个不同环境中安全连接和管理它们的网络服务。使用 Envoy 作为每个服务附加的 Sidecar 代理，Consul 确保所有服务间的通信都经过授权、认证和加密。Consul 包括负载均衡和流量分流（traffic splitting）等流量管理功能，帮助开发人员进行金丝雀测试、A/B 测试和蓝绿部署。Consul 还包括健康检查和可观察性功能。

Consul 是平台无关的 —— 它支持任何运行时（Kubernetes、EKS、AKS、GKE、VM、ECS、Lambda、Nomad）和任何云提供商（AWS、Microsoft Azure、GCP、私有云）。这使得它成为最灵活的服务发现和服务网格平台之一。虽然其他服务网格软件为数据平面支持多个运行时，但它们要求您将控制平面仅在 Kubernetes 上运行。而使用 Consul，您可以在不同的运行时中同时运行控制平面和数据平面。

Consul 还与 Vault 有几个独特的集成，Vault 是一个行业标准的 secrets 管理（secrets management）工具。运维人员可以选择使用 Consul 的内置证书颁发机构（certificate authority），或利用 Vault 的 PKI 引擎为数据平面和控制平面生成和存储 TLS 证书。此外，Consul 可以在数据平面和控制平面上自动轮转（rotate） TLS 证书，无需任何重启。这使得您可以更频繁地轮换（rotate）证书，而不会给运维人员增加额外的管理负担。在将 Consul 部署在 Kubernetes 上时，您可以将包括许可证、ACL 令牌和 TLS 证书等敏感数据集中存储在 Vault 中，而不是 Kubernetes secrets 中。Vault 比 Kubernetes secrets 更安全，因为它自动加密所有数据，为 secrets 提供高级访问控制，并为所有 secrets 提供集中治理。

Consul 与其他 DNS 工具的比较

示例：NS1、AWS Route53、AzureDNS、Cloudflare DNS

Consul 最初设计为一个集中式的服务注册表，适用于任何动态跟踪计算基础架构（compute infrastructure）中添加、更改或删除的服务的云环境。Consul 维护一个注册的服务目录及其属性，如 IP 地址或服务名称。有关更多信息，请参阅什么是服务发现？。

因此，Consul 还可以提供基本的 DNS 功能，包括查找、备用域和访问控制。由于 Consul 是平台无关的，您可以跨云和本地数据中心检索服务信息。Consul 本身不原生支持一些高级 DNS 功能，如过滤器或高级路由逻辑。但是，您可以将 Consul 与现有的 DNS 解决方案集成，如 NS1 和 DNSimple，以支持这些高级功能。

Consul 与其他配置管理工具的比较

例子：Chef、Puppet

有许多配置管理工具，它们通常专注于静态配置（static provisioning）。然而，Consul 使您能够根据服务和节点状态动态配置您的服务。静态和动态配置都很重要，可以很好地结合使用。由于 Consul 提供了多种不同的功能，有时其功能会与其他配置管理工具重叠。

例如，Chef 和 Puppet 是可以构建服务发现机制的配置管理工具。然而，它们只支持静态配置信息。因此，实施更新的时间取决于转换运行的频率（the frequency of conversion runs）（几分钟到几小时）。此外，这些工具不允许您在配置中包含系统状态。这可能导致负载均衡器将流量发送到不健康的节点，进一步恶化问题。使用这些工具支持多个数据中心也很具挑战性，因为一组中心服务器必须管理所有数据中心。

Consul 的服务发现层专门设计用于动态跟踪和响应服务的状态。通过使用集成的健康检查，Consul 可以将流量从不健康的节点路由到其他节点，允许系统和服务优雅地恢复。此外，Consul 的服务发现层与 Terraform 兼容。Consul-Terraform-Sync (CTS) 根据每个服务的动态更改自动更新网络基础设施。例如，随着服务的扩展或收缩，CTS 可以触发 Terraform 更新防火墙或负载均衡器以反映最新的更改。此外，由于每个数据中心都可以独立运行，支持多个数据中心与支持单个数据中心没有区别。

Consul 并不是其他配置管理工具的替代品。这些工具仍然至关重要，用于设置应用程序，包括 Consul。静态配置最好由现有工具管理，而 Consul 使您能够利用动态配置和服务发现。

通过将配置管理和集群管理工具分开，您可以利用更简单的工作流程：

• 不再需要定期运行服务或配置更改。
• Chef 的配方和 Puppet 的清单更简单，因为它们不需要全局状态。
• 基础设施可以变得不可变，因为配置管理运行不需要全局状态。

Consul 与其他 API 网关的比较

示例: Kong Gateway, Apigee, Mulesoft, Gravitee

Consul API Gateway 是 Kubernetes Gateway API 的一种实现。传统上，API 网关用于两个主要目的：客户端流量管理和 API 生命周期管理。

客户端流量管理指的是 API 网关在控制公共流量进入特定环境的入口点时所起的作用，也称为管理南北向流量。Consul API Gateway 与 Consul 服务网格一起部署，负责根据定义的路由将入站客户端请求路由到网格中。有关支持的完整流量管理功能列表，请参阅 Consul API Gateway 文档。

API 生命周期管理指的是应用开发人员如何使用 API 网关来部署、迭代和管理 API 的版本。目前，Consul API Gateway 不支持 API 生命周期管理。

Consul 核心概念

服务发现

服务发现帮助您在网络中发现、跟踪和监控服务的健康状态。服务发现会在服务目录（service catalog）中注册和维护所有服务的记录。这个服务目录作为唯一的真实数据源（single source of truth），允许您的服务互相查询和通信。

服务发现的好处

服务发现为所有组织提供了诸多好处，从简化的可扩展性到改进的应用弹性（application resiliency）。服务发现的一些好处包括：

• 动态 IP 地址和端口发现
• 简化水平服务扩展
• 将发现逻辑从应用程序中抽离出来
• 通过健康检查确保可靠的服务通信
• 在健康的服务实例间负载均衡请求
• 通过高速发现实现更快的部署时间
• 自动化服务注册和注销

服务发现如何工作？

服务发现使用服务的身份信息而不是传统的访问信息（IP 地址和端口）。这使您能够动态映射服务并跟踪服务目录中的任何变化。服务消费者（用户或其他服务）然后使用 DNS 从服务目录中动态检索其他服务的访问信息。服务的生命周期可能如下所示：

服务消费者通过服务目录提供的唯一 Consul DNS 条目与 “Web” 服务进行通信。

“Web” 服务的新实例将其 IP 地址和端口注册到服务目录中。随着新实例注册到服务目录，它们将参与负载均衡池，以处理服务消费者的请求。

随着新服务实例的添加以及遗留或不健康的服务实例的删除，服务目录会动态更新。已删除的服务将不再参与负载均衡池来处理服务使用者的请求。

什么是微服务中的服务发现？

在微服务应用程序中，活动服务实例集在大型动态环境中频繁变化。这些服务实例依赖于服务目录来从相应的服务检索最新的访问信息。可靠的服务目录对于微服务中的服务发现尤其重要，以确保健康、可扩展且高度响应的应用程序运行。

服务发现的两种主要类型是什么？

服务发现主要有两种模式：客户端发现和服务器端发现。

在使用客户端发现的系统中，服务消费者负责确定可用服务实例的访问信息并在它们之间进行负载均衡。

1. 服务消费者查询服务目录
2. 服务目录检索并返回所有的访问信息
3. 服务消费者选择一个健康的下游服务并直接向其发出请求

在使用服务器端发现的系统中，服务消费者使用中介（intermediary）查目录并向其发出请求。

1. 服务消费者查询中介（如 Consul）
2. 中介查询服务目录并将请求路由到可用的服务实例

对于现代应用程序来说，这种发现方法是有利的，因为开发人员可以通过解耦和集中服务发现逻辑来使他们的应用程序更快、更轻量。

服务发现与负载均衡

服务发现和负载均衡在将请求分发到后端服务方面有相似之处，但在许多重要方面存在差异。

传统负载均衡器并非设计用于快速注册和注销服务，也不是为了高可用性而设计的。相比之下，服务发现系统使用多个节点来维护服务注册表状态，并使用对等（peer-to-peer）管理系统，以增强在任何类型基础设施中的弹性。

对于现代的基于云的应用程序，服务发现是引导流量到正确服务提供者的首选方法，因为它能够独立于基础设施进行扩展并保持弹性。

如何实现服务发现？

您可以在任何类型的基础设施中实现服务发现系统，无论是本地部署还是云端。服务发现是许多容器编排工具（如 Kubernetes 或 Nomad）的原生功能。对于非容器化工作负载（如虚拟机和无服务器技术），也有平台无关的服务发现方法可用。实现一个弹性的服务发现系统需要创建一组服务器来维护和促进服务注册操作。您可以通过安装服务发现系统或使用托管的服务发现服务来实现这一点。

什么是 Consul

Consul 是一种服务网络解决方案，可以让你自动化网络配置、发现服务，并在任何云或运行时环境中实现安全连接。凭借这些功能，Consul 帮助您解决操作微服务和云基础设施（多云和混合云）的复杂网络和安全挑战。您可以独立或结合使用这些功能以实现零信任安全。

Consul 的服务发现功能帮助你在网络中发现、跟踪和监控服务的健康状态。Consul 作为一个单一的真实来源，让你的服务可以相互查询和通信。

你可以将 Consul 与虚拟机（VM）、容器、无服务器技术或容器编排平台（如 Nomad 和 Kubernetes）一起使用。Consul 是平台无关的，这使它非常适合所有环境，包括遗留平台。

Consul 可以作为自管理项目或完全托管的服务网格解决方案（HCP Consul Dedicated）使用。HCP Consul Dedicated 使用户能够发现和安全连接服务，而无需自行维护服务网格的额外运营负担。

服务网格

服务网格是一个专用网络层，可在基础设施内部和跨基础设施（包括本地和云环境）提供安全的服务到服务通信。服务网格通常与微服务架构模式一起使用，但可以在涉及复杂网络的任何场景中提供价值。

服务网格的好处

服务网格为所有组织提供了诸多好处，从安全性到改进应用程序弹性。服务网格的一些好处包括：

• 服务发现
• 应用健康监控
• 负载均衡
• 自动故障转移
• 流量管理
• 加密
• 可观测性和可追溯性
• 身份验证和授权
• 网络自动化

服务网格的一个常见用例是实现零信任模型。在零信任模型中，应用程序需要基于身份的访问（identity-based access），以确保服务网格内的所有通信都通过 TLS 证书进行身份验证并在传输过程中加密。

在传统的安全策略中，保护主要集中在网络的外围。在云环境中，网络访问的表面积（surface area）比传统的本地（on-premises）网络要广得多。此外，传统的安全实践忽视了许多恶意行为者可能来自网络内部的事实。零信任模型解决了这些问题，同时允许组织根据需要进行扩展。

服务网格如何工作？

服务网格通常由控制平面和数据平面组成。控制平面维护一个中央注册表，跟踪所有服务及其各自的IP地址。这一活动称为服务发现。只要应用程序注册到控制平面，控制平面就能够与网格中的其他成员分享如何与该应用通信，并强制执行谁可以相互通信的规则。

控制平面负责保护网格、促进服务发现（facilitating service discovery）、健康检查（health checking）、策略执行（policy enforcement）和其他类似的运维问题。

数据平面处理服务之间的通信。许多服务网格解决方案使用边车代理来处理数据平面通信，从而限制服务对网络环境的了解程度（limit the level of awareness the services need to have about the network environment）。

API 网关与服务网格

API 网关是一个集中的访问点，用于处理传入的客户端请求并将其传递给服务。 API 网关充当控制平面，允许运维和开发人员管理传入（incoming）的客户端请求并根据请求应用不同的处理逻辑。 API 网关会将传入请求路由到相应的服务。 API 网关的主要功能是处理请求并将服务的响应返回给客户端。

服务网格专门负责服务的网络管理和服务之间的通信。网格负责跟踪服务及其健康状态、IP 地址和流量路由，并确保服务之间的所有流量都经过身份验证和加密。与某些 API 网关不同，服务网格将跟踪所有注册服务的生命周期，并确保请求路由到服务的健康实例。 API 网关通常与负载均衡器一起部署，以确保流量被引导到健康且可用的服务实例。服务网格减少了负载均衡器的负担，因为路由职责以去中心化的方式处理。

API 网关可以与服务网格一起使用，将外部网络（非网格）与服务网格连接起来。

API 网关和流量方向：API 网关通常用于接受南北向流量。南北向流量是指进入或离开数据中心或虚拟私有网络（VPC）的网络流量。你可以将 API 网关连接到服务网格并提供从网格外部对其的访问。服务网格主要用于处理东西向流量。东西向流量通常保持在数据中心或 VPC 内部。服务网格可以连接到另一个数据中心或 VPC 中的另一个服务网格，以形成联合网格。

服务网格解决什么问题？

现代基础设施正从主要静态转变为动态（短暂性）。这种动态基础设施的生命周期较短，意味着虚拟机（VM）和容器会频繁回收。组织很难管理和跟踪运行在短暂资源上的应用服务。服务网格通过充当所有注册服务的中央注册表解决了这个问题。当服务实例（例如VM、容器、无服务器函数）启动和关闭时，网格能够了解它们的状态和可用性。服务发现能力是服务网格解决其他问题的基础。

由于服务网格了解服务及其实例的状态，网格可以实施更智能和动态的网络路由。许多服务网格提供L7流量管理功能。因此，运营商和开发人员可以创建强大的规则来按需引导网络流量，例如负载均衡、流量分割、动态故障转移和自定义解析器。服务网格的动态网络行为允许应用所有者在不更改应用的情况下提高应用的弹性和可用性。

随着越来越多的应用部署在不同的云提供商（多云）和私有数据中心，实施动态网络行为至关重要。组织可能需要将网络流量路由到其他基础设施环境。确保流量安全是所有组织的首要任务。服务网格提供了在所有服务之间强制实施网络流量加密（mTLS）和身份验证的能力。服务网格可以为每个服务及其实例自动生成SSL证书。该证书与网格内部的其他服务进行身份验证，并使用SSL加密TCP/UDP/gRPC连接。

制定精细的策略来规定哪些服务允许相互通信是服务网格的另一个好处。传统上，服务通过防火墙规则允许与其他服务通信。传统的防火墙（基于IP）模型很难在生命周期短且IP地址频繁更换的动态基础设施资源上实施。因此，网络管理员必须打开网络范围以允许服务之间的网络流量，而不区分生成网络流量的服务。然而，服务网格允许运营商和开发人员从基于IP的模型转向更专注于服务到服务的权限。运营商定义策略，仅允许服务A与服务B通信。否则，默认操作是拒绝流量。这种从基于IP地址的安全模型向服务焦点模型的转变，减少了保护网络流量的开销，并允许组织在不因复杂性而牺牲安全性的情况下利用多云环境。

Consul KV 存储

Consul KV 是 Consul 的一个核心功能，并与 Consul agent 一起安装。一旦与 agent 一起安装，它将具有合理的默认设置。Consul KV 允许用户存储索引对象，但其主要用途是存储配置参数和元数据。请注意，它是一个简单的键值存储，并不打算成为一个功能齐全的数据存储（如 DynamoDB），但与其有一些相似之处。

Consul KV 数据存储位于服务器上，但可以通过任何 agent（客户端或服务器）进行访问。原生集成的 RPC 功能允许客户端将请求转发到服务器，包括键值读取和写入。Consul 的核心设计部分允许数据自动在所有服务器之间复制。当有法定数量（quorum）的服务器时，如果发生故障，可以降低数据丢失的风险。

访问 KV 存储

可以通过 consul kv CLI 子命令、HTTP API 和 Consul UI 访问 KV 存储。要限制访问，请启用并配置 ACL。一旦 ACL 系统启动，用户和服务将需要一个具有 KV 权限的有效 token 才能访问数据存储，包括读取操作。我们建议创建一个权限有限的 token，例如，您可以创建一个对某个键具有写入权限的 token，以便开发人员更新与其应用程序相关的值。

数据存储本身位于 Consul 服务器的数据目录中。为了确保在完全故障的情况下不会丢失数据，请使用 consul snapshot 功能来备份数据。

使用 Consul KV

对象对 Consul 来说是透明的，这意味着在键/值条目中存储的对象类型没有限制。对象的主要限制是大小 - 最大为 512 KB。由于对象的最大大小和主要用例，您不需要额外的存储；一般的大小推荐通常是足够的。

键与对象一样不受类型限制，可以包含任何字符。但是，我们建议使用 URL 安全字符 - [a-zA-Z0-9-._~] ，但 / 除外，它可用于帮助组织数据。请注意， / 将像任何其他字符一样对待，并且不固定到文件系统。这意味着，在键中包含 / 不会将其固定为目录结构。此模型类似于 Amazon S3 存储桶。但是， / 对于组织数据以及在数据存储中递归搜索时仍然有用。我们还建议您避免使用 * 、 ? 、 ' 和 % ，因为它们可能会在使用 API 时导致问题以及 shell 脚本中。

使用 Sentinel 为 Consul KV 应用策略

此功能需要 HashiCorp 云平台 (HCP) 或自我管理的 Consul Enterprise。

您还可以使用 Sentinel 作为策略即代码框架来定义高级键值存储访问控制策略。 Sentinel 策略将 Consul 中的 ACL 系统扩展到静态 “读”、“写” 和 “拒绝” 策略之外，以支持完整的条件逻辑以及与外部系统的集成。请参阅 Sentinel 文档以了解高级 Sentinel 概念。

扩展 Consul KV

模板

如果您计划使用 Consul KV 作为配置管理过程的一部分，请查看 Consul 模板教程，了解如何根据 KV 中的值更新来更新配置。 Consul 模板基于 Go 模板，允许根据 Consul 键的值更改启动一系列脚本操作。

watches

Consul KV 还可以通过使用 watches 进行扩展。Watches 是一种监控数据更新的方式。当检测到更新时，会调用一个外部处理程序。要将 watches 与 KV 存储一起使用，应使用键 watch 类型。

Consul Sessions

Consul 会话可以与 Consul KV 一起用于构建分布式锁。会话充当节点、健康检查和键/值数据之间的绑定层。KV API 支持获取和释放操作。获取操作类似于检查并设置（Check-And-Set）操作。成功时，会有一个键更新并增加 LockIndex，并且会话值更新以反映持有锁的会话。请查看会话文档以了解更多关于集成的信息。

请查看以下教程，了解如何使用 Consul 会话进行应用程序领导选举和构建分布式信号量。

Vault

如果您计划将 Consul KV 用作 Vault 的后端，请查看此教程。