Understanding RPC: Architecture, Workflow, and Core Technologies

1. RPC Overview

Remote Procedure Call (RPC) is a method for invoking functions on a remote machine as if they were local, built on top of sockets. It enables a program on server A to call a service on server B, translating the call semantics and data across the network.

Using RPC, developers can distribute applications across multiple servers, share code, improve resource utilization, and offload heavy computation to more powerful machines, while keeping the programming model simple.

2. Goals and Principles of RPC Architecture

The primary goal of RPC is to make building distributed applications easier and transparent, preserving the simplicity of local calls. An RPC framework hides transport details (TCP/UDP), serialization formats (XML/JSON/binary), and communication protocols, allowing developers to focus on service interfaces.

Because RPC abstracts these details, the generated network packets often consume more bandwidth than raw socket communication.

3. Protocol Layers and Serialization

From the protocol perspective, RPC can be divided into:

HTTP‑based protocols such as SOAP (XML), REST (JSON), and binary Hessian.

TCP‑based protocols that typically rely on high‑performance frameworks like Mina or Netty.

Serialization is the process of converting an object into a binary stream for transmission; deserialization reverses this process.

4. Core Architectural Components

RPC architecture consists of three main parts:

Service Provider (RPC Server) : runs on the server side, implements the service interface.

Registry (Service Center) : registers service instances, manages their addresses, and provides discovery for clients.

Service Consumer (RPC Client) : runs on the client side, invokes remote services via a local proxy.

When a provider starts, it registers its IP, port, and service list with the registry. A consumer retrieves this list from the registry, enabling soft load balancing and failover.

5. Detailed RPC Call Flow

The complete RPC invocation involves ten steps, which the framework encapsulates to keep them transparent to the user:

Client calls a method locally.

Client stub packages method name, parameters, and other metadata into a network message.

Client stub resolves the service address and sends the message via socket.

Server stub receives and decodes the message.

Server stub invokes the corresponding local service implementation.

The service executes and returns the result to the server stub.

Server stub packages the result into a response message.

Server stub sends the response back to the client via socket.

Client stub receives and decodes the response.

Client obtains the final result of the remote call.

The framework hides steps 2‑9, providing a seamless experience for developers.

6. Core Technical Points

Service Definition : providers must expose interface definitions, data structures, or IDL files (e.g., Thrift IDL, WSDL).

Remote Proxy Object : the client interacts with a local proxy that forwards calls to the remote service, often implemented via dynamic proxies.

Communication Independence : the RPC framework is agnostic to the underlying transport protocol.

Serialization : objects are converted to binary streams for transmission; different frameworks may use different serialization strategies.

7. Common RPC Frameworks and Technologies

Application‑level service frameworks: Alibaba Dubbo/Dubbox, Google gRPC, Spring Boot / Spring Cloud.

Remote communication protocols: RMI, raw Socket, SOAP (HTTP XML), REST (HTTP JSON).

Network libraries: Apache MINA, Netty.