Understanding RPC Framework Architecture: Core Concepts, Functions, and Common Implementations

Typical RPC Framework Architecture

A typical RPC architecture consists of three parts: the service provider (RPC Server) that hosts the service implementation, a registry that publishes and manages service metadata, and the service consumer (RPC Client) that invokes remote methods via a proxy.

When a client calls a remote method, the process generally follows these steps:

The provider registers its IP, port, and service list with the registry.

The consumer retrieves the provider list from the registry and caches it locally.

The consumer makes a local call; a load‑balancing module selects an appropriate remote address.

The protocol module serializes the method name and parameters into a network‑transferable message and sends it.

The server decodes the message, invokes the local service, and processes the request.

The server serializes the result and sends it back.

The client decodes the response and obtains the final result.

Note: The order of steps 1‑3 may vary across different RPC implementations.

Core RPC Functions

The three essential functions of any commercial RPC framework are service discovery, data serialization/deserialization, and network transport.

Service Discovery

Remote calls require a way for the consumer to locate the provider. This is achieved by assigning a unique ID to each remote method, transmitting that ID with the request, and maintaining a mapping table of IDs to methods on both sides.

Commonly, a service registry (e.g., Zookeeper) is used to store provider addresses, and clients query the registry and apply load‑balancing strategies to select an instance.

Data Serialization (Encoding/Decoding)

Data transmitted over the network must be binary. Serialization converts objects into a binary stream, while deserialization restores the binary data back into objects. These processes are often referred to simply as serialization and deserialization.

Strictly speaking, serialization and encoding are distinct concepts, but they are frequently used interchangeably.

Network Transport

RPC frameworks can use any transport protocol that can carry the serialized request and response. TCP is common due to its reliability and support for both short‑lived and long‑lived connections, while some frameworks (e.g., gRPC) use HTTP/2.

Data serialization and transport can be combined in many ways, such as HTTP + JSON or Dubbo protocol + TCP.

Common RPC Frameworks

RMI (Sun/Oracle)

Thrift (Facebook/Apache)

gRPC (Google)

Finagle (Twitter)

Dubbo (Alibaba/Apache)

Motan (Sina Weibo)

brpc (Baidu/Apache)

…and others.

Summary

To build an RPC framework you need to provide service definitions, generate remote proxy objects for consumers, handle serialization of request/response data, and implement a network communication layer (often using Netty). Implementing these four aspects yields a functional RPC system.