Source Code Guide on Apache Dubbo

Architecture

Mon, 01 Jan 0001 00:00:00 +0000

Related samples:

Quick start RPC application: dubbo-go-samples/helloworld
Registry-based microservice application: dubbo-go-samples/registry/nacos
Multi-protocol application: dubbo-go-samples/rpc/multi-protocols

Dubbo Go is organized around a small set of runtime concepts: an application instance, providers, consumers, protocols, registries, metadata, and governance extensions. Current applications are usually built with the API entry points in dubbo.go, server, and client, while configuration-file users still go through config.RootConfig.

Main Runtime Layers

Layer	Important packages	Responsibility
Application instance	`dubbo.go`, `options.go`	Holds application, protocol, registry, metadata, metrics, tracing, router, and shutdown options.
Provider API	`server`	Registers service handlers, builds service options, creates invokers, and exports services.
Consumer API	`client`	Creates clients, dials service references, creates generated or generic services, and invokes remote methods.
Protocol	`protocol/base`, `protocol/triple`, `protocol/dubbo`, `protocol/rest`	Converts invokers into network servers on provider side and network clients on consumer side.
Registry and discovery	`registry`, `registry/protocol`, `registry/servicediscovery`, `registry/directory`	Handles registration, subscription, service discovery, and registry-backed invocation.
Metadata	`metadata`, `metadata/report`, `metadata/mapping`	Stores service definitions, service-to-application mapping, and metadata reports.
Governance extensions	`filter`, `cluster`, `cluster/router`, `cluster/loadbalance`, `common/extension`	Provides filters, routing, load balancing, cluster strategies, and extension registration.

Provider Flow

For the current server API, a provider normally follows this path:

Network Protocol

Mon, 01 Jan 0001 00:00:00 +0000

Related samples:

Triple RPC: dubbo-go-samples/rpc/triple
Multi-protocol service: dubbo-go-samples/rpc/multi-protocols
gRPC interoperability: dubbo-go-samples/rpc/grpc

In current Dubbo Go, the protocol layer is the bridge between the invocation model and the wire protocol. It is responsible for exposing providers as network services and turning consumer-side references into callable remote invokers.

Core Protocol Abstraction

The current protocol interface is defined in protocol/base/base_protocol.go:

type Protocol interface {
	Export(invoker Invoker) Exporter
	Refer(url *common.URL) Invoker
	Destroy()
}

Its responsibilities are straightforward:

Export: expose a provider-side invoker as a network service
Refer: create a consumer-side invoker for a target URL
Destroy: destroy protocol-owned invokers and exporters

There is also an optional capability:

Registry

Mon, 01 Jan 0001 00:00:00 +0000

Related samples:

Nacos registry: dubbo-go-samples/registry/nacos
Zookeeper registry: dubbo-go-samples/registry/zookeeper
Application-level service discovery: dubbo-go-samples/registry/nacos

Core Registry Interface

The main interface is defined in registry/registry.go:

type Registry interface {
	common.Node
	Register(url *common.URL) error
	UnRegister(url *common.URL) error
	Subscribe(*common.URL, NotifyListener) error
	UnSubscribe(*common.URL, NotifyListener) error
	LoadSubscribeInstances(*common.URL, NotifyListener) error
}

Compared with older explanations, LoadSubscribeInstances(...) is now part of the contract. It exists because subscription is asynchronous, and Dubbo Go may need an initial synchronous load before the normal subscription stream catches up.

Core 3.x Capabilities

Mon, 01 Jan 0001 00:00:00 +0000

Related samples:

Triple protocol: dubbo-go-samples/rpc/triple
Application-level discovery with Nacos: dubbo-go-samples/registry/nacos
Service Mesh deployment: dubbo-go-samples/mesh

Dubbo Go 3.x is centered on the Triple protocol, application-level service discovery, metadata-driven service introspection, and SDK-side governance capabilities. These capabilities are no longer just “new features” from the 3.0 release; they are the normal development model for current Dubbo Go applications.

Triple Protocol

Triple is the recommended RPC protocol in Dubbo Go 3.x. Its implementation lives mainly under:

Generic Call

Mon, 01 Jan 0001 00:00:00 +0000

Related samples:

Generic invocation sample: dubbo-go-samples/generic
Triple sample: dubbo-go-samples/rpc/triple

Generic invocation in current Dubbo Go is centered on client.NewGenericService(...) and filter/generic.GenericService. Older examples based on ReferenceConfigBuilder, GenericLoad(), and GetRPCService() describe the legacy compatibility API and are no longer the recommended entry point.

Core API

The main runtime entry is in client/client.go:

genericService, err := cli.NewGenericService(
	"org.apache.dubbo.samples.UserProvider",
	client.WithProtocolTriple(),
	client.WithSerialization(constant.Hessian2Serialization),
	client.WithURL("tri://127.0.0.1:20000"),
)

NewGenericService(...) does three important things by default:

sets NONIDL
enables generic invocation
uses hessian2 serialization

Internally it creates filter/generic.GenericService, then wires it into the normal reference and invocation path.

Generic Invocation Compatibility Notes

Mon, 01 Jan 0001 00:00:00 +0000

Related sample:

Generic invocation sample: dubbo-go-samples/generic

This page is kept mainly for compatibility with older links.

For current Dubbo Go, please read Generic Call. The old examples that use:

config.NewReferenceConfigBuilder()
GenericLoad()
GetRPCService()

describe the legacy configuration-centric API path. The recommended runtime entry today is:

client.NewGenericService(...)
filter/generic.GenericService.Invoke(...)
filter/generic.GenericService.InvokeWithType(...)

If you need a working example, use the dubbo-go-samples/generic sample first.

AOP and Extension Mechanism

Mon, 01 Jan 0001 00:00:00 +0000

Related samples:

Custom filter: dubbo-go-samples/filter/custom
Condition router: dubbo-go-samples/router/condition
Tag router: dubbo-go-samples/router/tag

Dubbo Go uses Go package initialization plus a centralized extension registry to provide most pluggable capabilities. Filters, routers, protocols, registries, load balancers, cluster strategies, tracing exporters, and metadata reporters are all loaded in this way.

Extension Registry

The current implementation lives under common/extension. It no longer relies on ad hoc package-level maps for each type. Instead, each extension category uses the shared generic registry helper:

Application and Interface

Mon, 01 Jan 0001 00:00:00 +0000

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

Application-level configuration is shared by all services and references inside one Dubbo Go process.