一、架构与核心机制
- 节点角色 ：每个主机运行一个 Consul Agent ，可为 Client 或 Server 。Server 维护集群状态并参与一致性协议，Client 无状态、负责本地健康检查与请求转发。Server 数量为 3 或 5 并选举 Leader ，通过 Raft 保证写强一致；读可在允许"轻微陈旧"的前提下在普通 Server 完成。集群内节点通过 Gossip（Serf） 维护成员关系，LAN 使用 8301 （TCP/UDP），WAN 使用 8302 （TCP/UDP）。数据读写与复制走 8300 （TCP）。服务注册/发现与 KV 等通过 HTTP API 8500 提供，DNS 查询使用 8600 。支持多 DataCenter，跨 DC 仅由 Server 参与通信。
二、服务注册流程
-
注册入口 ：应用以 HTTP API（8500） 或 配置文件 向本机 Consul Agent 提交服务定义（包含 Service Name/ID、Address、Port、Tags、Meta 与 Check 定义）。也可通过配置文件热加载方式注册。
-
本地处理：Agent 做参数校验、ACL 校验，解析并调度健康检查；健康检查由"服务注册到的那个 Agent"本地执行（非集中式心跳），以减少网络开销与单点压力。
-
一致性写入 ：注册信息经 RPC 转发至 Server，由 Leader 通过 Raft 复制多数派后返回成功，确保注册数据不丢；随后集群通过 **反熵（Anti-Entropy）** 机制修复可能的不一致，使状态最终收敛。
三、健康检查与故障隔离
-
检查类型 ：支持 Script、HTTP/HTTPS、TCP、gRPC、TTL、Docker、OS Service 等；常用参数含 Interval、Timeout、TLSSkipVerify、Method/Header/Body 等，可按需组合。
-
状态机与阈值 ：检查执行结果进入 Passing/Warning/Critical/Maintenance 状态；可配置 success_before_passing、failures_before_warning、failures_before_critical 等阈值以抑制抖动；严重状态可设置 deregister_critical_service_after 自动注销，避免流量打到不可用实例。
-
故障隔离与边界 ：健康检查由"注册所在 Agent"执行，若该 Agent 挂掉，其上的检查不再执行，不会"故障转移"到其他 Agent；因此部署时应尽量保证 Agent 稳定性，或使用多实例/多路注册与负载均衡降低风险。
四、服务发现与查询方式
-
HTTP API ：常用端点包括 /v1/catalog/service/<svc> 、/v1/health/service/<svc>?passing=true （仅健康实例）；支持按 tag 、dc 等过滤，返回节点、服务与检查详情，便于客户端实现自定义负载均衡与重试。
-
DNS 接口 ：域名格式 <service>.service[.tag].<datacenter>.<domain> ；默认 8600 端口。示例：
dig @127.0.0.1 -p 8600 web.service.consul ANY。DNS 查询通常由本机 Consul Agent 代理，Server 查询后返回可用实例；注意 DNS 本身不返回端口，且客户端/系统可能缓存记录，需结合场景设置缓存策略与容错。 -
结果使用 ：消费者拿到实例列表后自行选择（如 随机/轮询/权重 ），并配合 重试/熔断/超时 等策略提升稳定性；对实时性要求高的场景优先用 HTTP API ，对遗留系统或简单场景可用 DNS。
五、数据一致性与可用性设计
-
写路径 ：注册/注销等变更由 Leader 通过 Raft 多数派提交，写成功后集群各 Server 强一致；若注册时 Leader 宕机，写入会失败并触发重新选举，客户端需重试，保证"写不丢"。
-
读路径 ：默认 最终一致性 ；对强一致读可用 ?consistent ；对高吞吐可用 ?stale 读取"可能陈旧"的数据，降低延迟与负载。
-
成员与容错 ：Gossip 提供成员变更、故障检测与广播，收敛快、去中心化；反熵 定期校对 KV/服务/检查状态，弥补网络分区或节点异常导致的不一致，提升整体可用性。