Consul 是独立运行的服务发现与配置中心，Golang 微服务仅作为客户端连接本地 Agent；多数据中心需通过 WAN 模式（端口 8302）互联，server 节点启用 -server 和 -wan-join，跨 DC 查询由本地 agent 自动路由，Go 客户端不可直连远端 Consul 地址。
Consul 本身不是“部署在微服务里”的组件，而是独立运行的服务发现与配置中心；Golang 微服务只作为客户端连接它。所谓“高可用多数据中心互联”，本质是 Consul 集群自身的 WAN 模式设计问题，不是 Go 代码能决定的。
Consul 多数据中心必须走 WAN 模式，不能靠 client 节点跨 DC 连接
常见误解是让 Golang 服务直连另一个数据中心的 Consul server —— 这不可靠，也不符合 Consul 架构设计。跨 DC 通信必须通过 WAN gossip（端口 8302），且所有 server 节点需启用 -server 模式并显式 -wan-join。
- 每个数据中心至少部署 3 个
server节点（推荐奇数），全部配置server = true和bootstrap_expect = 3 - 跨 DC join 必须用
consul join -wan <target-wan-addr>，目标地址是对方 DC 的-wan-addr（默认ip:8302），不是8500或8300 - 公有云环境务必放开
8302的 TCP+UDP（gossip 协议依赖 UDP 批量同步）；仅开 TCP 会导致 raft peer 列表不全、WAN 状态卡在pending - 验证是否生效：在 DC1 执行
consul operator raft list-peers -wan，输出中必须包含 DC2 的节点 ID 和状态leader或follower
Golang 客户端永远只连本地 Consul Agent，不感知多 DC
你的 Go 服务不应、也不能直接访问远端数据中心的 Consul 地址。所有请求都应发给本机或同机房的 consul agent -client（监听 8500），由该 agent 自动路由到本地 server 或通过 WAN 转发查询。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 初始化
consul.Client时，Address必须设为"http://127.0.0.1:8500"或内网可达的本地 agent 地址，绝不能写成"http://dc2-consul:8500" - 服务注册时，
AgentServiceRegistration中的Address字段填本机 IP（如"10.1.2.3"），不是容器 hostname 或 localhost；否则其他 DC 查不到真实可访问地址 - 跨 DC 服务发现走 DNS：
service-name.service.dc2.consul（需确保本地 agent 开启recursors并配置 upstream DNS），HTTP API 查询则自动由 agent 代理到对应 DC - 不要在 Go 里做多 DC 地址轮询——Consul agent 已内置 DNS 负载均衡和故障转移逻辑
健康检查与服务注册必须适配多 DC 网络延迟
WAN 延迟高、丢包率高，导致默认健康检查参数在跨 DC 场景下极易误判下线。
立即学习“go语言免费学习笔记（深入）”；
- HTTP 健康检查的
Timeout至少设为10s，Interval不低于30s；TCP 检查同理，避免因瞬时抖动触发剔除 - 注册时禁用
DeregisterCriticalServiceAfter（默认1h），改用更宽松策略，例如"90m"，防止网络分区期间服务被误删 - Go 服务启动后，先调用
client.Status().Leader()确认本地 agent 可连 server，再注册；但不要等跨 DC raft 同步完成——那是 Consul 内部事，客户端无需阻塞 - 若某 DC 全部不可达，Consul agent 会自动降级为仅服务本地注册/发现，不影响本 DC 流量；这是设计使然，不必在 Go 里额外加 fallback 逻辑
真正容易被忽略的是：多 DC 并不等于“自动高可用”。如果某个 DC 的 server 全挂，而你又没在其他 DC 部署相同服务实例，那么跨 DC 查询仍会返回空列表——Consul 不会自动把 DC1 的服务“复制”到 DC2，它只做元数据同步。服务本身的多副本部署，才是高可用的物理基础。
