Consul 架构原理

理解 Consul 前先分清三类角色与两套协议：agent 分 dev/client/server 三种运行形态，节点之间用 Serf（gossip）做成员管理与故障发现，服务数据则由 server 组成的 Raft 集群保证强一致。

三种 agent 角色

所有 Consul 进程都叫 agent，启动参数不同角色就不同：

角色	职责	适用场景
dev	单机开发模式，功能全开，数据只在内存	本地学习、调试
client	转发注册/查询请求、跑健康检查，不存数据	与应用部署在同一台机器
server	参与 Raft 选举、存储服务目录与 KV	独立节点，集群核心

服务注册信息流向

服务注册总是先发给本机 agent（client 或 server），再由它转发给 server 集群存储：

业务应用 → 本机 agent（client/server）→ server 集群（Raft 同步给全体 server）
查询方 → 本机 agent → 就近 server 读取目录 → 返回健康实例列表

client 是业务的"代言人"，它不存数据、只做转发与检查，因此可以大量部署。

gossip 两层协议

Consul 用 Serf 实现的 gossip（谣言传播）协议管理成员，分 LAN 与 WAN 两层：

协议层	端口	作用
LAN gossip	8301	同数据中心内成员发现、故障检测
WAN gossip	8302	server 之间跨数据中心互联，发现其他 DC

节点会周期性交换成员信息，某节点挂掉后几秒内即被整个集群感知。

Raft 一致性

server 集群用 Raft 算法保证数据一致：唯一 leader 接收写入并广播日志，follower 复制确认，多数派（quorum）确认后才算提交：

概念	含义
leader	唯一处理写请求的 server，由选举产生
follower	复制 leader 日志、参与选举的 server
quorum	多数派，3 台集群需 2 台确认，5 台需 3 台

因为要凑够多数，server 数量必须取奇数，3 台起是生产最低要求，容忍 1 台故障。

小结

Consul 架构一句话：client 贴近业务收转发请求，server 用 Raft 存一致数据，Serf gossip 管成员与故障。抓住这条主线，后面的集群搭建、多数据中心与故障排错就有了分析框架。