Implementing Dynamic RPC Service Invocation in a Commercial Testing Platform

Background – As the QA team’s testing tools grew, a commercial testing platform was built to improve QA efficiency and support RD self‑testing, but three major issues were discovered: only one RPC service configuration could be loaded, configurations could not be changed in real time per user, and concurrent calls to RPC services on different machines interfered with each other.

The root cause was that the WF site, acting as the testing platform, could not dynamically invoke RPC services on arbitrary machines because the rpcclient could not load different rpc.config files on demand.

Key Technical Concepts – The solution relies on understanding Java class‑loading mechanisms (parent‑first vs. child‑first), handling of duplicate class names within the same classloader, Java dynamic proxies (java.lang.reflect), and ThreadLocal (java.lang.ThreadLocal).

Current Platform Implementation – When creating a product, users manually select the IP of the target RPC service from a dropdown populated via an environment‑platform API. After submitting, the request result and the RPC service IP are displayed in logs and UI.

Dynamic RPC Service Invocation – To enable dynamic loading of multiple rpc.config files, two solutions were implemented.

Solution 1 (Low‑Version rpcclient) – Uses Java dynamic proxies to reflectively generate RPC service calls, parses the default rpc.config to determine service location, and serializes parameters. Changes required include generating new configuration files per selected IP, adding an IP parameter through the call chain (from Class1.create to Class5.get), and packaging modified code into a 1.dynamic.client.jar that is prioritized by the classloader. Drawbacks: extensive code changes, strong dependencies, and high modification effort.

Solution 2 (New‑Version rpcclient) – Modifies the client interaction but still relies on a getConfig() method. Introduces ThreadLocal to store the rpc.config per request, allowing dynamic configuration without major code changes. The interceptor adds the necessary logic, preserving existing code structure.

Advantages of Solution 2 – Enables dynamic rpc.config updates without restarting the WF site, isolates configurations per user, eliminates host file modifications, avoids deploying the platform on each tested machine, makes server information traceable, supports RD self‑testing, lays groundwork for RPC diff and mock capabilities.