In-depth Explanation of Dubbo: Core Functions, Components, Architecture, and Call Process

Dubbo is a Java RPC framework that aims to deliver high‑performance remote service invocation solutions.

The article focuses on explaining Dubbo’s underlying principles and mechanisms.

Table of Contents

Dubbo core functions

Dubbo core components

Dubbo architecture design

Dubbo call process

Dubbo Core Functions

Dubbo provides three major capabilities: interface‑based remote method invocation, intelligent fault tolerance and load balancing, and automatic service registration and discovery.

1) Remote Method Invocation – a network communication framework that abstracts various NIO frameworks, supporting synchronous‑to‑asynchronous conversion and request‑response exchange patterns.

2) Intelligent Fault Tolerance and Load Balancing – transparent remote calls based on interface methods, multi‑protocol support, soft load balancing, failure tolerance, address routing, dynamic configuration, and other clustering features.

3) Service Registration and Discovery – a registry‑center‑based directory service that enables consumers to dynamically locate providers, making addresses transparent and allowing providers to scale up or down smoothly.

Dubbo Core Components

The main roles in Dubbo consist of the following components:

Registry – producers register and publish services here, while consumers subscribe to receive them.

Consumer – the client that obtains service methods from the registry and invokes them on providers.

Provider – the server side that offers services, typically requiring a container (e.g., Spring) to start.

Container – the runtime environment required by providers to launch (default is the Spring container).

Monitor – collects statistics such as call counts and execution times.

Dubbo Architecture Design

The overall architecture is illustrated in the diagram below (image retained from the original source).

The diagram shows that the light‑blue background on the left represents interfaces used by service consumers, the light‑green background on the right represents interfaces used by service providers, and the central axis contains interfaces shared by both sides.

Dubbo’s framework is divided into ten layers:

Service Interface Layer – defines business‑related interfaces and implementations for both providers and consumers.

Configuration Layer – external configuration interfaces centered on ServiceConfig and ReferenceConfig, configurable via code or Spring.

Proxy Layer – transparent service interface proxies that generate client stubs and server skeletons, centered on ServiceProxy and ProxyFactory.

Registry Layer – encapsulates service address registration and discovery, centered on service URLs and interfaces such as RegistryFactory, Registry, and RegistryService.

Cluster Layer – aggregates multiple providers, handling routing, load balancing, and presenting them as a single logical provider, centered on Invoker and interfaces like Cluster, Directory, Router, and LoadBalance.

Monitor Layer – monitors RPC call counts and timings, centered on Statistics and interfaces such as MonitorFactory, Monitor, and MonitorService.

Protocol Layer – encapsulates RPC calls, centered on Invocation and Result, with interfaces Protocol, Invoker, and Exporter. It manages the lifecycle of Invoker, which can represent local, remote, or clustered implementations.

Exchange Layer – implements request‑response patterns and async conversion, centered on Request and Response, with interfaces like Exchanger, ExchangeChannel, ExchangeClient, and ExchangeServer.

Transport Layer – abstracts network transports (e.g., Mina, Netty) with a unified Message interface and related components such as Channel, Transporter, Client, Server, and Codec.

Serialize Layer – provides reusable serialization utilities, with interfaces like Serialization, ObjectInput, ObjectOutput, and ThreadPool.

Dubbo Call Process

The following diagram (image retained) shows the overall call flow, which can be broken down into eight major steps:

Service provider starts, launches a Netty server, creates a Zookeeper client, and registers the service with the registry.

Service consumer starts, retrieves the provider list from Zookeeper, and establishes a long‑lived Netty connection with the provider.

Consumer initiates a remote call via the interface; ProxyFactory creates a dynamic proxy object.

The dynamic proxy’s invoke method wraps the call into an Invoker object.

The Invoker selects an optimal provider through routing and load balancing, then wraps itself with filters and protocol layers to become a DubboInvoker.

The DubboInvoker is packaged into a Request, serialized, and sent via NettyClient to the provider’s NettyServer.

On the provider side, the request is deserialized, protocol‑decoded, and transformed into a DubboExporter, which eventually yields a provider‑side Invoker.

The provider‑side Invoker executes the local service, returns the result, which propagates back through the layered callbacks to the consumer, where it is finally parsed and delivered.

The article concludes with a call to follow the “mikechen的互联网架构” public account for additional resources.