consul如何服务发现

本文目录导读：

1. 核心概念
2. 服务发现的工作流程（核心）
3. 服务发现的两种方式
4. 关键补充

Consul 的服务发现是其最核心的功能之一，Consul 就像一个“电话本”，让一个服务（例如订单服务）能够自动找到另一个服务（例如用户服务）的 IP 地址和端口,而不需要硬编码地址。

下面从核心概念和工作流程两个方面来详细解释。

核心概念

要理解 Consul 的服务发现,需要先了解以下几个关键角色：

1. Agent：运行在每台机器上的 Consul 守护进程（consul agent），它负责在节点上执行健康检查、注册服务、转发请求等，Agent 有两种运行模式：
   • Client 模式：无状态，轻量级，负责转发请求或 RPC 到 Server 节点,不参与持久化数据和选举。
   • Server 模式：有状态，负责持久化集群数据、处理查询、参与 Leader 选举，生产环境推荐 3 或 5 台 Server 节点形成 Raft 集群。
2. Catalog：Consul Server 维护的中央注册表，它存储了所有注册的服务、节点、健康检查状态等信息，可以把它想象成那个“电话本”本身。
3. Service：你想要注册和发现的服务，每个服务都有一个名字（如 user-service）和 ID（推荐与节点关联，如 user-service-node1）。
4. Check：健康检查，Consul 会定期执行检查（如 HTTP 请求、脚本、TTL 等）来判定服务是否健康,只有健康的服务才会被返回给调用方。

服务发现的工作流程（核心）

服务发现主要分为两个阶段：服务注册 和 服务发现。

服务注册（服务启动时）

当一个服务实例（user-service 在 168.1.10:8080 启动）时,它会执行以下步骤：

1. 服务实例向本地 Consul Agent 发起注册请求：服务进程通过 Consul 的 HTTP API 或 SDK（如 consul/api Go 包，consul-py Python 包）向本机的 Consul Client Agent 发送注册信息。
   • 注册信息包括：服务名称（user-service）、服务ID（user-service-1）、IP 地址（168.1.10）、端口（8080）、健康检查定义（如每 10 秒检查一次 /health 端点）。
2. Consul Agent 转发给 Server：Client Agent 将这个注册请求转发给集群中的 Consul Server（通常是 Leader）。
3. Consul Server 写入 Catalog：Server 验证信息后，将服务信息（包括健康检查配置）写入 Catalog 并持久化。
4. Consul Server 返回成功：Server 向 Client Agent 返回成功，Client Agent 再返回给服务进程。

服务发现（服务调用时）

当另一个服务（order-service）需要调用 user-service 时,它的工作流程如下：

1. 调用方向本地 Consul Agent 发起查询：order-service 向本机的 Consul Client Agent 发起一个 DNS 或 HTTP 请求，查询名为 user-service 的服务。
2. Consul Agent 转发或缓存查询：本地 Client Agent 首先检查自己的本地缓存，如果缓存有效且没有过期，直接返回结果，否则，它会将查询请求转发给集群中的 Consul Server。
3. Consul Server 查询 Catalog 并返回：Server 查询 Catalog，找到所有名为 user-service 且健康检查通过的实例列表，它可以根据配置的负载均衡策略（如轮询、随机）返回一个或全部健康的实例 IP 和端口。
4. 本地 Agent 返回结果：本地 Client Agent 将结果（168.1.10:8080）返回给 order-service。
5. order-service 发起真正的调用：order-service 使用获取到的 IP 和端口，通过 HTTP、gRPC 等协议直接调用 user-service，而不需要经过 Consul 代理，这样减少了中间的网络跳转（即零跳转）,性能很好。

服务发现的两种方式

Consul 提供了两种主要的服务发现方式：

DNS 接口（最简单、最常用）

服务可以使用标准的 DNS 查询来发现其他服务，Consul 默认运行一个 DNS 服务器在端口 8600。

• 查询格式：<service_name>.service.consul
  • 查询 user-service：dig user-service.service.consul @127.0.0.1 -p 8600
• 返回结果：DNS 会返回一个或多个健康的服务 IP（A 记录），负载均衡由 DNS 轮询（SRV 记录）处理。
• 优势：几乎所有语言都原生支持 DNS 查询，无需引入额外的 SDK，非常适合于微服务、Kubernetes 等场景。

HTTP API（功能更强大）

服务可以直接调用 Consul 的 RESTful API 来查询服务。

• 查询格式：http://127.0.0.1:8500/v1/catalog/service/<service_name> 或 http://127.0.0.1:8500/v1/health/service/<service_name>（推荐，会同时返回健康状态）。
• 返回结果：返回一个 JSON 数组，包含每个实例的节点、服务名、服务ID、地址、端口、标签（Tags）、健康检查结果等详细信息，调用方可以根据标签（如 version: v1）进行更精细的筛选。
• 优势：可以获取更丰富的元数据（如标签）、筛选健康服务、支持复杂的查询逻辑,适合需要在代码中做二次处理的场景。

关键补充

• 健康检查：这是服务发现正确性的基石，Consul 会定期检查注册的检查项，一个健康检查失败的服务会被自动从 Catalog 中剔除（防止调用到宕机的服务），在服务恢复正常后，健康检查通过,它会再次被自动加入。
• consul-template 或 envconsul：这些工具可以监听 Consul 中服务的变更，并动态生成配置文件（如 Nginx、Haproxy 的 upstream 配置），当服务实例上下线时，配置文件会自动更新，然后执行重载命令，从而实现应用的无感重启，这是传统架构（非 Kubernetes）中使用 Consul 的常见模式。
• 与 Kubernetes 的关系：Kubernetes 自带服务发现（基于 DNS 和 Endpoint），Consul 可以与其集成，为 Kubernetes 内的 Pod 和服务提供更丰富的功能（如跨集群服务发现、更复杂的健康检查、安全连接管理等），但这通常需要额外的部署和配置（如 Consul Connect）。

一句话总结：Consul 通过 Agent 注册服务 -> Server 存储到 Catalog -> 健康检查持续校验 -> 消费者通过 DNS/HTTP 查询 Catalog 这一套流程，实现了动态、可靠的服务发现。

标签： consul 服务发现