XXL-RPC is a Java RPC framework with built-in service governance

What the framework is for

XXL-RPC is described as a RPC service development framework that provides a stable and high performance RPC function, with features such as high performance, distributed, service registry, load balancing and service governance, and the README says it is now open source and genuinely out-of-the-box.

The author is xuxueli, and the homepage is xuxueli.com/xxl-rpc, where the documentation lives. The documentation link in the README is the Chinese version, and the project ships an English summary of the feature list alongside the Chinese original, so both audiences are addressed even if the full documentation is Chinese.

This sits in a well populated part of the Java ecosystem. The project list behind the naming is the xxl family, the job scheduler being the better known sibling, and the topics confirm the lineage: distributed, hessian, netty, rpc, rpc-framework, rpc-library and rpc-service. The name XXL-RPC itself, with the RPC in the name rather than the feature, tells you the intended scope is the transport and the calling convention.

The core module is published on Maven Central under the coordinate com.xuxueli/xxl-rpc-core, and the release history is regular enough to be usable in a build: 2.2.1 from 2026-06-13, 2.2.0 from 2025-12-20 and 2.1.0 from 2025-10-18. The last push to the repository was on 2026-06-13, the repository is not archived, and the licence is Apache 2.0 with copyright 2015-present, xuxueli.

The thirteen features, and where the real content sits

The feature list is the substance of the README, and it is worth reading in full because the items are not all at the same level of abstraction.

The first two are about usability. The framework integrates with Spring Boot so that you can get going in three minutes, and the service is transparent: the framework wraps the underlying communication details, so calling a remote service looks like calling a local one, without losing the semantic simplicity of the local call.

Then the protocol surface. There are multiple invocation types, including SYNC, ONEYAY, FUTURE and CALLBACK, and multiple communication protocols, supporting TCP and HTTP. There are multiple serialization schemes, including JSONB, HESSIAN2, Gson, PROTOSTUFF and KRYO. A list like that is really a statement about interchange, because the serialization choice is the one thing that determines whether two services written at different times can talk.

The middle group is the operational part. The built-in service registry supports dynamic service discovery as a lightweight, all-in-one solution, and it can also be extended to integrate other registries, or used with no registry at all by directly specifying the provider's machine address. Load balancing supports several strategies: round robin, random, LRU, LFU and consistent hashing. Service governance provides online management of registered service information, such as locking a service or disabling an IP. Fault tolerance automatically inspects online services and removes faulty nodes, with consumers sensing the invalid nodes in real time and distributing the traffic to the remaining ones.

Two items are worth pulling out as limitations rather than features. Service monitoring, which covers online monitoring of call statistics and service health, is marked as planned rather than shipped. And the compatibility claim is deliberately broad: thanks to the modular design, the technology stack is not restricted, so apart from the spring and springboot stacks it theoretically runs in any Java code, even started directly from a main method.

The last two are about the calling side. Generalised invocation lets a caller invoke a service directly without depending on an API provided by the service owner, and service security supports a serialization safe space mechanism along with a communication token encryption mechanism.

Getting XXL-RPC and finding a first example

There is no install script to copy here, because the framework is a set of Maven artifacts rather than a program, and the README does not give a build command. The README points at the Maven Central listing for com.xuxueli/xxl-rpc-core, so the artifact to declare in a pom.xml is that coordinate, and the project home page is the place to find the configuration details.

The first thing to read after the README is the samples module, xxl-rpc-samples/, because the documentation link in the README is the Chinese version and the working examples are the language-neutral entry point. The samples show the practical choices the feature list names: which invocation type to use, which serialisation to pick, and how a provider registers and a consumer looks it up.

The provider side is the part that has to be right first, because the consumer side is what looks simple. A provider registers its service address with the registry, and a consumer resolves the name to a list of instances and lets the load balancing strategy choose. A direct address call bypasses the registry entirely, which is the quickest way to see the framework work before wiring in discovery.

The three governance controls are available at runtime rather than at build time, so they are worth trying in a test environment before relying on them. Locking a service or disabling an IP is what you would reach for during a bad deploy, and the fault tolerance inspection is the piece that removes a node from rotation without anyone editing a configuration file.

The module layout, and what a Netty dependency implies

The repository has a small number of top level entries, and the split is what tells you the dependency shape of the framework.

There is xxl-rpc-core/, xxl-rpc-netty-shade/ and xxl-rpc-samples/, alongside pom.xml, doc/ and the usual repository files. The core module is the framework itself and the one published to Maven Central as com.xuxueli/xxl-rpc-core.

The netty module is named shade, and that word carries a specific meaning in the Java ecosystem. Shading means relocating the bundled dependencies under a new package name so that the versions inside the artifact cannot clash with the versions on the application's classpath. For an RPC framework that bundles Netty, this is not a detail: Netty is the kind of library where two versions in one JVM cause failures that are very hard to trace, and shading is how a framework avoids being the reason a user's build breaks. The core module depending on a shaded Netty artifact is a deliberate design decision, and it also means the framework is not compatible with an application that already uses Netty directly in a conflicting way, which is rare but worth knowing.

The samples module is where the working examples live, and for a framework whose documentation is in Chinese, the samples are the more accessible entry point for an English speaker.

There is a doc/ directory for the documentation sources, and the CI badge points at a Java CI workflow, so the build is Maven and the checks run on every push.

Registry, discovery and the option of no registry at all

The registry design is the decision that determines how much of the framework you actually take, so it deserves a closer look.

There are three ways to use it. The built-in registry is a lightweight, all-in-one option that supports dynamic service discovery. The framework can be extended to integrate other registries, which is the path for a team that already runs one, since the discovery interface is the seam. And the third option is to use no registry at all and call the provider's machine address directly.

That third option is the one that gets underestimated. A framework that lets you skip the registry entirely is usable in a two-service system, in a test, or in a deployment where the provider address is fixed by configuration, and it means the registry is not a mandatory runtime dependency. It also means the discovery and the load balancing layers are optional rather than always on.

The load balancing strategies follow the same pragmatic design. Round robin and random are the obvious ones, LRU and LFU are the cache-aware ones, and consistent hashing is the one that matters when a service has state that must stay on a particular node. All of them sit behind the registry abstraction, so a direct address call has no balancing to apply.

The fault tolerance feature completes the picture. The framework automatically inspects the online services and removes faulty nodes, and the consumer senses the invalid nodes in real time and moves the traffic to the remaining nodes. In combination with the governance controls, that is a closed loop: register, discover, balance, exclude, and recover.

Where XXL-RPC fits, and where it stops

The comparison worth making is with the two obvious alternatives, and with doing nothing.

Against gRPC, the difference is the ecosystem rather than the protocol. gRPC gives you a multi-language contract generated from a proto file, HTTP/2 multiplexing and a strong story on streaming, and it asks you to run a proxy or a sidecar for load balancing in most production topologies. XXL-RPC is a Java library with a registry built in, a Spring integration path, and a serialisation choice that includes Hessian and Protobuf-compatible schemes. If your estate is Java-only and you want the operational pieces in one dependency, that is a reasonable trade. If any part of your estate is not Java, gRPC's cross-language story is the deciding factor.

Against Dubbo, the comparison is closer, since both target the same Chinese enterprise Java market with a registry, load balancing and governance. The difference is that Dubbo is a much larger framework with a much larger surface area, while XXL-RPC is smaller and describes itself as lightweight.

Against doing nothing, the case for a framework is strongest when the services involved change address, when the number of instances varies, or when you need to exclude a failing node without redeploying. With a fixed set of addresses and no failures, a plain HTTP client is less to maintain.

The limits are visible in the record and in the README itself. The service monitoring item, covering call statistics and health monitoring, is marked as planned rather than implemented, so the observability story is the weakest part of the feature list, and a team that wants live call dashboards will not find them here. The documentation is Chinese, with the README's English section being a summary rather than a manual, so an English-speaking team will be reading samples and source. The list of supported serialisations is broad but the interaction between a given scheme and a given RPC invocation type is exactly the kind of matrix that only the source or the Chinese documentation answers.

The maintenance picture is steady rather than fast. Three releases across nine months, the last one in June 2026, a repository that is not archived, and an Apache 2.0 licence with no copyleft obligation on the applications that embed it.

Editorial conclusion

XXL-RPC suits a Java team that wants an RPC layer with a registry, load balancing and fault tolerance in one dependency rather than assembling those pieces separately, since the built-in registry and the governance controls are the reason to pick it over a bare serialization library. It is the wrong tool if you already run gRPC or Dubbo and have no reason to add a second stack, and it is the wrong tool if you need features the README marks as planned, such as online monitoring of call statistics and service health. Before adopting it, read the feature list against what you actually need, because several of the thirteen items are Java and Spring specific while the rest are protocol level, and check whether the built-in registry is what you want or whether you will point it at an external one.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. xuxueli/xxl-rpc on GitHub