乐闻世界logo
5月30日 22:56

Consul 多数据中心部署如何配置？哪些坑最容易踩？

Consul 的多数据中心不是把一个 Raft 集群横跨几个机房，而是每个数据中心有自己的 Consul server 集群，再通过 WAN Gossip 和远程 RPC 互相发现。这样做的好处是本地故障不会直接拖垮其他数据中心，服务查询也优先走本地。代价是 KV、ACL、服务目录并不是天然全局一致，跨数据中心访问要明确指定目标 DC。很多误解都来自这里：Consul 支持联邦，不等于自动同步所有配置和业务流量。

常见生产结构是每个数据中心 3 或 5 个 server，业务机器运行 client agent。server 参与 Raft，client 负责本机服务注册、健康检查和转发查询。跨数据中心只让 server 加入 WAN 池，普通 client 不需要加入。

dc1 的 server 配置可以这样写：

hcl
datacenter = "dc1"
node_name = "consul-dc1-s1"
server = true
bootstrap_expect = 3
data_dir = "/opt/consul"
bind_addr = "10.0.0.11"
client_addr = "0.0.0.0"
encrypt = "<same-gossip-key>"
retry_join = ["10.0.0.12", "10.0.0.13"]
retry_join_wan = ["10.1.0.11", "10.1.0.12", "10.1.0.13"]

启动后用这些命令确认联邦是否正常：

bash
consul members
consul members -wan
consul catalog datacenters
dig @127.0.0.1 -p 8600 web.service.dc2.consul

服务仍然在本地注册，查询远程服务时通过 HTTP API 加 ?dc=dc2，或用 DNS 名称 web.service.dc2.consul。是否切到远端要由客户端、网关或服务网格决定，因为跨地域流量涉及延迟、成本、数据一致性和用户归属。

追问

为什么不建议把一个 Consul Raft 集群跨机房部署？

Raft 对延迟和网络抖动很敏感，Leader 选举和日志提交都依赖多数派确认。跨机房部署会让写入变慢，网络闪断时还可能频繁选主。Consul 推荐每个数据中心一套本地 Raft，再用 WAN 联邦做发现。这个取舍牺牲了全局强一致目录，换来本地可用性和清晰故障边界。

多数据中心下服务发现是自动故障转移吗？

不是完全自动，Consul 提供跨数据中心查询能力，但是否切流要看业务策略。比如本地没有健康实例时，网关可以再查 web.service.dc2.consul。踩坑点是把“能查到远端服务”误认为“可以直接切过去”。生产上要提前定义哪些服务可跨 DC，哪些受数据库、会话或合规限制只能本地调用。

KV 和配置会在数据中心之间自动同步吗？

默认不会，每个数据中心的 KV 是独立的。你可以用 consul kv export 和 consul kv import 做迁移，也可以用外部配置平台分发到多个 DC。自动同步听起来方便，但配置错误也会被同步放大。边界是不要把 Consul KV 当成跨地域强一致数据库，它更适合轻量配置和服务治理数据。

WAN Gossip 配置最容易错在哪里？

第一类错误是端口没放通，只开放 8500 通常不够。第二类错误是各数据中心的 Gossip 加密 key 不一致，表现为节点一直加不进 WAN 池。第三类是把 client 节点也加入 WAN，导致成员列表混乱和跨地域流量变多。排查时先看 consul members -wan，再看日志里的 join、decrypt、coordinate 相关错误。

标签：Consul