Understanding Dubbo 3.x’s Move to Application-Level Service Registration

The author revisits a previous deep‑dive into Dubbo RPC and fills a "38‑likes" gap by explaining why Dubbo switched to application‑level service registration after version 3.x and how it is implemented.

Simple Demo

A minimal Dubbo demo is presented, consisting of a provider project that implements DemoService annotated with @DubboService , and a consumer project that uses @DubboReference in a unit test. The provider and consumer configuration files are shown in the images below.

Application‑Level vs Interface‑Level Service Registration

1. Application‑Level Service Registration

In this model a service instance registers itself once as a whole, without exposing individual interface information to the registry.

A service, regardless of how many interfaces it provides, is registered as a single entity in the service registry.

2. Interface‑Level Service Registration

Each interface is treated as an independent service and is registered separately. Dubbo 2.x used this model, so a service with 100 interfaces would generate 100 registration entries.

Registration and discovery are performed per interface; each interface is a distinct service.

Why Dubbo 3.x Adopted Application‑Level Registration

Two main reasons are given:

Reduced pressure on the registry : Interface‑level registration multiplies registration, change‑notification, and storage load. A single registration per service instance dramatically lowers these costs.

Alignment with modern cloud‑native ecosystems : Spring Cloud and Kubernetes use application‑level registration, so adopting the same model eases integration and supports microservice‑native architectures.

The pressure of interface‑level registration far exceeds that of application‑level registration.

Implementation of Application‑Level Registration in Dubbo 3.x

Dubbo still invokes services via interfaces, but the registry now only holds application‑level data. Consumers must discover the service name first, then retrieve interface details.

1. Determining the Service Providing an Interface

Consumers can obtain the service name by:

Manually configuring it via @DubboReference#providedBy , consumer configuration files, or registry configuration entries.

Automatic detection: providers store a mapping of interface fully‑qualified names to service names in a metadata center . Consumers query this center to resolve the service name.

The metadata center can be Redis, Nacos, or Zookeeper. When Nacos or Zookeeper is used as the registry, they are also used as the metadata center by default.

2. Obtaining Interface Detail Data

After the service name is known, the consumer needs the interface’s IP, port, and protocol. Dubbo provides two ways:

Local cache (default) : Providers expose a MetadataService RPC endpoint and store its protocol/port in the registry. Consumers fetch details from the provider’s local cache.

Remote metadata center : If dubbo.metadata.storage-type=remote , the provider pushes full interface metadata to the metadata center, and consumers retrieve it from there.

The MetadataService is automatically exposed on port 20880 using the Dubbo protocol. The registry entry for a service includes the address of this metadata service, enabling consumers to query interface details.

Configuration Example

Manual configuration example using @DubboReference#providedBy :

@DubboReference(providedBy = "demo-service")

Automatic detection relies on the provider storing mappings such as:

interfaceName -> serviceName

and the consumer querying the metadata center to resolve the service name.

Metadata Storage Types

The property dubbo.metadata.storage-type controls where interface details are fetched from. The default local uses the provider’s cache; setting it to remote switches to the metadata center.

Summary

Dubbo 3.x switched to application‑level service registration to reduce registry load and to align with cloud‑native platforms like Spring Cloud and Kubernetes. Consumers locate the target service either via manual configuration or automatic metadata‑center lookup, then retrieve interface details from either the provider’s local cache or the remote metadata center, enabling seamless RPC calls.