How Dubbo 3.0 Cuts Resource Use with Application‑Level Service Discovery

Background

With the rise of cloud‑native architectures, Dubbo 3.0 aims to fully embrace cloud‑native principles. To achieve better compatibility, the framework evolves from an interface‑level service discovery model to an application‑level one, which reduces memory consumption and improves resource utilization.

Single‑machine resident memory drops by 75%.

Supports clusters with millions of instances.

Overall registry data volume decreases by more than 90%.

What is Application‑Level Service Discovery?

Previously, each interface of a service was registered separately, causing redundant data. The new model registers only one entry per application instance, solving three main problems:

Aligns with mainstream microservice models such as Spring Cloud.

Supports Kubernetes‑native services, which operate at the application‑instance level.

Reduces storage pressure on the registry and lessens address‑change push traffic.

Data Comparison

Assume an application dubbo-application runs three instances (instance1‑3) and exposes three interfaces (sayHello, echo, getVersion). Under the old interface‑level discovery the registry stores:

"sayHello": [
  {"application":"dubbo-application","name":"instance1","ip":"127.0.0.1","metadata":{"timeout":1000}},
  {"application":"dubbo-application","name":"instance2","ip":"127.0.0.2","metadata":{"timeout":2000}},
  {"application":"dubbo-application","name":"instance3","ip":"127.0.0.3","metadata":{"timeout":3000}}
],
"echo": [...],
"getVersion": [...]

With application‑level discovery the registry stores a single entry:

"dubbo-application": [
  {"name":"instance1","ip":"127.0.0.1","metadata":{"timeout":1000}},
  {"name":"instance2","ip":"127.0.0.2","metadata":{"timeout":2000}},
  {"name":"instance3","ip":"127.0.0.3","metadata":{"timeout":3000}}
]

Full Server‑Exposure Process in Dubbo 3.0

The core entry point is DubboBootstrap#doStart. The simplified flow is:

private void doStart() {
    // 1. Export Dubbo services
    exportServices();
    // If consumer instance needs registration or services have been exported
    if (isRegisterConsumerInstance() || hasExportedServices()) {
        // 2. Export metadata service
        exportMetadataService();
        // 3. Periodically update and report metadata
        registerServiceInstance();
        ....
    }
    ......
}

When using Zookeeper as the registry and exposing a service via the Triple protocol, the sequence diagram (see image) shows four major parts:

Expose injvm protocol services.

Register service-discovery-registry protocol.

Expose Triple protocol services and register the registry protocol.

Expose the MetadataService.

1. Expose injvm Protocol Services

Injvm services run locally, allowing a Service and its Reference to coexist in the same application without network overhead. The core code is identical to the previous version, so it is omitted here.

2. Register service-discovery-registry Protocol

This step stores service metadata in memory (via InMemoryWritableMetadataService) and optionally in a remote metadata center.

private URL exportRemote(URL url, List<URL> registryURLs) {
    if (CollectionUtils.isNotEmpty(registryURLs)) {
        for (URL registryURL : registryURLs) {
            if (SERVICE_REGISTRY_PROTOCOL.equals(registryURL.getProtocol())) {
                url = url.addParameterIfAbsent(SERVICE_NAME_MAPPING_KEY, "true");
            }
            // Reuse service export flow for service‑discovery‑registry
            doExportUrl(registryURL.putAttribute(EXPORT_KEY, url), true);
        }
    }
    return url;
}

The export process wraps the Invoker with DelegateProviderMetaDataInvoker and then calls the underlying protocol:

private void doExportUrl(URL url, boolean withMetaData) {
    Invoker<?> invoker = PROXY_FACTORY.getInvoker(ref, (Class) interfaceClass, url);
    if (withMetaData) {
        invoker = new DelegateProviderMetaDataInvoker(invoker, this);
    }
    Exporter<?> exporter = PROTOCOL.export(invoker);
    exporters.add(exporter);
}

3. Expose Triple Protocol Services and Register registry Protocol

The Triple protocol export reuses the same flow as injvm. After the local export, the registry protocol registers the application instance in Zookeeper.

public <T> Exporter<T> export(final Invoker<T> originInvoker) throws RpcException {
    URL registryUrl = getRegistryUrl(originInvoker);
    URL providerUrl = getProviderUrl(originInvoker);
    // Export Triple service locally
    final ExporterChangeableWrapper<T> exporter = doLocalExport(originInvoker, providerUrl);
    // Create Zookeeper registry object
    final Registry registry = getRegistry(registryUrl);
    final URL registeredProviderUrl = getUrlToRegistry(providerUrl, registryUrl);
    if (providerUrl.getParameter(REGISTER_KEY, true)) {
        register(registry, registeredProviderUrl); // triggers onRegister event
    }
    notifyExport(exporter); // triggers onExport event
    return new DestroyableExporter<>(exporter);
}

4. Expose MetadataService

MetadataService provides an API for consumers to fetch service metadata. Its exposure reuses the Triple protocol flow.

private void exportMetadataService() {
    metadataServiceExporter.export();
}

The exporter creates a ServiceConfig<MetadataService> with a dummy registry ( N/A) and the Triple protocol, then calls serviceConfig.export().

Metadata Publishing and ServiceInstance Registration

Metadata publishing occurs in two places: MetadataUtils.publishServiceDefinition(url) stores interface data in the in‑memory metadata service and optionally in a remote store. ServiceDiscoveryRegistry#register registers the ServiceInstance (application name, host, port, metadata) to the service‑discovery registry.

public final void register(URL url) {
    if (!shouldRegister(url)) return;
    doRegister(url);
}

The remote registration ultimately writes data to Zookeeper paths such as /dubbo/metadata/xxxService/provider/${application-name} and creates mapping nodes under /dubbo/mapping/xxxService.

Summary

Dubbo 3.0’s application‑level service discovery introduces a more efficient registration model, cutting memory usage by up to 75% and reducing registry data volume by over 90%. Although the implementation is more complex, the framework reuses much of the existing 2.7.x flow to ensure a smooth migration for users. Ongoing community work aims to further optimize core processes and support multi‑instance deployments.