Design and Implementation of a Custom Java RPC Framework

The author shares a detailed summary of a self‑written Remote Procedure Call (RPC) framework developed for Java, aiming to illustrate the design and implementation process.

RPC, or Remote Procedure Call, enables developers to invoke methods on remote services as if they were local, abstracting network communication and making distributed calls feel like ordinary method calls.

The framework consists of three essential components: a client, a server, and a registry. During a call, the server registers its services with the registry, the client discovers service addresses, and communication proceeds via a proxy that serializes method calls into network messages.

Key roles include service governance (registration and discovery), load balancing, fault tolerance, serialization/deserialization, codec handling, network transport, thread pools, and dynamic proxies; optional features such as connection pools, logging, and security may also be incorporated.

To minimize configuration for end users, the framework is packaged as two Spring Boot starters— rpc-client-spring-boot-starter and rpc-server-spring-boot-starter —which automatically load configuration classes via spring.factories (e.g.,

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

).

Service registration relies on Zookeeper; both consumers and providers use the ZK client located in the rpc-core module to publish and discover service metadata.

The core module also defines load‑balancing strategies (FullRoundBalance and RandomBalance, defaulting to random) and serialization mechanisms (Hessian by default, with optional JSON support), providing performance comparisons for both space and time.

A custom binary message protocol is defined, containing fields such as magic number, version, serialization type, message type, status, request ID, data length, and payload. Encoding and decoding are implemented with Netty’s MessageToByteEncoder<MessageProtocol<T>> and ByteToMessageDecoder classes.

To address TCP sticky‑packet and fragmentation issues, the framework adopts a length‑prefixed framing approach (message length + content), ensuring the decoder reads complete frames before processing.

The network layer uses Netty, with careful ordering of handlers to guarantee correct inbound decoding and outbound encoding.

Four invocation modes are described—synchronous (Sync), asynchronous Future, callback, and one‑way—but only the synchronous mode is currently implemented, using a CountDownLatch to block the calling thread until a response arrives or a timeout occurs.

The overall workflow is illustrated: provider startup registers services, consumer startup discovers services and creates dynamic proxies, the client encodes requests, Netty transports them, the server decodes, invokes the target method via reflection, encodes the response, and the client finally decodes and returns the result.

Setup instructions include running a Zookeeper server, launching the provider and consumer applications, and testing the RPC call via a browser URL, which should return a greeting message.

The complete source code is available at https://gitee.com/listen_w/rpc .