Implementing a High‑Performance RPC Server with Netty in Java

Remote Procedure Call (RPC) is a protocol that lets a client invoke methods on a remote server as if they were local, abstracting away network details; common frameworks include Thrift and Dubbo, and most implementations rely on TCP or HTTP transport and various I/O models (select, epoll, IOCP).

The performance of an RPC framework largely depends on the chosen network I/O model (blocking, non‑blocking, multiplexed, or asynchronous) and the transport protocol; TCP is dominant, while UDP is rarely used for mainstream RPC solutions.

To build a high‑performance RPC server from scratch, the author uses Java with Netty (version 4.0) as the underlying NIO framework, leveraging its non‑blocking I/O, flexible thread pools, and built‑in handlers for TCP framing (e.g., LengthFieldBasedFrameDecoder).

The implementation steps include:

Defining request and response message structures that carry interface name, method name, parameter types, and values.

Loading the mapping between RPC interfaces and their implementations during server initialization.

Encoding/decoding messages using Java serialization (with a note that more efficient serializers such as Protobuf, JBoss Marshalling, or Avro could be substituted).

Using reflection to instantiate service objects and invoke the requested methods.

Returning the result to the client via a response message.

Key Netty‑related components are organized under packages like newlandframework.netty.rpc.core, newlandframework.netty.rpc.model, and newlandframework.netty.rpc.config, covering thread factories, business thread pools, client proxies, and server executors.

The client side employs a dynamic proxy ( MessageSendProxy) based on JDK’s built‑in proxy mechanism (CGLIB is mentioned but found less stable under high concurrency).

Performance testing creates 10,000 simultaneous RPC calls to a simple addition service; the server processes all requests in roughly 11 seconds without packet loss, sticky packets, or I/O blocking, demonstrating the effectiveness of the Netty‑based design.

Potential improvements listed include adopting more efficient serialization frameworks, customizing Netty’s thread model per business needs, supporting one‑to‑many service bindings, externalizing thread‑pool parameters, and decoupling business logic via message queues such as ActiveMQ or RocketMQ.