Seata RPC 模块的重构之路

简介：RPC 模块是我最初研究 Seata 源码开始的地方，因此我对 Seata 的 RPC 模块有过一些深刻研究，在我研究了一番后，发现 RPC 模块中的代码需要进行优化，使得代码更加优雅，交互逻辑更加清晰易懂，本着 “让天下没有难懂的 RPC 通信代码” 的初衷，我开始了 RPC 模块的重构之路。

作者 | 张乘辉
来源|阿里巴巴云原生公众号

RPC 模块是我最初研究 Seata 源码开始的地方，因此我对 Seata 的 RPC 模块有过一些深刻研究，在我研究了一番后，发现 RPC 模块中的代码需要进行优化，使得代码更加优雅，交互逻辑更加清晰易懂，本着 “让天下没有难懂的 RPC 通信代码” 的初衷，我开始了 RPC 模块的重构之路。

这里建议想要深入了解 Seata 交互细节的，不妨从 RPC 模块的源码入手，RPC 模块相当于 Seata 的中枢，Seata 所有的交互逻辑在 RPC 模块中表现得淋漓尽致。

这次 RPC 模块的重构将会使得 Seata 的中枢变得更加健壮和易于解读。

重构继承关系

在 Seata 的旧版本中，RPC 模块的整体结构有点混乱，尤其是在各个类的继承关系上，主要体现在：

1. 直接在 Remoting 类继承 Netty Handler，使得 Remoting 类与 Netty Handler 处理逻辑耦合在一起。
2. 客户端和服务端的 Reomting 类继承关系不统一。
3. RemotingClient 被 RpcClientBootstrap 实现，而 RemotingServer 却被 RpcServer 实现，没有一个独立的 ServerBootstrap，这个看起来关系非常混乱。
4. 有些接口没必要抽取出来，比如 ClientMessageSender、ClientMessageListener、ServerMessageSender 等接口，因这些接口会增加整体结构继承关系的复杂性。

针对上面发现的问题，在重构过程中我大致做了如下事情：

1. 将  Netty Handler 抽象成一个内部类放在 Remoting 类中。
2. 将 RemotingClient 为客户端顶级接口，定义客户端与服务端交互的基本方法，抽象一层 AbstractNettyRemotingClient，下面分别有 RmNettyRemotingClient、TmNettyRemotingClient；将 RemotingServer 为服务端顶级接口，定义服务端与客户端交互的基本方法，实现类 NettyRemotingServer。
3. 同时将 ClientMessageSender、ClientMessageListener、ServerMessageSender 等接口方法归入到 RemotingClient、RemotingServer 中，由 Reomting 类实现 RemotingClient、RemotingServer，统一 Remoting 类继承关系。
4. 新建 RemotingBootstrap 接口，客户端和服务端分别实现 Net