Consul 多数据中心 Java 客户端连接失败的典型表现
Java 应用启动时抛出 com.ecwid.consul.transport.TransportException，或日志里反复出现 Failed to retrieve catalog services from Consul，基本是跨数据中心通信没通——不是服务没启，而是客户端默认只连本地 DC，压根没发请求过去。
- Consul Java SDK（如
consul-api）默认不启用多 DC 支持，ConsulClient初始化时必须显式指定目标数据中心名，否则一律走本地dc1 - 跨 DC 请求依赖 Consul Server 间的 WAN gossip 和 RPC 转发，但 Java 客户端本身不参与 gossip，它只是把请求发给「你配的那个 Consul agent 或 server」，由后者决定是否转发到远端 DC
- 常见误操作：在
ConsulClient("10.0.1.100:8500")后调用getCatalogServices()，却没意识到这个 endpoint 所在节点所属的 DC 才是实际生效的 DC，不是你代码里写的 IP 决定的
Java 中正确设置目标数据中心的两种方式
关键不是改 URL，而是告诉 client “我要查哪个 DC 的数据”，这通过 QueryParams 或构造参数控制，且不同操作粒度不同。
- 全局指定：初始化
ConsulClient时传入ConsulRawClient+ 自定义HttpClient不够，必须用带datacenter参数的构造函数：new ConsulClient("10.0.1.100", 8500, "dc2") - 单次查询指定：更灵活，适合混合读取多 DC 场景，比如查本 DC 的配置、远 DC 的公共服务：
client.getCatalogServices(QueryParams.Builder().datacenter("dc2").build()) - 注意：Spring Cloud Consul 2.x+ 默认禁用跨 DC 查询，需手动开启
spring.cloud.consul.config.format=KEY_VALUE并配spring.cloud.consul.config.datacenters.dc2=consul-server-dc2:8500，否则@Value注入永远只读本地 DC
Consul Agent 配置对 Java 客户端行为的隐性影响
Java 应用连的是 local agent 还是 remote server，直接决定它能否访问其他 DC 的数据——agent 本身不跨 DC 转发，server 才能。
php配置文件php.ini的中文注释版
下载
php配置文件php.ini的中文注释版是一本由多位作者编著的有关PHP内部实现的开源书籍。从环境准备到代码实现，从实现过程到细节延展，从变量、函数、对象到内存、Zend虚拟机…… 如此种种，道尽PHP之风流。
- 如果 Java 连的是 client-mode agent（即
client_addr = 0.0.0.0且未启用enable_script_checks = true等 server 特性），那它只能访问本 DC 数据，即使你代码里写了datacenter="dc2"，agent 也会静默忽略并返回空结果 - 必须确保 Java 连接的 endpoint 是一个 server-mode 节点（
server = true），或者该 agent 配置了retry_join_wan = ["10.0.2.50"]并成功加入 WAN cluster，否则跨 DC 查询会超时或 404 - 验证方法：curl
http://consul-server-dc1:8500/v1/status/peers看是否列出 dc2 的 server；再 curlhttp://consul-server-dc1:8500/v1/catalog/services?dc=dc2测试 server 层面是否可达
Java 服务注册到远端 DC 的陷阱
注册 ≠ 发现。Java 应用调用 client.agentServiceRegister(...) 时，服务只会被注册到 client 所连节点所在的 DC，不会自动同步到其他 DC。
立即学习“Java免费学习笔记（深入）”；
- Consul 没有“全局服务注册”机制，多 DC 下必须为每个 DC 单独注册，通常做法是在每个 DC 部署一套 Java 应用实例，并分别指向对应 DC 的 Consul server
- 若强行让 dc1 的应用注册到 dc2，需手动指定 dc2 的 server 地址初始化
ConsulClient，但此时健康检查会失败——因为 check 脚本或 HTTP check 的地址（如http://localhost:8080/health）在 dc2 网络里根本不可达 - 真正可行的跨 DC 服务暴露方式是：用 Consul 的
prepared_query+failover，或在 dc2 部署轻量级 proxy（如 fabio）反向代理到 dc1 的真实服务，Java 客户端只查本地 DC 的 proxy 服务
