建怎样的网站挣钱快,个人快速建站,青岛城乡建设部网站首页,陕西省建设网站 五大员过期简介#xff1a; RPC 模块是我最初研究 Seata 源码开始的地方#xff0c;因此我对 Seata 的 RPC 模块有过一些深刻研究#xff0c;在我研究了一番后#xff0c;发现 RPC 模块中的代码需要进行优化#xff0c;使得代码更加优雅#xff0c;交互逻辑更加清晰易懂#xff0c…简介 RPC 模块是我最初研究 Seata 源码开始的地方因此我对 Seata 的 RPC 模块有过一些深刻研究在我研究了一番后发现 RPC 模块中的代码需要进行优化使得代码更加优雅交互逻辑更加清晰易懂本着 “让天下没有难懂的 RPC 通信代码” 的初衷我开始了 RPC 模块的重构之路。 RPC 模块是我最初研究 Seata 源码开始的地方因此我对 Seata 的 RPC 模块有过一些深刻研究在我研究了一番后发现 RPC 模块中的代码需要进行优化使得代码更加优雅交互逻辑更加清晰易懂本着 “让天下没有难懂的 RPC 通信代码” 的初衷我开始了 RPC 模块的重构之路。
这里建议想要深入了解 Seata 交互细节的不妨从 RPC 模块的源码入手RPC 模块相当于 Seata 的中枢Seata 所有的交互逻辑在 RPC 模块中表现得淋漓尽致。
这次 RPC 模块的重构将会使得 Seata 的中枢变得更加健壮和易于解读。
重构继承关系
在 Seata 的旧版本中RPC 模块的整体结构有点混乱尤其是在各个类的继承关系上主要体现在
直接在 Remoting 类继承 Netty Handler使得 Remoting 类与 Netty Handler 处理逻辑耦合在一起。客户端和服务端的 Reomting 类继承关系不统一。RemotingClient 被 RpcClientBootstrap 实现而 RemotingServer 却被 RpcServer 实现没有一个独立的 ServerBootstrap这个看起来关系非常混乱。有些接口没必要抽取出来比如 ClientMessageSender、ClientMessageListener、ServerMessageSender 等接口因这些接口会增加整体结构继承关系的复杂性。
针对上面发现的问题在重构过程中我大致做了如下事情
将 Netty Handler 抽象成一个内部类放在 Remoting 类中。将 RemotingClient 为客户端顶级接口定义客户端与服务端交互的基本方法抽象一层 AbstractNettyRemotingClient下面分别有 RmNettyRemotingClient、TmNettyRemotingClient将 RemotingServer 为服务端顶级接口定义服务端与客户端交互的基本方法实现类 NettyRemotingServer。同时将 ClientMessageSender、ClientMessageListener、ServerMessageSender 等接口方法归入到 RemotingClient、RemotingServer 中由 Reomting 类实现 RemotingClient、RemotingServer统一 Remoting 类继承关系。新建 RemotingBootstrap 接口客户端和服务端分别实现 NettyClientBootstrap、NettyServerBootstrap将引导类逻辑从 Reomting 类抽离出来。
在最新的 RPC 模块中的继承关系简单清晰用如下类关系图表示 AbstractNettyRemotingRemoting 类的最顶层抽象包含了客户端和服务端公用的成员变量与公用方法拥有通用的请求方法文章后面会讲到Processor 处理器调用逻辑文章后面会讲到。RemotingClient客户端最顶级接口定义客户端与服务端交互的基本方法。RemotingServer服务端最顶级接口定义服务端与客户端交互的基本方法。AbstractNettyRemotingClient客户端抽象类继承 AbstractNettyRemoting 类并实现了 RemotingClient 接口。NettyRemotingServer服务端实现类继承 AbstractNettyRemoting 类并实现了 RemotingServer 接口。RmNettyRemotingClientRm 客户端实现类继承 AbstractNettyRemotingClient 类。TmNettyRemotingClientTm 客户端实现类继承 AbstractNettyRemotingClient 类。
同时将客户端和服务端的引导类逻辑抽象出来如下类关系图表示 RemotingBootstrap引导类接口有 start 和 stop 两个抽象方法。NettyClientBootstrap客户端引导实现类。NettyServerBootstrap服务端引导实现类。
解耦处理逻辑
解耦处理逻辑即是将 RPC 交互的处理逻辑从 Netty Handler 中抽离出来并将处理逻辑抽象成一个个 Processor为什么要这么做呢我大致讲下现在存在的一些问题
Netty Handler 与 处理逻辑是糅合在一起的由于客户端与服务端都共用了一套处理逻辑因此为了兼容更多的交互在处理逻辑中你可以看到非常多难以理解的判断逻辑。在 Seata 的交互中有些请求是异步处理的也有一些请求是同步处理的但是在旧的处理代码逻辑中对同步异步处理的表达非常隐晦而且难以看明白。无法从代码逻辑当中清晰地表达出请求消息类型与对应的处理逻辑关系。在 Seata 后面的更新迭代中如果不将处理处理逻辑抽离出来这部分代码想要增加新的交互逻辑将会非常困难。
在将处理逻辑从 Netty Handler 进行抽离之前我们先梳理一下 Seata 现有的交互逻辑。
RM 客户端请求服务端的交互逻辑TM 客户端请求服务端的交互逻辑服务端请求 RM 客户端的交互逻辑从以上的交互图中可以清晰地看到了 Seata 的交互逻辑。
客户端总共接收服务端的消息
1服务端请求消息
BranchCommitRequest、BranchRollbackRequest、UndoLogDeleteRequest
2服务端响应消息
RegisterRMResponse、BranchRegisterResponse、BranchReportResponse、GlobalLockQueryResponseRegisterTMResponse、GlobalBeginResponse、GlobalCommitResponse、GlobalRollbackResponse、GlobalStatusResponse、GlobalReportResponseHeartbeatMessage(PONG)
服务端总共接收客户端的消息
1客户端请求消息
RegisterRMRequest、BranchRegisterRequest、BranchReportRequest、GlobalLockQueryRequestRegisterTMRequest、GlobalBeginRequest、GlobalCommitRequest、GlobalRollbackRequest、GlobalStatusRequest、GlobalReportRequestHeartbeatMessage(PING)
2客户端响应消息
BranchCommitResponse、BranchRollbackResponse
基于以上的交互逻辑分析我们可以将处理消息的逻辑抽象成若干个 Processor一个 Processor 可以处理一个或者多个消息类型的消息只需在 Seata 启动时注册将消息类型注册到 ProcessorTable 中即可形成一个映射关系这样就可以根据消息类型调用对应的 Processor 对消息进行处理用如下图表示 在抽象 Remoting 类中定一个 processMessage 方法方法逻辑是根据消息类型从 ProcessorTable 中拿到消息类型对应的 Processor。
这样就成功将处理逻辑从 Netty Handler 中彻底抽离出来了Handler#channelRead 方法只需要调用 processMessage 方法即可且还可以灵活根据消息类型动态注册 Processor 到 ProcessorTable 中处理逻辑的可扩展性得到了极大的提升。
以下是 Processor 的调用流程
1客户端 RmBranchCommitProcessor处理服务端全局提交请求。RmBranchRollbackProcessor处理服务端全局回滚请求。RmUndoLogProcessor处理服务端 undo log 删除请求。ClientOnResponseProcessor客户端处理服务端响应请求如BranchRegisterResponse、GlobalBeginResponse、GlobalCommitResponse 等。ClientHeartbeatProcessor处理服务端心跳响应。
2服务端 RegRmProcessor处理 RM 客户端注册请求。RegTmProcessor处理 TM 客户端注册请求。ServerOnRequestProcessor处理客户端相关请求如BranchRegisterRequest、GlobalBeginRequest、GlobalLockQueryRequest 等。ServerOnResponseProcessor处理客户端相关响应如BranchCommitResponse、BranchRollbackResponse 等。ServerHeartbeatProcessor处理客户端心跳响应。
下面我以 TM 发起全局事务提交请求为例子让大家感受下 Processor 在整个交互中所处的位置 重构请求方法
在 Seata 的旧版本当中RPC 的请求方法也是欠缺优雅主要体现在
请求方法过于杂乱无章没有层次感。sendAsyncRequest 方法耦合的代码太多逻辑过于混乱客户端与服务端都共用了一套请求逻辑方法中决定是否批量发送是根据参数 address 是否为 null 决定决定是否同步请求是根据 timeout 是否大于 0 决定显得极为不合理且批量请求只有客户端有用到服务端并没有批量请求共用一套请求逻辑还会导致服务端异步请求也会创建 MessageFuture 放入 futures 中。请求方法名称风格不统一比如客户端 sendMsgWithResponse服务端却叫 sendSyncRequest
针对以上旧版本 RPC 请求方法的各种缺点我作了以下改动
将请求方法统一放入 RemotingClient、RemotingServer 接口当中并作为顶级接口分离客户端与服务端请求逻辑将批量请求逻辑单独抽到客户端相关请求方法中使得是否批量发送不再根据参数 address 是否为 null 决定由于 Seata 自身的逻辑特点客户端服务端请求方法的参数无法统一可通过抽取通用的同步/异步请求方法客户端和服务端根据自身请求逻辑特点实现自身的同步/异步请求逻辑最后再调用通用的同步/异步请求方法使得同步/异步请求都有明确的方法不再根据 timeout 是否大于 0 决定统一请求名称风格。
最终Seata RPC 的请求方法终于看起来更加优雅且有层次感了。
同步请求 异步请求 其它
类目录调整RPC 模块目录中还有一个 netty 目录也可以从目录结构中发现 Seata 的初衷是兼容多个 RPC 框架目前只实现了 netty但发现 netty 模块中有些类并不 ”netty“且 RPC 跟目录的类也并不通用因此需要将相关类的位置进行调整。某些类重新命名比如 netty 相关类包含 「netty」。
最终 RPC 模块看起来是这样的 作者张乘辉
原文链接
本文为阿里云原创内容未经允许不得转载
