RPC-Java and the case for rebuilding an RPC framework in six steps

Six versions, one directory each, and a deliberate order

The repository layout is the clearest description of the project. There are six directories, version1/ through version6/, alongside a README.assets/ directory holding the images and a project description file.

Each version adds a specific layer of capability, and the order is the point. The project states plainly that it does not try to build a complete RPC framework in one go, but instead walks through four implementation versions to progressively improve it, and the list of six is the final state of that idea.

Version one implements the simplest RPC that can actually be used. Version two adds a Netty custom encoder, a decoder and a serializer, and creates a cache. Version three adds load balancing, timeout and retry, and a whitelist. Version four adds service-side rate limiting and circuit breaking.

The progression is pedagogically deliberate. A protocol is nearly useless without a codec, a codec is nearly useless without a cache, a cache is nearly useless without a balancer deciding which instance to talk to, and a balancer with no retry and no circuit breaker will happily take a service down. Each version is a self-contained step that a reader can run and understand before the next one arrives.

The primary language is Java, and the project carries no recorded licence.

What version five and version six add on top

The last two versions are where the framework stops being a demo.

Version five adds more serialization options, a configuration layer, and an SPI mechanism. The SPI point matters more than it sounds: it is the extension point that lets the codec, the load balancer or the registry be swapped without touching the core, which is the design that separates a framework from a hard-coded implementation. The version also added a written comparison of established RPC frameworks and their strengths and weaknesses, with documentation links and source links, covering gRPC and Dubbo among others. The stated reason for that comparison is to learn mature design ideas and understand the core patterns and technical difficulties, and through comparing performance, extensibility and applicable scenarios, to help pick a better option and avoid reinventing what already exists.

Version six is the current one, and it changes three things. It implements distributed log tracing with Zipkin integrated for visualisation. It improves graceful shutdown, with Netty gaining heartbeat detection so channel resources are maintained dynamically. And it refines the retry granularity, moving it from the interface level down to the method level, and uses annotations to implement whitelist registration.

The retry refinement is a good example of the kind of detail a real framework needs and a tutorial usually skips. Retrying a whole interface when one method is flaky is wrong, and the annotation-driven whitelist replaces what would otherwise be a configuration file listing endpoints.

The technology choices are the standard ones, deliberately

The stated technology stack lists the components the framework is built from, and the list is a sensible inventory of what a Java RPC framework needs.

Data serialization uses fastjson and protobuf among other mainstream options, and version five widened that set. The network framework is Netty, and the distributed coordination uses ZooKeeper, which is the classic answer for service registration and discovery. On top of those sit implementations of load balancing algorithms and of rate limiting algorithms, plus the use of retry tasks and scheduled tasks in the project scenario.

The framing around RPC itself is worth stating because it explains why the project exists. As business upgrades and system scale grows, a monolithic architecture produces more and more problems, and microservices are introduced to decouple the original architecture into separate modules. Placing each service module on a different server keeps the system working under high concurrency. How those service modules call each other is where the idea of the RPC protocol, remote procedure call, comes in.

The three reasons given for needing RPC are service-oriented architecture with cross-platform remote calls, distributed system architectures where services call each other across machines, and building reusable capability services that several services can call remotely. The fourth case, stated in full, is the concrete one: application a on server A needs a method from application b on server B, the two are not in the same memory space, so the call semantics and the data have to be expressed and transmitted over the network.

The wider set of options the project points at

The project situates itself among the existing options, and the categorisation it uses is the standard one.

Application-level service frameworks include Alibaba's Dubbo and Dubbox, Google gRPC, and Spring Boot with Spring Cloud. Remote communication protocols include RMI, Socket, SOAP over HTTP with XML, and REST over HTTP with JSON. And the communication frameworks underneath are MINA and Netty.

Separating those three layers is the point of the list, because a project like this is mostly about deciding which layer to write and which to borrow. Building your own RPC protocol is mostly a matter of choosing a wire format, a codec, a discovery mechanism and a set of resilience behaviours, and the project writes all of those, which is why it can talk about them concretely rather than in the abstract.

The project's own documentation also notes that many readers find getting a project running to be the first real difficulty, which is a candid admission that a tutorial that does not run is not much of a tutorial. The build prerequisites are documented separately in the project guide, and the requirement list runs from basic Java and networking knowledge up to understanding of concurrency, which is roughly the right floor for what the code does.

What is actually in the repository, and what is behind the membership

This is the practical point for anyone considering the project, because the repository and the course are not the same thing.

The repository holds the six version directories, the project description and its images. The detailed commentary is not there. The project guide states that this project is currently only answered and maintained inside the paid knowledge planet membership, that the project column is shared only there, and that the document itself is exclusive to members.

The column covers the reference resume writing for the project, with the public versions redacted so that the same wording does not appear in many places. It also covers the common interview questions for the project, grouped and updated as they come in, plus scenario questions based on this project's context, and the claim is that mastering the column's interview questions means the project raises no further concerns in an interview.

What is in the open repository is therefore the code and the outline of what each version adds. The reasoning, the diagrams and the interview preparation are not. For a reader who wants to run the code and read it, that is enough. For a reader who wants the guided explanation of why version three does what it does, the guide is where to look, and the guide is paid.

The contact route is a Telegram discussion group listed in the project summary, and the membership site is linked from several places in the documentation.

Where RPC-Java is the wrong choice

The first case is production use. This is a progression of six teaching examples, and a teaching example makes different trade-offs than a library does, such as hard-coding the parts that a real framework would make configurable, or leaving out the failure modes that only appear under real traffic. The repository itself frames it as a learning project, and the comparison with gRPC and Dubbo is presented as something to learn from rather than to replace.

The second is the maintenance reality. The project has no GitHub releases, no recorded licence and no homepage, and the last push to the repository was on 2026-04-07. Even if the code is good, a project with a single maintainer whose primary commitment is to a course community will move at the pace of the course, and the recorded licence is genuinely unclear, which matters if you intend to copy code out of it into a commercial codebase.

The third is anyone who needs a specific capability rather than the education. If what you want is gRPC with tracing, you want gRPC. The value of this project is that it shows you the parts in an order that makes them legible, and that value is realised by working through it, not by adopting the artifact.

The fourth is a team already fluent in these patterns. A distributed systems team will read the six versions and find the work familiar, and the specialised value of a Chinese-language course with interview-focused framing will not apply to them.

Editorial conclusion

RPC-Java suits a Java developer who wants to understand what sits between a method call and a network request, because the six-version structure shows each capability arriving in isolation, with a directory per version so you can read one at a time. It does not suit a team that needs a production RPC framework, since the project is explicitly a teaching progression maintained as course material rather than a supported library, and its licence is not recorded. Before you rely on it, check what the version directories actually contain against the feature list, because the detailed walkthrough of each version is not in the repository, and note that the last push was on 2026-04-07.

Frequently asked questions

Official sources

1. Issues
2. README
3. youngyangyang04/RPC-Java on GitHub