Mastering RPC: Core Principles, Architecture, and Popular Frameworks

1. Why RPC Is Needed

As web applications grow, a single‑process architecture can no longer handle traffic; vertical applications are split into multiple services, and a distributed service architecture requires a unified way to invoke remote functions without duplicating serialization, networking, and connection‑management code. RPC frameworks provide this unified service layer.

2. What Is RPC?

Remote Procedure Call (RPC) is a protocol that allows a program to execute a function on a remote machine as if it were a local call. It abstracts the communication protocol, serialization, interface description, service framework, performance considerations, and language support.

3. RPC Architecture Components

A basic RPC architecture consists of four components:

Client : the service consumer.

Client Stub : stores server address information, packages request parameters into a network message, and sends it to the server.

Server Stub : receives the request, unpacks it, and invokes the local service.

Server : the actual service provider.

4. RPC vs. REST, SOAP, and SOA

REST is a simple HTTP‑based protocol that typically uses JSON, offering low overhead but weaker security. SOAP is a heavyweight XML‑based protocol with built‑in security extensions. SOA (Service‑Oriented Architecture) focuses on loosely coupled, coarse‑grained services. All provide distributed capabilities, but differ in protocol weight, data format, and typical use cases.

5. Problems an RPC Framework Must Solve

Choosing a communication protocol between client and server.

Efficient network transmission.

Exposing services to clients.

Service discovery for clients.

High‑performance serialization and deserialization.

6. Foundations of RPC Implementation

High‑performance network library (e.g., Netty).

Efficient serialization framework (e.g., Google Protobuf).

Reliable service registry and discovery (e.g., Zookeeper, Consul, Etcd).

Optional session and state management for stateful RPC.

7. Key Technologies Used by RPC Frameworks

Dynamic Proxy : generates client and server stubs using JDK dynamic proxies, CGLib, or Javassist.

Serialization/Deserialization : converts objects to byte streams and back; common libraries include Kryo, FastJson, Protobuf.

NIO Communication : asynchronous I/O (Netty or MINA) replaces blocking I/O for better concurrency.

Service Registry : tools like Zookeeper provide registration, discovery, and health‑checking.

8. Popular RPC Frameworks

RMI – Java native remote method invocation.

Hessian – lightweight HTTP‑based remoting.

protobuf‑rpc‑pro – Protobuf‑based RPC built on Netty.

Thrift – cross‑language framework with code generation.

Avro – Hadoop‑origin data exchange protocol.

Dubbo – Alibaba’s high‑performance Java RPC framework, integrates seamlessly with Spring.

9. RPC Call Process

Client invokes a local proxy method.

Client stub serializes method name and parameters into a network message.

Client stub sends the message to the server address.

Server stub receives and deserializes the message.

Server stub calls the local service implementation.

Service executes business logic and returns the result to the server stub.

Server stub serializes the result and sends it back.

Client stub receives the response and deserializes it.

Client receives the final result as if it were a local call.

The RPC framework hides steps 2‑8, making remote calls appear as local method invocations.

10. Service Addressing and Registration

Clients need to know the server’s host, port, and method signature. Service registries (e.g., Zookeeper, Redis) store this information, enable discovery, and provide health‑checking. Providers register themselves on startup, send heartbeats, and deregister on shutdown. Consumers query the registry to locate services and subscribe to updates.

11. Network Transmission, Serialization, and Deserialization

When a client initiates an RPC call, method name and parameters are serialized into a binary format (e.g., Protobuf) and transmitted over TCP. The server deserializes the data, invokes the method via a proxy, serializes the return value, and sends it back. The client then deserializes the response and continues processing.

12. Provider and Consumer Perspectives

From the provider side, services are registered, heartbeated, and deregistered as needed. From the consumer side, services are discovered, subscribed to, and notified of availability changes. Both sides rely on the registry for dynamic service management.