How to Design and Implement a Custom RPC Framework from Scratch

What Is RPC?

Remote Procedure Call (RPC) enables developers to invoke remote services as if they were local methods, abstracting network communication complexities.

Basic RPC Framework Architecture

The framework consists of three core components: client, server, and registry. During a call, the server registers its services to the registry, the client discovers service addresses, and communication proceeds through proxies and network transmission.

Communication Process and Roles

Key roles include service governance (registration/discovery), load balancing, fault tolerance, serialization/deserialization, encoding/decoding, network transport, thread pools, and dynamic proxies. Optional components may include connection pools, logging, and security.

Practical Implementation

The framework is packaged as two Spring Boot starters—client‑starter and server‑starter—to minimize configuration. The server starter registers services annotated with @RpcService to Zookeeper, while the client starter injects proxies for fields annotated with @RpcAutowired.

Configuration is driven by spring.factories:

org.springframework.boot.autoconfigure.EnableAutoConfiguration=com.rrtv.rpc.client.config.RpcClientAutoConfiguration

Registration Center

Zookeeper is used as the registry; both providers and consumers interact with it via the rpc-core module.

Load Balancing

Two strategies are provided: round‑robin ( FullRoundBalance) and random ( RandomBalance), with random as the default. Custom strategies can be added by implementing the LoadBalance interface.

Custom Message Protocol and Codec

The protocol includes a magic number, version, serialization type, message type, status, request ID, data length, and payload. Encoding and decoding are implemented with Netty’s MessageToByteEncoder and ByteToMessageDecoder in the com.rrtv.rpc.core.codec package.

To handle TCP packet fragmentation and aggregation, the protocol uses a length‑field‑based framing ("message length + content") to delineate message boundaries.

Serialization

Both Hessian and JSON serializers are available; Hessian is the default and cannot be overridden by users.

Network Transport

Netty provides the non‑blocking I/O layer. Correct handler ordering is crucial: decoders first, then encoders, followed by business logic handlers.

Client Call Types

The framework supports four call modes: synchronous (Sync), asynchronous (Future), callback (Callback), and one‑way (Oneway). The current implementation uses synchronous calls backed by a CountDownLatch for timeout handling.

Overall Flow

1. Provider starts, registers services to Zookeeper, and launches a Netty server. 2. Consumer starts, scans beans for @RpcAutowired, creates dynamic proxies, discovers services via Zookeeper, and selects an instance using the load‑balancer. 3. The proxy encodes the request, sends it over Netty, the server decodes it, invokes the target method via reflection, encodes the response, and sends it back. 4. The client decodes the response and completes the RpcFuture to return the result.

Environment Setup and Testing

Run Zookeeper, start the provider module ( ProviderApplication), then the consumer module ( ConsumerApplication). Access http://localhost:9090/hello/world?name=hello to see the response "您好：hello" confirming successful RPC invocation.

Project Code

Source code is available at https://gitee.com/listen_w/rpc .