Repository navigation
Website content en overview mannual golang sdk sourcecode app_and_interface
Go SDK 手册（版本需核对）。原文按来源版本保留；使用前请读 版本与升级。 来源：原文 · 提交
84b35ebdab20· 返回目录
Related samples:
- Hello world application: dubbo-go-samples/helloworld
- YAML-based configuration: dubbo-go-samples/config_yaml
- Registry-based application: dubbo-go-samples/registry/nacos
Current Dubbo Go still separates concepts into application-level configuration and interface-level service references, but the runtime model is broader than the older "application vs interface" explanation. The real source of truth is now the application instance options in options.go and the compatibility configuration model in config/root_config.go.
Application-level configuration is shared by all services and references inside one Dubbo Go process.
In configuration-file mode, that model is represented by config.RootConfig:
ApplicationProtocolsRegistriesConfigCenterMetadataReportProviderConsumerOtelMetricsTracingLoggerShutdownRouterTLSConfig
In API mode, the same shape appears in InstanceOptions from options.go, which is filled by helpers such as:
dubbo.WithProtocol(...)dubbo.WithRegistry(...)dubbo.WithConfigCenter(...)dubbo.WithMetadataReport(...)dubbo.WithMetrics(...)dubbo.WithTracing(...)dubbo.WithShutdown(...)dubbo.WithRouter(...)dubbo.WithRemoteMetadata()dubbo.WithMetadataServiceProtocol(...)
These options describe the runtime environment of the whole application, not one single service.
Interface-level configuration is attached to one exposed service or one referenced remote interface.
On the provider side, the main unit is a registered service:
server.Register(...)server.RegisterService(...)server.ServiceOptions
This layer carries interface name, implementation handler, protocol IDs, registry IDs, serialization, and service metadata.
On the consumer side, the main unit is a reference:
- generated client stubs with
client.DialWithInfo(...) - plain service references with
client.DialWithService(...) - generic references with
client.NewGenericService(...)
This layer carries interface name, URL or registry target, protocol selection, group/version, timeout, and per-reference routing or metadata behavior.
The distinction is especially important in current Dubbo Go because application-level service discovery is now common.
At the application level, Dubbo Go manages:
- application identity
- registry and metadata center integration
- protocol server/client setup
- tracing, metrics, and logging
- router and shutdown policies
At the interface level, Dubbo Go manages:
- which service is exported or referenced
- which method signatures are callable
- per-service protocol and registry binding
- generic or generated invocation behavior
That is why one process can expose multiple services and reference multiple remote services while still sharing the same application identity, registries, protocol servers, and governance settings.
A single Dubbo Go process can contain both provider and consumer roles at the same time. In practice:
- one application instance may host multiple services;
- the same application instance may also dial multiple remote services;
- all of them share the same top-level instance options unless overridden at the service or reference layer.
This is the runtime reason behind the directory and package split you see in server, client, registry, metadata, and protocol.