什么是 Consul？Consul 的核心架构和主要功能有哪些？

Consul 是 HashiCorp 公司开源的分布式服务发现和配置管理系统，在微服务架构中承担服务注册与发现、健康检查、键值存储、安全通信等核心职责。与 Eureka、Zookeeper 等同类工具相比，Consul 原生支持多数据中心、提供 DNS+HTTP 双协议接口，并内置 ACL 安全机制，是生产级微服务基础设施的常见选择。

Consul 的核心架构

Consul 采用 Server-Client 分层架构，每个节点运行一个 Agent 进程：

组件	职责	说明
Server Agent	参与共识、存储数据	通常 3-5 个节点组成 Raft 集群，推荐奇数节点
Client Agent	转发请求、执行健康检查	轻量级，几乎不占用资源，运行在每个服务节点上
Datacenter	逻辑隔离单元	同一 Datacenter 内低延迟通信，跨 DC 通过 WAN Gossip 连接

架构要点：

• Server 节点通过 Raft 协议选举 Leader，所有写操作由 Leader 处理并同步到 Follower
• Client 节点不参与共识，仅向 Server 转发 RPC 请求，同时负责本地健康检查
• 每个数据中心推荐 3 或 5 个 Server——2 个无法容错，7 个则共识延迟过高

shell
                    ┌─────────────────────────────┐
                    │       Datacenter 1          │
                    │                             │
   ┌──────────┐    │  ┌───────┐ ┌───────┐ ┌───────┐
   │  Client  │────┼──│Server1│ │Server2│ │Server3│
   └──────────┘    │  │Leader │ │Follow │ │Follow │
   ┌──────────┐    │  └───────┘ └───────┘ └───────┘
   │  Client  │────┼──│  Raft Consensus + WAL      │
   └──────────┘    │  └────────────────────────────┘
                    └──────────────┬──────────────┘
                                   │ WAN Gossip
                    ┌──────────────┴──────────────┐
                    │       Datacenter 2          │
                    │  ┌───────┐ ┌───────┐ ┌───────┐
                    │  │Server4│ │Server5│ │Server6│
                    │  └───────┘ └───────┘ └───────┘
                    └─────────────────────────────┘

Raft 共识协议

Consul 使用 Raft 协议保证 Server 集群的数据强一致性，这是面试高频考点：

Leader 选举流程：

1. 节点启动时进入 Follower 状态，等待 Leader 的心跳
2. 若在 election timeout（默认 150ms-300ms 随机）内未收到心跳，转为 Candidate
3. Candidate 自增任期号（term），向其他 Server 请求投票
4. 获得多数票（N/2 + 1）的 Candidate 成为 Leader
5. Leader 开始周期性发送心跳维持权威

日志复制流程：

1. 客户端写请求 → Leader 将操作写入本地日志（WAL）
2. Leader 将日志条目并行发送给所有 Follower
3. 多数 Follower 确认后，Leader 提交该日志条目并应用到状态机
4. 通知客户端写入成功

关键特性：

• 强一致性读：通过 require_consistent 参数，读请求也经过 Raft 共识
• 默认一致性读：Leader 直接返回数据，性能更高但可能读到旧数据（stale read）
• CAP 取舍：网络分区时 Raft 保证一致性（CP），牺牲可用性

Gossip 协议

Consul 在两个层面使用 Gossip 协议（基于 SWIM 算法）：

层面	协议名	用途
LAN Gossip	Serf LAN	同一数据中心内节点发现、故障检测、事件广播
WAN Gossip	Serf WAN	跨数据中心的 Server 互联、全局服务发现

Gossip 的核心优势：

• 去中心化：无需中心节点，任意节点故障不影响集群
• 最终一致性：信息以 O(log N) 速度传播到全网
• 故障检测：比传统心跳更高效，可扩展到数千节点

服务发现机制

Consul 提供两种服务发现接口：

1. DNS 接口

bash
# 查询服务所有实例
dig @consul-server -p 8600 redis.service.consul

# 查询健康实例（过滤掉不健康的）
dig @consul-server -p 8600 healthy.redis.service.consul

# 指定数据中心查询
dig @consul-server -p 8600 redis.service.dc2.consul

2. HTTP API

bash
# 查询服务实例
curl http://consul-server:8500/v1/catalog/service/redis

# 仅查询健康实例
curl http://consul-server:8500/v1/health/service/redis?passing

服务注册方式：

json
{
  "service": {
    "name": "redis",
    "tags": ["primary", "v7"],
    "port": 6379,
    "check": {
      "http": "http://localhost:6379/health",
      "interval": "10s",
      "timeout": "1s"
    }
  }
}

健康检查

Consul 的健康检查是服务发现的核心保障——只有健康检查通过的服务实例才会被 DNS 和 API 返回：

检查类型	配置方式	适用场景
HTTP	"http": "http://localhost/health"	Web 服务健康端点
TCP	"tcp": "localhost:6379"	数据库端口连通性
TTL	"ttl": "30s"	应用主动汇报心跳
gRPC	"grpc": "localhost:50051"	gRPC 服务健康检查
Script	"args": ["/usr/local/bin/check.sh"]	自定义脚本检查

健康状态流转：

shell
passing → warning → critical → 自动从服务发现中剔除

面试常问：健康检查失败后服务多久被剔除？ 答：取决于 deregister_critical_service_after 配置，默认不会自动注销，需显式配置。

键值存储（KV Store）

Consul KV 提供分布式配置管理能力：

bash
# 写入配置
curl -X PUT http://consul-server:8500/v1/kv/config/database/url \
  -d 'mysql://db:3306/myapp'

# 读取配置
curl http://consul-server:8500/v1/kv/config/database/url

# 监听配置变更（长轮询）
curl "http://consul-server:8500/v1/kv/config/database/url?wait=30s&index=42"

典型应用场景：

• 动态配置中心：应用启动时从 KV 读取配置，变更时热更新
• 分布式锁：基于 session + KV 实现互斥
• Leader 选举：多个实例竞争同一 KV key 的 session
• 特性开关（Feature Flag）：通过 KV 控制功能灰度

多数据中心支持

Consul 原生支持多数据中心，无需额外中间件：

1. 每个 Datacenter 独立运行 Raft 集群，管理本地状态
2. Server 节点通过 WAN Gossip 自动发现其他数据中心的 Server
3. 客户端跨 DC 查询时，本地 Server 代理转发到目标 DC 的 Server

跨数据中心服务发现：

bash
# 查询 dc2 中的 redis 服务
dig @consul-server -p 8600 redis.service.dc2.consul

# HTTP API 跨 DC 查询
curl "http://consul-server:8500/v1/catalog/service/redis?dc=dc2"

面试重点： 跨 DC 查询是最终一致性，不经过 Raft 共识，数据可能存在短暂延迟。

安全特性

安全机制	作用	配置方式
TLS 加密	节点间 RPC 通信加密	verify_incoming、verify_outgoing
Gossip 加密	LAN/WAN Gossip 通信加密	encrypt、verify_incoming
ACL 访问控制	细粒度权限管理	Token + Policy 规则
Service Mesh (Connect)	服务间 mTLS 通信	Sidecar Proxy 模式

ACL 策略示例：

hcl
# 只允许读取 redis 服务
acl_policy "redis-read" {
  rules = <<-EOF
    service "redis" {
      policy = "read"
    }
  EOF
}

Consul vs Eureka vs Zookeeper

面试常考对比题：

特性	Consul	Eureka	Zookeeper
一致性协议	Raft (CP)	无 (AP)	ZAB (CP)
健康检查	多种方式	客户端心跳	长连接/会话
多数据中心	原生支持	不支持	需要额外方案
服务发现	DNS + HTTP	HTTP	需要客户端封装
KV 存储	内置	无	支持
Spring Cloud	支持	Netflix 原生	需要适配
运维复杂度	中等	低	高

选型建议：

• 需要 多数据中心 + 强一致性 → Consul
• Spring Cloud Netflix 体系 + 高可用优先 → Eureka
• 已有 Zookeeper 基础设施 + 需要分布式协调 → Zookeeper
• 新项目推荐 Consul，功能最全面，社区活跃

面试高频问题

Q1：Consul Server 数量为什么推荐奇数？

Raft 共识需要多数派（N/2 + 1）确认。3 节点容忍 1 故障，4 节点也只能容忍 1 故障，因此 4 节点相比 3 节点没有增加容错能力，反而增加共识延迟。5 节点容忍 2 故障，是下一个合理选择。

Q2：Consul 如何防止脑裂？

Raft 协议要求多数派确认，网络分区时只有拥有多数派的分区能选举 Leader，少数派分区无法提交写入，从而避免脑裂。

Q3：Consul 的 Watch 机制是什么？

Watch 是 Consul 的长轮询机制，客户端指定一个 key/index，当数据变更时服务端立即返回新数据，否则阻塞等待直到超时。适合实现配置热更新。

Q4：Consul Connect 的工作原理？

Connect 是 Consul 的 Service Mesh 功能。每个服务实例旁部署 Sidecar Proxy（支持内置 L4 代理或 Envoy），Proxy 负责建立 mTLS 连接、执行访问控制，服务间通信通过 Proxy 代理，实现零信任安全架构。