Unveiling Dubbo RPC: Step‑by‑Step Core Process Explained

A Simple Demo

To make the tutorial self‑contained, a minimal Dubbo demo is presented. The provider implements DemoService and is annotated with @DubboService . The consumer is a separate project that uses a unit test with @DubboReference to call the service.

Running the provider and the consumer test shows a successful remote service invocation.

Provider Exposure

When the provider starts, it performs two main tasks:

Opens a server socket on the protocol‑specific port (default Dubbo protocol on port 20880) to accept consumer requests.

Registers the service metadata (interface name, method signatures, host IP, port, protocol, etc.) in a metadata center or local cache (Nacos or Zookeeper in Dubbo 3.x).

Consumers later retrieve this metadata to know how to call the service.

Consumer Reference

The consumer creates a dynamic proxy for the service interface, either via JDK dynamic proxy or Javassist bytecode generation (default). It also fetches the service metadata from the metadata center or local cache and prepares the connection (e.g., establishing a long‑lived connection for the Dubbo protocol).

Parameter Packaging

The RPC call starts with InvokerInvocationHandler.invoke , which wraps the interface, method name, and arguments into a RpcInvocation object and then calls invoker.invoke(rpcInvocation) , triggering the core flow.

ClusterFilter Filtering

After parameter packaging, the request passes through ClusterFilter , a responsibility‑chain extension point that can perform pre‑processing such as monitoring or integrating with frameworks like Sentinel.

Cluster Invocation Decision

Dubbo then decides how to invoke a cluster of service instances. Available cluster strategies include broadcast, available, failback, failfast, failover (default), failsafe, forking, and mergeable. The chosen strategy determines whether one or multiple instances are called and how failures are handled.

Routing Strategy

Routing filters the set of candidate instances. For example, a tag‑based route can ensure that a gray‑release consumer only calls providers with the same gray tag. Other routing options include condition routing and script routing.

Load Balancing

After routing, a load‑balancing algorithm selects a concrete instance. Supported algorithms are random (default), round‑robin, least‑active, shortest‑response, and consistent‑hash. The load‑balancer is applied only when the cluster strategy requires a single target.

Filter Filtering

Before the request is sent, a generic Filter chain (different from ClusterFilter ) can perform additional processing on each selected instance. It runs once per instance, whereas ClusterFilter runs only once for the whole call.

Communication Protocol

Dubbo supports multiple communication protocols. The default is the Dubbo protocol, but Rest (HTTP), gRPC, and Triple are also available. Each protocol determines how the request data is packaged and transmitted.

Serialization Protocol

The data payload is serialized according to a serialization protocol. For the Dubbo protocol, supported serializers include Java native, Hessian2, Fastjson2 (default since 3.2.0), and others.

Provider Handling Request

When the provider receives the request bytes, it deserializes them using the chosen protocol and serializer, invokes the target method via reflection, serializes the result, and sends it back. Provider‑side Filter s can also intercept the call.

Conclusion

The entire RPC flow—from consumer proxy creation, parameter packaging, filter chains, cluster decision, routing, load balancing, protocol handling, serialization, to provider processing—is extensible via Dubbo’s many extension points, demonstrating the framework’s design flexibility.