Seata 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 接口，客戶端和服務端分別實現 NettyClientBootstrap、NettyServerBootstrap，將引導類邏輯從 Reomting 類抽離出來。

在最新的 RPC 模塊中的繼承關係簡單清晰，用以下類關係圖表示：

1. AbstractNettyRemoting：Remoting 類的最頂層抽象，包含了客戶端和服務端公用的成員變量與公用方法，擁有通用的請求方法（文章後面會講到），Processor 處理器調用邏輯（文章後面會講到）。
2. RemotingClient：客戶端最頂級接口，定義客戶端與服務端交互的基本方法。
3. RemotingServer：服務端最頂級接口，定義服務端與客戶端交互的基本方法。
4. AbstractNettyRemotingClient：客戶端抽象類，繼承 AbstractNettyRemoting 類並實現了 RemotingClient 接口。
5. NettyRemotingServer：服務端實現類，繼承 AbstractNettyRemoting 類並實現了 RemotingServer 接口。
6. RmNettyRemotingClient：Rm 客戶端實現類，繼承 AbstractNettyRemotingClient 類。
7. TmNettyRemotingClient：Tm 客戶端實現類，繼承 AbstractNettyRemotingClient 類。

同時將客戶端和服務端的引導類邏輯抽象出來，以下類關係圖表示：

1. RemotingBootstrap：引導類接口，有 start 和 stop 兩個抽象方法。
2. NettyClientBootstrap：客戶端引導實現類。
3. NettyServerBootstrap：服務端引導實現類。

解耦處理邏輯

解耦處理邏輯便是將 RPC 交互的處理邏輯從 Netty Handler 中抽離出來，並將處理邏輯抽象成一個個 Processor，爲何要這麼作呢？我大體講下如今存在的一些問題：

1. Netty Handler 與 處理邏輯是糅合在一塊兒的，因爲客戶端與服務端都共用了一套處理邏輯，所以爲了兼容更多的交互，在處理邏輯中你能夠看到很是多難以理解的判斷邏輯。
2. 在 Seata 的交互中有些請求是異步處理的，也有一些請求是同步處理的，可是在舊的處理代碼邏輯中對同步異步處理的表達很是隱晦，並且難以看明白。
3. 沒法從代碼邏輯當中清晰地表達出請求消息類型與對應的處理邏輯關係。
4. 在 Seata 後面的更新迭代中，若是不將處理處理邏輯抽離出來，這部分代碼想要增長新的交互邏輯，將會很是困難。

在將處理邏輯從 Netty Handler 進行抽離以前，咱們先梳理一下 Seata 現有的交互邏輯。

• RM 客戶端請求服務端的交互邏輯：

• TM 客戶端請求服務端的交互邏輯：

• 服務端請求 RM 客戶端的交互邏輯：

從以上的交互圖中能夠清晰地看到了 Seata 的交互邏輯。

客戶端總共接收服務端的消息：

1）服務端請求消息

• BranchCommitRequest、BranchRollbackRequest、UndoLogDeleteRequest

2）服務端響應消息

• RegisterRMResponse、BranchRegisterResponse、BranchReportResponse、GlobalLockQueryResponse
• RegisterTMResponse、GlobalBeginResponse、GlobalCommitResponse、GlobalRollbackResponse、GlobalStatusResponse、GlobalReportResponse
• HeartbeatMessage(PONG)

服務端總共接收客戶端的消息：

1）客戶端請求消息

• RegisterRMRequest、BranchRegisterRequest、BranchReportRequest、GlobalLockQueryRequest
• RegisterTMRequest、GlobalBeginRequest、GlobalCommitRequest、GlobalRollbackRequest、GlobalStatusRequest、GlobalReportRequest
• HeartbeatMessage(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 的請求方法也是欠缺優雅，主要體如今：

1. 請求方法過於雜亂無章，沒有層次感。
2. sendAsyncRequest 方法耦合的代碼太多，邏輯過於混亂，客戶端與服務端都共用了一套請求邏輯，方法中決定是否批量發送是根據參數 address 是否爲 null 決定，決定是否同步請求是根據 timeout 是否大於 0 決定，顯得極爲不合理，且批量請求只有客戶端有用到，服務端並無批量請求，共用一套請求邏輯還會致使服務端異步請求也會建立 MessageFuture 放入 futures 中。
3. 請求方法名稱風格不統一，好比客戶端 sendMsgWithResponse，服務端卻叫 sendSyncRequest；

針對以上舊版本 RPC 請求方法的各類缺點，我做了如下改動：

1. 將請求方法統一放入 RemotingClient、RemotingServer 接口當中，並做爲頂級接口；
2. 分離客戶端與服務端請求邏輯，將批量請求邏輯單獨抽到客戶端相關請求方法中，使得是否批量發送再也不根據參數 address 是否爲 null 決定；
3. 因爲 Seata 自身的邏輯特色，客戶端服務端請求方法的參數沒法統一，可經過抽取通用的同步/異步請求方法，客戶端和服務端根據自身請求邏輯特色實現自身的同步/異步請求邏輯，最後再調用通用的同步/異步請求方法，使得同步/異步請求都有明確的方法，再也不根據 timeout 是否大於 0 決定；
4. 統一請求名稱風格。

最終，Seata RPC 的請求方法終於看起來更加優雅且有層次感了。

同步請求：

異步請求：

其它

1. 類目錄調整：RPC 模塊目錄中還有一個 netty 目錄，也能夠從目錄結構中發現 Seata 的初衷是兼容多個 RPC 框架，目前只實現了 netty，但發現 netty 模塊中有些類並不 」netty「，且 RPC 跟目錄的類也並不通用，所以須要將相關類的位置進行調整。
2. 某些類從新命名，好比 netty 相關類包含 「netty」。

最終 RPC 模塊看起來是這樣的：

更多詳情可訪問 Seata 官網進行了解。