Why Dubbo Remains a Top Java RPC Framework for Modern Backend Systems

Background

In the early days, web applications were monolithic, low traffic, all functions and code deployed together, low cost. At that time the ORM database access framework was key.

Later, as traffic grew, monoliths were split into independent vertical applications, making the MVC web framework essential for accelerating front‑end development.

Subsequently, vertical applications became larger, and inter‑service interaction was inevitable, so distributed service frameworks (RPC) became critical.

Dubbo

RPC (Remote Procedure Call) allows calling remote objects as easily as local methods. Common RPC frameworks include Dubbo, gRPC, Thrift, etc.

Dubbo (pronounced “dub‑bow”) is a high‑performance, lightweight open‑source Java RPC framework that provides three core capabilities: interface‑based remote method invocation, intelligent fault‑tolerance and load balancing, and automatic service registration and discovery. It is widely adopted by many companies.

History

Dubbo’s development can be divided into three stages:

Birth at Alibaba: originated internally in 2008, open‑sourced in 2011, version 2.5.3 released in 2012, then stopped updates.

Continuation by Dangdang: in 2014 Dangdang released Dubbox, based on Alibaba’s 2.5.3 with added REST protocol.

Apache revival: Alibaba restarted the project in 2017, entered Apache incubation in 2018, became a top‑level Apache project in 2019, and released multi‑language versions (dubbo.js, dubbo-go) and a cloud‑native roadmap in 2020.

Current supported versions are mainly 2.6.x and 2.7.x:

2.6.x focuses on bug fixes and minor enhancements, ensuring full stability.

2.7.x is the main community development line, adding many new features and optimizations, but also introducing some stability challenges.

Feature Overview

Protocol

Dubbo’s native protocol layout is as follows:

0‑15: magic number to identify Dubbo protocol.

16: request or response flag.

17: whether a response is expected.

18: event message flag (e.g., heartbeat).

19‑23: serialization flag.

24‑31: response status flag (similar to HTTP status).

32‑63: request ID.

64‑95: content length (bytes).

96‑?: serialized payload (newline‑separated).

The protocol is compact and has consistent request/response headers, but it cannot locate resources via headers, contains redundant fields, and is not easily extensible.

Dubbo also supports extensions such as the REST protocol from Dangdang and the newer gRPC protocol.

Extension is a major highlight; Dubbo’s SPI‑based design enables non‑intrusive addition of many functionalities.

Registry Center

The registry center provides:

Dynamic registration: providers expose themselves without each consumer updating config files.

Dynamic discovery: consumers discover new services without restart.

Unified configuration to avoid inconsistent local settings.

Dynamic parameter adjustment propagated to all related nodes.

Centralized management: using data from the registry to manage service nodes. Common implementations use Zookeeper or Nacos, with many other extensions.

Cluster

Cluster features include routing, load balancing, and fault tolerance. For example, a Dubbo user service deployed with 10 providers in Beijing and 20 in Shanghai, when called from Hangzhou, will:

Route according to configured rules, typically to the nearer Shanghai providers.

Select one provider randomly based on the load‑balancing strategy.

If the selected provider fails, the failover fault‑tolerance mode retries other providers until success.

The three steps correspond to routing, load balancing, and cluster fault tolerance respectively.

Filter

Filters are a crucial extension point in Dubbo, implementing most functionalities via a chain‑of‑responsibility pattern. Each invocation passes through configured filters.

Common filters include monitoring, logging, rate limiting, degradation, and authentication.

Three Core Centers

Dubbo relies on three centers: registry, metadata, and configuration. The volume of registration data can be huge, so metadata and configuration centers help offload the registry.

/dubbo/org.apache.dubbo.demo.DemoService/providers/dubbo%3A%2F%2F172.23.234.48%3A20880%2Forg.apache.dubbo.demo.DemoService%3Fanyhost%3Dtrue%26application%3Ddubbo-demo-api-provider%26default%3Dtrue%26deprecated%3Dfalse%26dubbo%3D2.0.2%26dynamic%3Dtrue%26generic%3Dfalse%26interface%3Dorg.apache.dubbo.demo.DemoService%26metadata-type%3Dremote%26methods%3DsayHello%2CsayHelloAsync%26pid%3D21563%26release%3D%26side%3Dprovider%26timestamp%3D1600336623852

After splitting, the metadata center stores relatively static data, while the configuration center pushes only changed configurations.

/dubbo/org.apache.dubbo.demo.DemoService/providers/dubbo%3A%2F%2F172.23.234.48%3A20880%2Forg.apache.dubbo.demo.DemoService%3Fapplication%3Ddubbo-demo-api-provider%26deprecated%3Dfalse%26dubbo%3D2.0.2%26timestamp%3D1600336144382

Generic Invocation

Typically, Dubbo callers import the provider’s interface JAR, but calls can be made without it by providing interface name and parameter types, useful for testing platforms or gateways.

Future Development

Dubbo’s roadmap has shifted toward cloud‑native and reactive programming. In 2019, the focus was on reactive programming to overcome thread‑pool limits in I/O‑intensive services. Reactive programming, exemplified by RSocket, enables declarative data‑flow handling, and Dubbo 3.0.0‑SNAPSHOT adds RSocket support with Mono and Flux types.

With the rise of cloud‑native concepts, Dubbo is adapting to container orchestration and service mesh environments. Traditional SDK‑centric service registration conflicts with Kubernetes‑style service discovery, so recent versions support application‑level discovery, e.g.:

/dubbo/org.apache.dubbo.demo.DemoService/providers/dubbo%3A%2F%2F172.23.234.48%3A20880%2Forg.apache.dubbo.demo.DemoService%3Fapplication%3Ddubbo-demo-api-provider%26deprecated%3Dfalse%26dubbo%3D2.0.2%26timestamp%3D1600336144382

becomes

/services/dubbo-demo-api-provider/172.23.234.48:20880

Future mesh integration may further reduce SDK reliance.