Designing an RPC Framework: Concepts, Components, and the Evolution of Dubbo

01 RPC and RPC Frameworks

Remote Procedure Call (RPC) abstracts the details of network communication so that developers can invoke methods on remote services as if they were local, without needing to understand the underlying transport or serialization mechanisms.

An RPC framework hides the transport protocol (TCP/UDP), serialization format, and other communication details, allowing business code to focus solely on business logic.

In China, well‑known RPC frameworks include Alibaba's internal HSF and the open‑source Dubbo.

02 The Origin of Dubbo

1. Small business scale

Early applications were packaged as a single Java WAR and deployed on a single server, making inter‑service calls trivial and avoiding any distributed concerns.

2. Growing business scale

As the number of subsystems exploded (e.g., Taobao’s transaction, product, user, and review systems), monolithic deployments became cumbersome, leading to long build times, difficult rollbacks, and painful merge conflicts.

These challenges highlighted the need to decouple services and deploy them independently.

3. Emergence of Dubbo and HSF

When applications required split deployments, a high‑efficiency inter‑service communication mechanism—distributed remote invocation—became essential, prompting the creation of internal HSF and the open‑source Dubbo framework.

03 How to Design an RPC Framework

The core goal of an RPC framework is to solve service‑to‑service invocation in distributed systems.

Designing such a framework demands deep knowledge of communication protocols, serialization, message mechanisms, and the underlying operating system and language runtime.

1. Three core roles

1) Service Provider (Server) – registers its services with a registry.

2) Registry – stores service metadata (IP, port, protocol, serialization) and enables discovery; common implementations include Zookeeper, Eureka, Consul, and Etcd. Dubbo uses Zookeeper.

3) Service Consumer (Client) – retrieves service metadata from the registry and performs remote calls.

2. RPC Call Process

1) The client invokes a local stub. 2) The client stub serializes the method name and parameters into a network‑transferable message. 3) The stub looks up the service address and sends the message. 4) The server stub deserializes the message. 5) The server stub calls the local service implementation. 6) The service processes the request. 7) The result is returned to the server stub. 8) The server stub serializes the result. 9) The response is sent back over the network. 10) The client stub receives and deserializes the response. 11) The client receives the final result.

The framework’s purpose is to encapsulate steps 2‑10, providing a seamless remote call experience.

04 Technical Aspects of an RPC Framework

1. Establishing Communication – Typically a TCP connection is created between client and server to carry all RPC traffic.

2. Service Addressing

• Service Registration – Services register their metadata (IP, port, protocol, serialization) in a registry such as Zookeeper, which creates a znode containing this information. • Service Discovery – Consumers query the registry once, cache the address list, and later use load‑balancing to select a provider without further registry calls. • Reliable Registration – A robust registry is the foundation for service discovery.

3. Network Transport – Choose a protocol and define how data is serialized/deserialized.

4. NIO Communication – Modern RPC frameworks often build on Netty (or similar NIO libraries) for high‑performance I/O.

5. Service Invocation – After a local proxy call, the result must be serialized, transmitted back, and deserialized on the caller side.

In summary, implementing a basic RPC mechanism is straightforward; building a high‑performance, reliable RPC framework like Dubbo involves addressing all the above technical challenges.

Related articles:

How to Design a Message Queue from 0 to 1

High‑Concurrency Architecture Series: 12 Core Principles of Message Queues

High‑Concurrency Architecture Series: Redis Cache and MySQL Consistency Solutions

High‑Concurrency Architecture Series: Why Redis Is Single‑Threaded and Its Performance Advantages