Unlocking Dubbo: A Visual Guide to Its 10‑Layer Architecture and Call Flow
This article explains Dubbo's role as a high‑performance RPC framework, details its ten‑layer architecture, and walks through the eleven‑step call process, providing clear diagrams and concise descriptions for developers building distributed systems.
What Is Dubbo?
Dubbo is an open‑source, high‑performance, lightweight RPC framework created by Alibaba, offering a complete solution for service governance, remote invocation, load balancing, fault tolerance and other capabilities needed to build distributed communication systems.
Why Use Dubbo?
When an application is decomposed into multiple independent services, Dubbo manages the communication and invocation relationships between those services, allowing remote procedure calls to feel like local calls.
Overall Architecture
The architecture consists of a consumer side (light‑blue interfaces), a provider side (light‑green interfaces) and shared interfaces in the middle, as illustrated in the diagram below.
Ten‑Layer Design
Service Interface Layer : defines business‑related interfaces and implementations for providers and consumers.
Configuration Layer : external configuration centered on ServiceConfig and ReferenceConfig, configurable via code or Spring.
Proxy Layer : transparent proxy generating client stubs and server skeletons, based on ServiceProxy and ProxyFactory.
Registry Layer : encapsulates service address registration and discovery, centered on service URLs, with RegistryFactory, Registry and RegistryService.
Cluster Layer : aggregates multiple providers, handling routing, load balancing and presenting them as a single provider to consumers.
Monitor Layer : monitors RPC call counts and latency, centered on Statistics with MonitorFactory, Monitor and MonitorService.
Protocol Layer : manages RPC invocation and result handling, centered on Protocol, Invoker and Exporter; Invoker is the core model representing an executable entity.
Exchange Layer : abstracts request‑response patterns, supporting synchronous‑to‑asynchronous conversion, centered on Request and Response.
Transport Layer : unifies network frameworks such as Mina and Netty, centered on Message with Channel, Transporter, Client, Server and Codec.
Serialization Layer : provides reusable serialization utilities, centered on Serialization, ObjectInput, ObjectOutput and ThreadPool.
Call Process
The overall call flow, shown in the diagram below, follows eleven steps:
The provider starts the service and registers it with the registry.
The consumer periodically pulls the provider list from the registry.
When the consumer needs to invoke a service, it creates a dynamic proxy object to call the remote interface.
The proxy passes through the Cluster layer, which obtains the current provider list.
Cluster selects a provider based on the configured load‑balancing algorithm.
The chosen provider and protocol are determined.
Exchange packages the request according to the protocol.
The request is sent over the network via the transport framework.
The provider’s transport receives the request and deserializes it.
Exchange parses the request according to the protocol.
The dynamic proxy finally invokes the target service implementation.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Mike Chen's Internet Architecture
Over ten years of BAT architecture experience, shared generously!
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.