Designing a Scalable RPC Framework: Architecture and Extensibility

1 RPC Architecture

Remote Procedure Call (RPC) converts intercepted method arguments into a binary format that can travel over the network and guarantees that the service provider can faithfully reconstruct the original semantics, achieving remote invocation that feels like a local call.

The transport layer typically uses TCP for reliability and encapsulates a dedicated module to send and receive binary data. Before transmission, method arguments are serialized into binary, then wrapped with delimiter symbols to separate distinct requests—this constitutes the protocol module. Optional compression can be applied when the binary payload exceeds a threshold, allowing lossless compression on the sender side and decompression on the receiver side.

These transport and protocol modules form the foundation of RPC, but developers still need glue code to bind them together. A Bootstrap module can expose the RPC interface as a Spring Bean, allowing Spring’s BeanFactory to manage it and enabling dependency injection throughout the application.

A simple point‑to‑point RPC implementation works for single‑machine scenarios without clustering. To support clusters, the framework must provide service discovery (mapping interfaces to multiple provider addresses) and a connection manager that maintains TCP connection states, since connections can change rapidly.

Clustered deployments also require governance features such as provider weighting, call authorization, and load‑balancing logic that selects an appropriate connection before each request.

2 Extensible Architecture

To make the RPC framework plugin‑friendly, each functional point is abstracted as an interface that serves as a contract. Implementations are separated from the contract, and a default implementation is provided.

Java’s built‑in Service Provider Interface (SPI) can locate implementations at runtime by placing a file named after the service interface in META-INF/services. However, SPI has notable drawbacks:

It cannot load implementations on demand; ServiceLoader eagerly loads and instantiates all providers, wasting resources.

Dependencies between extensions are not automatically injected, making integration with frameworks like Spring difficult.

By adding a plugin system, the RPC framework evolves into a micro‑kernel architecture where core functionality remains lightweight and external features are added as plugins. This design follows the open‑closed principle, allowing users to extend capabilities without modifying core code and reducing dependency conflicts.

3 Summary

Software architecture must balance functional correctness with maintainability and cost. A well‑designed RPC framework abstracts transport, protocol, discovery, and governance while exposing a clean, Spring‑compatible entry point, enabling developers to focus on business logic.

Beyond functional design, extensibility is crucial. A micro‑kernel with plugin contracts ensures the system can evolve with changing business needs without incurring version‑conflict risks.

4 FAQ

① How to perform load testing? Use JMeter with a custom sampler JAR placed in lib\ext and start JMeter to see the sampler.

② What are the limitations of JDK SPI? It lacks on‑demand loading and cannot inject Spring beans, making integration cumbersome.

③ Why might an interface have many implementations? Because ServiceLoader iterates over all providers, requiring type checks to find the desired one.

④ How can a plugin model help in IoT device data collection? By treating each device type as a plugin (driver), the core product remains unchanged while supporting diverse hardware.