Understanding RPC Frameworks: Concepts, Principles, and Code Walkthrough

1. Concept of RPC Framework

RPC (Remote Procedure Call) is a remote method invocation technique that enables services to communicate over a network, forming the foundation of micro‑service architectures. Using RPC decouples systems, simplifies maintenance, and enhances request handling capacity.

The diagram shows a simple software system split into a user service and an order service, each acting as independent services that can be called by different sites.

By importing the service interface packages, RPC calls can be made just like local method calls, which may seem surprising at first because the call appears to be a regular Java method call.

2. RPC Framework Principles

2.1 Process Overview

The RPC call process consists of five steps: three client‑side steps on the left and two server‑side steps on the right, which are explained in the following sections.

2.2 Client Invocation

The client initializes configuration, obtains the server address from a config file or configuration center, and then calls the service.

// User service interface
public interface UserService {
    public User genericUser(Integer id, String name, Long phone);
}

// Client side
// Service initialization
KRPC.init("D:\\krpc\\service\\demo\\conf\\client.xml");
UserService service = ProxyFactory.create(UserService.class, "demo", "demoService");
User user = service.genericUser(1, "yasin", 1888888888L);

Initially, one may wonder why calling an interface works without an implementation class.

This leads to the next topic: dynamic proxy .

2.3 Dynamic Proxy

Dynamic proxy acts on behalf of the interface. The UserService instance is created by ProxyFactory, which binds a proxy handler.

@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    // Construct request
    Request request = new Request();
    // ...
    return RequestHandler.request(serviceName, request, returnClass);
}

The class implements InvocationHandler, handling method name, parameter types, parameter values, and return type. It also provides serialization; RPC typically uses TCP (or HTTP) for transport.

2.4 Network Transmission

After processing method parameters, the request is sent over TCP using socket communication. Both blocking and non‑blocking approaches are possible.

2.5 Server Data Reception

The server uses Netty for high‑performance, reliable handling.

public class ServerHandler extends ChannelInboundHandlerAdapter {
    @Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
        ByteBuf buf = (ByteBuf) msg;
        byte[] bytes = new byte[buf.readableBytes()];
        buf.readBytes(bytes);
        byte[] responseBytes = RequestHandler.handler(bytes);
        ByteBuf resbuf = ctx.alloc().buffer(responseBytes.length);
        resbuf.writeBytes(responseBytes);
        ctx.writeAndFlush(resbuf);
    }

    @Override
    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
        cause.printStackTrace();
        ctx.close();
    }
}

The above is the server‑side code used in the project.

2.6 Real Invocation

After the server receives the request data, it uses reflection to invoke the target method, serializes the result, and returns it via Netty; the client parses the response, completing the RPC call.

method = clazz.getMethod(request.getMethodName(), requestParamTypes);
method.setAccessible(true);
result = method.invoke(service, requestParmsValues);

The snippet shows reflection invoking the actual method.

2.7 Server Dynamic Loading

Before handling requests, the server must start. Like Tomcat, the server acts as a container that can dynamically load any project. KRPC uses URLClassLoader to load JARs from a specified directory, allowing business services to be added at runtime.

3. Summary

An RPC framework generally requires knowledge of dynamic proxy, serialization, network request/response (implemented with Netty), dynamic loading, and reflection. Numerous open‑source and proprietary RPC frameworks exist, but mastering the underlying principles—best achieved by reading source code and building your own implementation—provides a lasting advantage.