Apache Dubbo: A Java and Go RPC Framework with Built-In Service Governance

Apache Dubbo is a remote procedure call framework with service governance built into its SDK. A service written with Dubbo registers itself in a registry, finds other services through that registry, balances load across their instances, and applies routing rules, all inside the application process. Dubbo is a NON CNCF tool: it is listed in the CNCF Landscape but is not a CNCF project. It was created at Alibaba and open sourced in 2012, donated to the Apache Software Foundation in 2018 and became an Apache top-level project in 2019. Dubbo 3 introduced the Triple protocol, which runs on HTTP/2 and is compatible with gRPC, so Dubbo services can be called by ordinary gRPC and HTTP clients.

CNCF daily · Sprint 3, post 10 of 21 · Remote Procedure Call · NON CNCF

At a glance

Category	Orchestration & Management › Remote Procedure Call
CNCF status	NON CNCF, listed in the CNCF Landscape
Governance	Apache Software Foundation top-level project
Written in	Java (core), with Go, Rust, Node.js and other SDKs
License	Apache 2.0
Wire protocol	Triple (HTTP/2, gRPC-compatible); the older Dubbo protocol is still supported
Registries	Nacos, ZooKeeper, Consul, Kubernetes
Traffic control	Load balancing, cluster fault tolerance, condition and tag routing
Mesh options	Proxyless through xDS (for example Istio), or sidecar

Architecture

Purple is Dubbo, slate the registry and configuration service, grey the application services and blue the client. The registry is never on the request path: it distributes instance lists and rules, and calls go straight from consumer to provider. Open the zoomable diagram, or download it as SVG or PNG.

Component	Responsibility
Dubbo Admin	Console for inspecting services and instances and for writing routing and traffic rules.
Consumer service	Application with the Dubbo SDK that holds a local instance list and picks a provider for each call.
Nacos	Registry, metadata and configuration service. Other registries such as ZooKeeper can fill this role.
Provider service	Application with the Dubbo SDK that exposes a service on the Triple port and registers its instances.
gRPC or HTTP client	A client without the Dubbo SDK that calls the provider’s Triple port directly.

Design principle. Put governance in the SDK and keep the registry off the data path. Each consumer already knows the instances and rules, so a registry outage stops changes but not traffic.

Request flow

1. Register instance. On startup the provider registers its address, port and metadata in Nacos.
2. Write routing rules. An operator uses Dubbo Admin to write condition or tag routing rules, which are stored with the registry’s configuration.
3. Push instances. Nacos pushes the current instance list and rules to the consumer, which keeps them locally and updates them on change.
4. Triple call. The consumer applies the rules, picks an instance with its load balancing policy and calls it over Triple on HTTP/2. On failure the cluster policy can retry another instance.
5. Other clients. Because Triple is gRPC-compatible, a client without the Dubbo SDK, such as a gRPC client or curl, can call the same provider port.

Open the zoomable flow diagram, or download it as SVG or PNG.

Production reference design

A typical design runs Dubbo services as Deployments on Kubernetes with Nacos as the registry.

1. Install Nacos in a platform namespace with persistent storage and at least three replicas, using the project’s Helm chart or manifests.
2. Configure the provider in Spring Boot with the Triple protocol and the registry address:

   dubbo:
     application:
       name: inventory
     protocol:
       name: tri
       port: 50051
     registry:
       address: nacos://nacos.platform:8848

   Expose the implementation with @DubboService on the class.
3. Configure the consumer with the same registry address and inject the client with @DubboReference. The consumer needs only the shared interface, not provider addresses.
4. Deploy Dubbo Admin to inspect instances and write routing rules, and restrict access to it.
5. Roll out safely. Use tag routing to send a small share of calls to a new version before widening it.

Typical uses include microservice estates in Java, migrations of older Dubbo systems to Triple, and mixed-language platforms where Go and Java services share a registry. Application-level service discovery in Dubbo 3 registers one record per application rather than per method, which reduces registry load in large estates.

Operational considerations

• Registry availability. Running consumers keep their last instance list, but new deployments and rule changes need the registry. Run it with three or more replicas.
• Instance lifecycle. Configure graceful shutdown so a provider deregisters and drains before the pod stops; otherwise consumers can call a terminated instance.
• Security. Enable TLS on the Triple port and authentication on the registry and Admin, since both can change traffic.
• Kubernetes fit. Dubbo can use Kubernetes as the registry and can run proxyless with xDS under Istio, but its default model is its own registry and SDK, which overlaps with Kubernetes Services.
• Version alignment. Keep SDK versions compatible across services and test protocol changes, especially when moving from the Dubbo protocol to Triple.

Adoption

• Alibaba created Dubbo and runs a large internal estate on it, and the Alibaba Cloud service MSE offers managed Dubbo governance.
• The project maintains a list of user organisations in its repository and on the Dubbo website; consult it for current names. It is widely used by Chinese technology companies, and public adopter lists outside that region are shorter.

Alternatives

Solution	Model	Best suited to
gRPC (CNCF Incubating)	RPC framework without built-in governance	Language-neutral RPC with discovery and balancing supplied by the platform; see the gRPC brief
Connect RPC (CNCF Sandbox)	gRPC-compatible HTTP RPC	Browser and curl friendly APIs; see the Connect RPC brief
Istio, Linkerd or Kuma	Service mesh	Governance in the platform instead of the SDK; see the Kuma brief
Spring Cloud	Java framework with HTTP clients	Java teams that prefer REST and a Spring-only stack

Strengths and limitations

Strengths	Limitations
Discovery, load balancing and routing built into the SDK	Governance is tied to the SDK and its language
Triple is gRPC-compatible and works with plain clients	Java is the most complete SDK; others vary in features
Registry stays off the request path	Another system (registry) to run next to Kubernetes
Proxyless mesh option through xDS	Overlaps with Kubernetes Services and service meshes
Apache 2.0 and Apache governance	Fewer public adopters outside China

Recommendation

Assess for teams outside the existing Dubbo ecosystem, and Adopt for Java estates that already run Dubbo. For new Kubernetes platforms, start with gRPC and a mesh or the platform’s own discovery, and consider Dubbo when SDK-level governance and a Java-first stack are a real advantage. Choose Triple rather than the older protocol, and test registry loss before relying on it.

References: Apache Dubbo website · Dubbo repository · CNCF Landscape entry