How Dubbo Enables Kubernetes‑Native Service Discovery with Metadata and Revision

Kubernetes Basics

A Pod is the smallest deployable unit in Kubernetes and may contain one or more containers. A Service abstracts a set of Pods that share the same function; the Service selects Pods via label selectors. Each Service has Endpoints that map to the actual Pods.

Dubbo Application‑Level Service Discovery

Dubbo registers services at the interface granularity, which differs from the service‑level registration used by Spring Cloud and native Kubernetes Service registration. Since Dubbo 2.7.5 a metadata service enables the transition to interface‑level registration, and the model has been further optimized in Dubbo 3.0.

Metadata Service

The metadata service stores the mapping between service instances and interfaces, reducing the amount of data kept in the registry and lowering network traffic during updates. Providers write instance information and service URLs to the metadata service; consumers first obtain instance data from the registry and then query the metadata service for detailed URLs.

Revision Mechanism

Revision is a hash (e.g., MD5) of an instance’s metadata. Instances that share the same Revision have identical metadata, so a consumer can randomly select one instance per Revision group to fetch the metadata, dramatically reducing traffic.

Consumer obtains the list of service instances from the registry (including a Revision field).

Consumer groups instances by Revision.

From each group, the consumer selects one instance to query the metadata service.

Consumer fetches service URLs via RPC or a configuration center.

Consumer builds interface‑level service information from the retrieved metadata.

Integration Approaches with Kubernetes

Kubernetes API Client

Dubbo can communicate with the Kubernetes control plane through the HTTP API exposed by the API Server.

Provider Details (API Client)

When a Dubbo provider starts or updates its interfaces, it writes a Revision annotation onto the corresponding Service object. The Service name matches the Dubbo service annotation, and Labels act as selectors for the Service.

Consumer Details (API Client)

Consumers retrieve the Service object via the API, read the associated Pod annotations to complete the ServiceInstance data, and then follow the normal Dubbo service‑introspection flow.

Pros and Cons (API Client)

Direct interaction with the Kubernetes API can introduce security risks if credentials are mis‑configured.

Frequent updates may increase load on the API Server.

The approach removes the need for an external registry, simplifying management in a pure Kubernetes environment.

DNS Client

Kubernetes DNS allows Dubbo to discover services using standard DNS queries (A/AAAA and SRV records). The metadata service is adapted to operate without writing Revision information to the registry; only the Dubbo instance IP is required.

Decentralized Metadata Service

The revised metadata service provides two RPCs: (1) retrieve URL information for a given Revision, and (2) retrieve the Revision value itself. Consumers contact each instance’s metadata endpoint, obtain its Revision, and then randomly select one instance with the same Revision to fetch the full metadata.

Provider Details (DNS)

Providers cache metadata locally and expose a metadata service endpoint. The endpoint port is configurable via metadataServicePort and may differ from the business service port, enabling DNS usage without SRV records.

Consumer Details (DNS)

Consumers perform DNS A/AAAA queries to obtain instance IPs, then call each instance’s metadata service to get its Revision. A parameter‑callback mechanism pushes updates from providers to consumers; future work will use Dubbo 3.0’s Triple protocol for streaming pushes.

Pros and Cons (DNS)

Avoids direct Kubernetes API interaction, reducing security exposure.

DNS lacks a watch/notification mechanism, so consumers must poll, adding network load.

Any DNS that can resolve Dubbo pod IPs can be used, making the solution portable beyond Kubernetes DNS.

Future Directions

Future work includes integrating with Service Mesh control planes via the xDS protocol and aligning the upcoming Dubbo 3.0 release (both Java and Dubbo‑go) with the Kubernetes native service discovery model.

Reference: Dubbo Application‑Level Service Discovery article – https://mp.weixin.qq.com/s?__biz=MzU4NzU0MDIzOQ==∣=2247489653&idx=1&sn=445692c491f68aed3f649730d3d9ba96&scene=21#wechat_redirect