NettyRpc: annotation-registered services, a ZooKeeper address and no documented wire format

A service is one annotated class and a version string

Registration in NettyRpc starts from an ordinary Java interface. The README defines HelloService with two overloads of hello, one taking a String and one taking a Person. The implementation class carries the annotation @NettyRpcService(HelloService.class, version = "1.0"), and that annotation is the whole registration step. There is no separate registry call in the example.

The interface and the version together form the identity of a service. A client asks for HelloService at version 1.0 and gets whatever server registered that pair. Running two versions side by side is what the feature line about different versions of service refers to.

The README example implementation is deliberately tiny. hello(String name) returns "Hello " plus the name, and hello(Person person) joins getFirstName() and getLastName(). Nothing in it shows a checked exception, a timeout or a return type other than String, so the examples say nothing about how those cases behave.

public interface HelloService {
    String hello(String name);
    String hello(Person person);
}

ZooKeeper has to be running before anything else starts

Step three of the README is to run ZooKeeper, with 127.0.0.1:2181 given as the example address. Service discovery depends on it. The feature list names ZooKeeper as the registry and discovery mechanism, and the client constructor takes the same address string, so server and client both need to reach the ensemble.

This makes ZooKeeper a hard prerequisite, not an optional add-on. A developer who wants to try the project in ten minutes still has to stand up a ZooKeeper instance first, and the README gives no instructions for that. It also does not say what a client does when ZooKeeper is unreachable at startup or goes away later.

The feature list claims high availability, load balance and failover, and it says different load balance strategies are supported. The README does not name any strategy, so you cannot tell from it whether the choices are round robin, random or something else. That detail sits in the code of the netty-rpc-client module, not in the documentation.

Two bootstrap classes decide whether Spring is in the picture

The test module netty-rpc-test ships two ways to start a server. RpcServerBootstrap starts it with a Spring config. RpcServerBootstrap2 starts it without one. Both are listed in step four, and the README does not explain what differs beyond the Spring dependency.

The project description says the framework is based on Netty, ZooKeeper and Spring, yet the second bootstrap shows that Spring is not strictly required to run a server. What Spring contributes in the first path is presumably wiring of the annotated service beans, but the README does not spell that out, so verify it in the pom.xml and the server module before relying on it.

The repository is split into modules: netty-rpc-common, netty-rpc-server, netty-rpc-client and netty-rpc-test, tied together by a root pom.xml. That layout lets a client application depend on the client and common modules without pulling in the server. Whether the modules are published to Maven Central is not stated, and the repository has no GitHub releases, so the practical route is cloning the source and building it.

The client offers a synchronous proxy and a future-based call

A client is created with new RpcClient("127.0.0.1:2181"), pointing at ZooKeeper rather than at a server host. From it, createService(HelloService.class, "1.0") returns a proxy that behaves like the interface, so helloService.hello("World") reads like a local call.

The asynchronous path is different in shape. createAsyncService(HelloService.class, "2.0") returns an RpcService, and client.call("hello", "World") returns an RPCFuture. The method is addressed by its name as a string, which gives up compile-time checking, and the result is fetched with helloFuture.get(3000, TimeUnit.MILLISECONDS), cast to String. The 3000 millisecond limit in the example is the only timeout the README shows.

final RpcClient rpcClient = new RpcClient("127.0.0.1:2181");

// Sync call
HelloService helloService = rpcClient.createService(HelloService.class, "1.0");
String result = helloService.hello("World");

Note that the async example asks for version 2.0 while the only implementation shown is registered as 1.0. The README never shows a 2.0 implementation, so as written that call would not find a matching service. Treat it as an illustration of the API, not a runnable pair.

RpcAutowired injects remote proxies into Spring fields

The second client style uses the annotation @RpcAutowired. In the README example, the class Baz implements Foo and declares two private fields of type HelloService. One is annotated @RpcAutowired(version = "1.0") and the other @RpcAutowired(version = "2.0"). The say method simply returns helloService1.hello(s).

This is the Spring-flavored route: the remote service is injected like any other dependency, with the version chosen per field. Having two fields for two versions in one class shows how a caller can talk to both versions at once, which is the practical use of the version attribute.

The README does not say which Spring configuration makes @RpcAutowired work, what happens when the requested version has no registered provider, or whether the injection fails at startup or at first call. Those are the questions to answer by reading the client module before using the annotation in an application that must start cleanly.

Serialization and heartbeat are claimed, not configured

Two items on the feature list concern the wire. The framework supports different serializer and deserializer implementations, and it detects dead TCP connections with a heartbeat. The README gives no configuration key, class name or option for either one.

That gap has consequences. If you need to exchange types beyond String and Person, the README does not tell you how to choose a serializer, which ones exist, or whether both ends must agree on the choice. If you run behind a firewall that drops idle connections, it does not tell you the heartbeat interval or how many missed beats close a connection.

The Design heading in the README is present and empty. There is no architecture description in the document at all, only a link to a Chinese article on cnblogs.com for details. Readers who cannot read Chinese are left with the source code as their design document.

Last push in October 2026, with no releases and no stated license

The repository was last pushed on 2026-10-09, so it has seen recent activity, but there are no GitHub releases to pin a version against. License information is absent from the repository metadata, which matters if you plan to copy code into a product.

The feature list opens with simple code and framework, and the module layout supports that claim: four small modules and a single README with one tutorial. The cost of that simplicity is documentation. There is no description of the protocol, no list of serializers, no failure behavior and no security notes, such as authentication between client and server.

The tutorial lives in netty-rpc-test, which is where to start if you want a running example. Build the modules with the root pom.xml, start ZooKeeper, run one of the two server bootstrap classes, and then execute the client code from the README.

Editorial conclusion

Use NettyRpc as a readable reference for how annotation-based RPC with ZooKeeper discovery fits together, or as a base for an internal experiment. Do not pick it for production traffic on the strength of the README alone: it has no releases, no stated license, an empty Design section and no documentation of timeouts, retries or security. Before committing, read the netty-rpc-server and netty-rpc-client modules and confirm that the load balance and failover behavior the feature list claims is what you need.

Frequently asked questions

Official sources

1. Issues
2. luxiaoxun/NettyRpc on GitHub
3. README