Understanding Dubbo: Core Functions, Architecture Layers, and Call Process of the RPC Framework

The previous article introduced the fundamentals of distributed RPC and hinted at analyzing Dubbo; this piece continues by exploring Dubbo's underlying implementation.

Dubbo offers three core functions: interface‑based remote method invocation, intelligent fault tolerance with load balancing, and automatic service registration and discovery.

Remote Method Invocation : Dubbo abstracts multiple NIO frameworks, supporting synchronous‑to‑asynchronous conversion and a request‑response communication model.

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

Service Registration and Discovery : Using a registry center, providers register services while consumers subscribe to them, enabling dynamic lookup, address transparency, and seamless scaling of service instances.

The framework’s core components include the registry, consumer, provider, container (typically Spring), and monitor for tracking call counts and latency.

Dubbo’s architecture is divided into ten layers: Service (business interface), Config (configuration APIs), Proxy (client stub and server skeleton generation), Registry (service address registration/discovery), Cluster (routing and load balancing), Monitor (statistics), Protocol (RPC invocation handling), Exchange (request‑response exchange), Transport (network transport abstraction such as Netty or Mina), and Serialize (serialization utilities).

The RPC call process follows eight steps: (1) Provider starts Netty, creates a Zookeeper client, and registers services; (2) Consumer retrieves provider list from Zookeeper and establishes a long‑lived Netty connection; (3) Consumer invokes the remote interface via a dynamically generated proxy; (4) The proxy creates an Invoker object; (5) The Invoker selects an optimal provider through routing and load balancing, wrapping itself into a DubboInvoker; (6) The Invoker is packaged into a Request, serialized, and sent over Netty; (7) The provider deserializes the request, creates a DubboExporter, and generates a server‑side Invoker; (8) The server‑side Invoker executes the local service, returns the result through the same layered callbacks, and the consumer receives the final response.

The article concludes with a call to follow the "mikechen's Internet Architecture" public account, reply with specific keywords to receive architecture or interview resource collections, and highlights that these resources cover topics such as single sign‑on, distributed caching, microservices, middleware, high concurrency, performance optimization, and big data.