Configuration and Discovery

配置与服务发现

首页 · 快速开始 · 问题排查

先决定使用 API 配置、YAML，还是二者组合，然后分别检查注册中心、配置中心和 metadata。三者可能使用相同后端产品，但承担不同职责，不能用“已经连上 Nacos”代替整个调用链的验证。

配置入口

入口	用途	文档
instance／client／server options	在代码中组装应用和调用参数	RPC 入门
本地 YAML	集中描述应用、协议、注册和服务配置	YAML 使用
配置中心	从外部系统管理配置	远程配置
JSON Schema	在编辑器中补全和校验 YAML 结构	Schema 工具

官网 YAML 教程通过 DUBBO_GO_CONFIG_PATH 指定配置文件。排查时检查变量在实际启动进程中是否存在，以及路径相对哪个工作目录解析。例如同一相对路径在项目根目录和 cmd 目录启动时可能指向不同文件。Schema 只能检查其描述的结构，不能证明远端服务可达。YAML 原文

如果代码直接依赖 dubbo.apache.org/dubbo-go/v3/config，升级 v3.3.2 前必须先读 迁移说明，避免把旧配置启动 API 与新 options API 混在一起。

服务发现模型

模式	注册内容	使用提示
interface	可调用的 provider URL	维护接口级发现的项目需核对 consumer／provider 模式
service	应用实例与 metadata	consumer 通过服务到应用的映射、实例与 metadata 还原调用信息
all	两类都注册	用于需要兼容两种 consumer 的迁移阶段

当前手册说明应用级发现是默认模型，且接口级与应用级的注册订阅路径不自动互通。因此迁移或接入已有 Java 应用时，建议明确配置注册模式，而不是只检查注册地址相同。完整模式和 API

Metadata 是发现链路的一部分

local 模式由 provider 保留 metadata 并暴露 metadata service，consumer 根据实例参数拉取；remote 模式通过 metadata report 存取。业务 RPC 能连通，并不能证明 metadata service 也能连通。重点核对服务名、group/version、应用名、revision、metadata 模式和可达地址。provider 发布的 metadata 协议决定 consumer 需要具备的调用能力。完整手册

后端与多注册中心

• Nacos：结合实际 namespace、group、鉴权和部署拓扑配置。
• ZooKeeper：核对连接地址、服务注册内容与订阅模式。
• 多注册中心：确认服务具体绑定了哪个 registry，而不是只确认配置里定义了多个地址。
• Nacos v2 → v3 升级方案讨论：这是兼容性验证与迁移方案，不能据此宣称任意 Nacos 3.x 环境已经获支持；框架 SDK、服务端和 samples 的版本分别验证。

更细的排障顺序见 问题排查。