Mastering Custom RPC Frameworks: Architecture, Protocols, and Implementation

What is RPC?

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

Basic RPC Framework Architecture

The framework consists of three main components: client, server, and registry. The server registers its services with the registry, and the client discovers services via the registry.

During a call, the client uses a local proxy (client stub) to serialize method name and parameters into a network byte stream, selects a service address from the registry, and sends the request to the server. The server decodes the request, invokes the target service, and returns the result.

Specific Call Process

Client (consumer) calls the service locally.

Client stub packages the method and parameters.

Client stub encodes and sends the message.

Server stub receives and decodes the message.

Server stub invokes the local service.

Service result is returned to the server stub.

Server stub encodes the response and sends it back.

Client stub decodes the response.

Client receives the result.

Technical Choices

Registry : Zookeeper (no switchable option).

IO Framework : Netty (high‑performance NIO).

Message Protocol : Custom protocol defined in the project.

Project Structure

The modules prefixed with rpc contain the framework core, while consumer and provider represent the client and server sides respectively.

Dependency Overview

Implementation Details

The framework is packaged as two Spring Boot starters (client‑starter and server‑starter) to minimize configuration for users.

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

Services are exposed with @RpcService and consumed with @RpcAutowired. The client uses dynamic proxies to invoke remote methods, and Netty handles the network transport.

Load Balancing

Implemented strategies include round‑robin ( FullRoundBalance) and random ( RandomBalance), configurable via rpc.client.balance. Custom strategies can be added by implementing the LoadBalance interface.

Custom Message Protocol and Codec

The protocol includes fields such as magic number, version, serialization algorithm, message type, status, message ID, data length, and payload. Encoding and decoding are implemented in rpc-core using Netty’s MessageToByteEncoder and ByteToMessageDecoder.

TCP Packet Framing

To avoid TCP sticky‑packet and fragmentation issues, the framework uses a length‑field‑based framing (message length + content) to determine packet boundaries.

Overall Architecture and Flow

The process includes provider startup (registering services to Zookeeper and starting a Netty server), consumer startup (discovering services, applying load balancing, and creating dynamic proxies), and the actual RPC call flow.

Environment Setup

OS: Windows

IDE: IntelliJ IDEA

Tech Stack: Spring Boot 2.5.2, JDK 1.8, Netty 4.1.42.Final

Build Tool: Maven 4.0.0

Registry: Zookeeper 3.7.0

Testing

Start Zookeeper server.

Run the provider module ( ProviderApplication ).

Run the consumer module ( ConsumerApplication ).

Access http://localhost:9090/hello/world?name=hello to see the response 您好：hello, confirming successful RPC invocation.

Project Code

Source repository: https://gitee.com/listen_w/rpc