How Refactoring Seata’s RPC Module Simplifies Communication Logic

The author, who began exploring Seata by studying its RPC module, identified several structural issues in the old implementation that made the code hard to understand and maintain. The RPC module acts as Seata's core, handling all inter‑process communication, so improving it enhances the overall robustness of the system.

Problems in the Original RPC Module

Remoting class directly inherited Netty Handler, tightly coupling communication logic.

Inconsistent inheritance between client and server Remoting classes.

RemotingClient was implemented by RpcClientBootstrap while RemotingServer used RpcServer, lacking a unified ServerBootstrap.

Unnecessary interfaces such as ClientMessageSender, ClientMessageListener, ServerMessageSender added complexity.

Refactor Steps

Abstract Netty Handler into an inner class of Remoting.

Define top‑level interfaces RemotingClient and RemotingServer, introduce AbstractNettyRemotingClient, and create concrete implementations RmNettyRemotingClient, TmNettyRemotingClient, and NettyRemotingServer.

Merge previously separate interfaces into RemotingClient and RemotingServer, letting the Remoting class implement both.

Create a new RemotingBootstrap interface with NettyClientBootstrap and NettyServerBootstrap implementations, extracting bootstrap logic from Remoting.

The resulting class diagram shows a clean hierarchy:

AbstractNettyRemoting : top‑level abstraction containing shared fields and methods.

RemotingClient / RemotingServer : top‑level interfaces for client and server interactions.

AbstractNettyRemotingClient : abstract client class implementing RemotingClient.

NettyRemotingServer : server implementation of RemotingServer.

RmNettyRemotingClient and TmNettyRemotingClient : concrete client classes for RM and TM.

Decoupling Processing Logic

Previously, Netty Handler mixed request handling with business logic, leading to tangled conditional code and difficulty distinguishing synchronous from asynchronous processing. The refactor extracts processing into independent Processor classes, each responsible for one or more message types. Processors are registered in a ProcessorTable at startup, enabling dynamic lookup based on message type.

Key processors include:

RmBranchCommitProcessor, RmBranchRollbackProcessor, RmUndoLogProcessor (server‑side RM handling).

ClientOnResponseProcessor, ClientHeartbeatProcessor (client‑side response handling).

RegRmProcessor, RegTmProcessor, ServerOnRequestProcessor, ServerOnResponseProcessor, ServerHeartbeatProcessor (server‑side request handling).

Message flow diagrams illustrate how a TM‑initiated global commit request traverses these processors.

Refactoring Request Methods

The old RPC request methods were chaotic, with a single sendAsyncRequest handling both client and server logic, mixing batch and synchronous decisions based on parameters. The new design:

Moves request methods into the top‑level RemotingClient and RemotingServer interfaces.

Separates batch request logic into client‑specific methods.

Provides distinct synchronous and asynchronous request methods, removing reliance on timeout checks.

Standardizes naming conventions across client and server.

Resulting request flow diagrams show clear, layered synchronous and asynchronous interactions.

Additional Adjustments

Reorganized package directories, moving non‑Netty‑specific classes out of the netty folder.

Renamed several classes to better reflect their purpose.

The final RPC module structure is presented with a comprehensive class diagram, demonstrating a more maintainable and readable codebase.

For further details, refer to the original Seata documentation.