如何手擼一個較為完整的RPC框架？

2022-03-01 11:38:51

最近在公司分享了手擼RPC，因此做一個總結(jié)。一起來看一下吧。

概念篇

RPC 是什么？

RPC 稱遠程過程調(diào)用（Remote Procedure Call），用于解決分布式系統(tǒng)中服務(wù)之間的調(diào)用問題。通俗地講，就是開發(fā)者能夠像調(diào)用本地方法一樣調(diào)用遠程的服務(wù)。所以，RPC的作用主要體現(xiàn)在這兩個方面：

屏蔽遠程調(diào)用跟本地調(diào)用的區(qū)別，讓我們感覺就是調(diào)用項目內(nèi)的方法；
隱藏底層網(wǎng)絡(luò)通信的復(fù)雜性，讓我們更專注于業(yè)務(wù)邏輯。

RPC 框架基本架構(gòu)

下面我們通過一幅圖來說說 RPC 框架的基本架構(gòu)

RPC 框架包含三個最重要的組件，分別是客戶端、服務(wù)端和注冊中心。在一次 RPC 調(diào)用流程中，這三個組件是這樣交互的：

服務(wù)端在啟動后，會將它提供的服務(wù)列表發(fā)布到注冊中心，客戶端向注冊中心訂閱服務(wù)地址；
客戶端會通過本地代理模塊 Proxy 調(diào)用服務(wù)端，Proxy 模塊收到負責(zé)將方法、參數(shù)等數(shù)據(jù)轉(zhuǎn)化成網(wǎng)絡(luò)字節(jié)流；
客戶端從服務(wù)列表中選取其中一個的服務(wù)地址，并將數(shù)據(jù)通過網(wǎng)絡(luò)發(fā)送給服務(wù)端；
服務(wù)端接收到數(shù)據(jù)后進行解碼，得到請求信息；
服務(wù)端根據(jù)解碼后的請求信息調(diào)用對應(yīng)的服務(wù)，然后將調(diào)用結(jié)果返回給客戶端。

RPC 框架通信流程以及涉及到的角色

從上面這張圖中，可以看見 RPC 框架一般有這些組件：服務(wù)治理(注冊發(fā)現(xiàn))、負載均衡、容錯、序列化/反序列化、編解碼、網(wǎng)絡(luò)傳輸、線程池、動態(tài)代理等角色，當然有的RPC框架還會有連接池、日志、安全等角色。

具體調(diào)用過程

服務(wù)消費方(client)以本地調(diào)用方式調(diào)用服務(wù)
client stub 接收到調(diào)用后負責(zé)將方法、參數(shù)等封裝成能夠進行網(wǎng)絡(luò)傳輸?shù)南Ⅲw
client stub 將消息進行編碼并發(fā)送到服務(wù)端
server stub 收到消息后進行解碼
server stub 根據(jù)解碼結(jié)果調(diào)用本地的服務(wù)
本地服務(wù)執(zhí)行并將結(jié)果返回給 server stub
server stub 將返回導(dǎo)入結(jié)果進行編碼并發(fā)送至消費方
client stub 接收到消息并進行解碼
服務(wù)消費方(client)得到結(jié)果

RPC 消息協(xié)議

RPC調(diào)用過程中需要將參數(shù)編組為消息進行發(fā)送，接收方需要解組消息為參數(shù)，過程處理結(jié)果同樣需要經(jīng)編組、解組。消息由哪些部分構(gòu)成及消息的表示形式就構(gòu)成了消息協(xié)議。

RPC調(diào)用過程中采用的消息協(xié)議稱為RPC消息協(xié)議。

實戰(zhàn)篇

從上面的概念我們知道一個RPC框架大概有哪些部分組成，所以在設(shè)計一個RPC框架也需要從這些組成部分考慮。從RPC的定義中可以知道，RPC框架需要屏蔽底層細節(jié)，讓用戶感覺調(diào)用遠程服務(wù)像調(diào)用本地方法一樣簡單，所以需要考慮這些問題：

用戶使用我們的RPC框架時如何盡量少的配置
如何將服務(wù)注冊到ZK(這里注冊中心選擇ZK)上并且讓用戶無感知
如何調(diào)用透明(盡量用戶無感知)的調(diào)用服務(wù)提供者
啟用多個服務(wù)提供者如何做到動態(tài)負載均衡
框架如何做到能讓用戶自定義擴展組件(比如擴展自定義負載均衡策略)
如何定義消息協(xié)議，以及編解碼
...等等

上面這些問題在設(shè)計這個RPC框架中都會給予解決。

技術(shù)選型

注冊中心目前成熟的注冊中心有Zookeeper，Nacos，Consul，Eureka，這里使用ZK作為注冊中心，沒有提供切換以及用戶自定義注冊中心的功能。
IO通信框架本實現(xiàn)采用 Netty 作為底層通信框架，因為Netty 是一個高性能事件驅(qū)動型的非阻塞的IO(NIO)框架，沒有提供別的實現(xiàn)，也不支持用戶自定義通信框架
消息協(xié)議本實現(xiàn)使用自定義消息協(xié)議，后面會具體說明

項目總體結(jié)構(gòu)

從這個結(jié)構(gòu)中可以知道，以rpc命名開頭的是rpc框架的模塊，也是本項目RPC框架的內(nèi)容，而consumer是服務(wù)消費者，provider是服務(wù)提供者，provider-api是暴露的服務(wù)API。

整體依賴情況

項目實現(xiàn)介紹

要做到用戶使用我們的RPC框架時盡量少的配置，所以把rpc框架設(shè)計成一個starter，用戶只要依賴這個starter,基本那就可以了。

為什么要設(shè)計成兩個 starter (client-starter/server-starter) ?

這個是為了更好的體現(xiàn)出客戶端和服務(wù)端的概念，消費者依賴客戶端，服務(wù)提供者依賴服務(wù)端，還有就是最小化依賴。

為什么要設(shè)計成 starter ?

基于spring boot自動裝配機制，會加載starter中的 spring.factories 文件，在文件中配置以下代碼，這里我們starter的配置類就生效了，在配置類里面配置一些需要的bean。

org.springframework.boot.autoconfigure.EnableAutoConfiguration=com.rrtv.rpc.client.config.RpcClientAutoConfiguration

發(fā)布服務(wù)和消費服務(wù)

對于發(fā)布服務(wù)

服務(wù)提供者需要在暴露的服務(wù)上增加注解 @RpcService，這個自定義注解是基于 @service 的，是一個復(fù)合注解，具備@service注解的功能，在@RpcService注解中指明服務(wù)接口和服務(wù)版本，發(fā)布服務(wù)到ZK上，會根據(jù)這個兩個元數(shù)據(jù)注冊

發(fā)布服務(wù)原理：

服務(wù)提供者啟動之后，根據(jù)spring boot自動裝配機制，server-starter的配置類就生效了，在一個 bean 的后置處理器（RpcServerProvider）中獲取被注解 @RpcService 修飾的bean，將注解的元數(shù)據(jù)注冊到ZK上。

對于消費服務(wù)

消費服務(wù)需要使用自定義的 @RpcAutowired 注解標識，是一個復(fù)合注解，基于 @Autowired。

消費服務(wù)原理

要讓客戶端無感知的調(diào)用服務(wù)提供者，就需要使用動態(tài)代理，如上面所示， HelloWordService 沒有實現(xiàn)類，需要給它賦值代理類，在代理類中發(fā)起請求調(diào)用。

基于spring boot自動裝配，服務(wù)消費者啟動，bean 后置處理器 RpcClientProcessor 開始工作，它主要是遍歷所有的bean，判斷每個bean中的屬性是否有被 @RpcAutowired 注解修飾，有的話把該屬性動態(tài)賦值代理類，這個再調(diào)用時會調(diào)用代理類的 invoke 方法。

代理類 invoke 方法通過服務(wù)發(fā)現(xiàn)獲取服務(wù)端元數(shù)據(jù)，封裝請求，通過netty發(fā)起調(diào)用。

注冊中心

本項目注冊中心使用ZK，由于注冊中心被服務(wù)消費者和服務(wù)提供者都使用。所以把ZK放在rpc-core模塊。

rpc-core 這個模塊如上圖所示，核心功能都在這個模塊。服務(wù)注冊在 register 包下。

服務(wù)注冊接口，具體實現(xiàn)使用ZK實現(xiàn)。

負載均衡策略

負載均衡定義在rpc-core中，目前支持輪詢（FullRoundBalance）和隨機（RandomBalance），默認使用隨機策略。由rpc-client-spring-boot-starter指定。

通過ZK服務(wù)發(fā)現(xiàn)時會找到多個實例，然后通過負載均衡策略獲取其中一個實例

可以在消費者中配置 rpc.client.balance=fullRoundBalance 替換，也可以自定義負載均衡策略，通過實現(xiàn)接口 LoadBalance，并將創(chuàng)建的類加入IOC容器即可。由于我們配置 @ConditionalOnMissingBean，所以會優(yōu)先加載用戶自定義的 bean。

自定義消息協(xié)議、編解碼

所謂協(xié)議，就是通信雙方事先商量好規(guī)則，服務(wù)端知道發(fā)送過來的數(shù)據(jù)將如何解析。

自定義消息協(xié)議

魔數(shù)：魔數(shù)是通信雙方協(xié)商的一個暗號，通常采用固定的幾個字節(jié)表示。魔數(shù)的作用是防止任何人隨便向服務(wù)器的端口上發(fā)送數(shù)據(jù)。例如 java Class 文件開頭就存儲了魔數(shù) 0xCAFEBABE，在加載 Class 文件時首先會驗證魔數(shù)的正確性
協(xié)議版本號：隨著業(yè)務(wù)需求的變化，協(xié)議可能需要對結(jié)構(gòu)或字段進行改動，不同版本的協(xié)議對應(yīng)的解析方法也是不同的。
序列化算法：序列化算法字段表示數(shù)據(jù)發(fā)送方應(yīng)該采用何種方法將請求的對象轉(zhuǎn)化為二進制，以及如何再將二進制轉(zhuǎn)化為對象，如 JSON、Hessian、Java 自帶序列化等。
報文類型：在不同的業(yè)務(wù)場景中，報文可能存在不同的類型。RPC 框架中有請求、響應(yīng)、心跳等類型的報文。
狀態(tài)：狀態(tài)字段用于標識請求是否正常（SUCCESS、FAIL）。
消息ID：請求唯一ID，通過這個請求ID將響應(yīng)關(guān)聯(lián)起來，也可以通過請求ID做鏈路追蹤。
數(shù)據(jù)長度：標明數(shù)據(jù)的長度，用于判斷是否是一個完整的數(shù)據(jù)包
數(shù)據(jù)內(nèi)容：請求體內(nèi)容

編解碼

編解碼實現(xiàn)在 rpc-core 模塊，在包 com.rrtv.rpc.core.codec下。

自定義編碼器通過繼承 netty 的 MessageToByteEncoder<MessageProtocol<T>>類實現(xiàn)消息編碼。

自定義解碼器通過繼承 netty 的 ByteToMessageDecoder類實現(xiàn)消息解碼。

解碼時需要注意TCP粘包、拆包問題

什么是TCP粘包、拆包

TCP 傳輸協(xié)議是面向流的，沒有數(shù)據(jù)包界限，也就是說消息無邊界。客戶端向服務(wù)端發(fā)送數(shù)據(jù)時，可能將一個完整的報文拆分成多個小報文進行發(fā)送，也可能將多個報文合并成一個大的報文進行發(fā)送。因此就有了拆包和粘包。

在網(wǎng)絡(luò)通信的過程中，每次可以發(fā)送的數(shù)據(jù)包大小是受多種因素限制的，如 MTU 傳輸單元大小、滑動窗口等。

所以如果一次傳輸?shù)木W(wǎng)絡(luò)包數(shù)據(jù)大小超過傳輸單元大小，那么我們的數(shù)據(jù)可能會拆分為多個數(shù)據(jù)包發(fā)送出去。如果每次請求的網(wǎng)絡(luò)包數(shù)據(jù)都很小，比如一共請求了 10000 次，TCP 并不會分別發(fā)送 10000 次。TCP采用的 Nagle（批量發(fā)送，主要用于解決頻繁發(fā)送小數(shù)據(jù)包而帶來的網(wǎng)絡(luò)擁塞問題）算法對此作出了優(yōu)化。

所以，網(wǎng)絡(luò)傳輸會出現(xiàn)這樣：

tcp_package.png

服務(wù)端恰巧讀到了兩個完整的數(shù)據(jù)包 A 和 B，沒有出現(xiàn)拆包/粘包問題；
服務(wù)端接收到 A 和 B 粘在一起的數(shù)據(jù)包，服務(wù)端需要解析出 A 和 B；
服務(wù)端收到完整的 A 和 B 的一部分數(shù)據(jù)包 B-1，服務(wù)端需要解析出完整的 A，并等待讀取完整的 B 數(shù)據(jù)包；
服務(wù)端接收到 A 的一部分數(shù)據(jù)包 A-1，此時需要等待接收到完整的 A 數(shù)據(jù)包；
數(shù)據(jù)包 A 較大，服務(wù)端需要多次才可以接收完數(shù)據(jù)包 A。

如何解決TCP粘包、拆包問題

解決問題的根本手段：找出消息的邊界：

消息長度固定

每個數(shù)據(jù)報文都需要一個固定的長度。當接收方累計讀取到固定長度的報文后，就認為已經(jīng)獲得一個完整的消息。當發(fā)送方的數(shù)據(jù)小于固定長度時，則需要空位補齊。

消息定長法使用非常簡單，但是缺點也非常明顯，無法很好設(shè)定固定長度的值，如果長度太大會造成字節(jié)浪費，長度太小又會影響消息傳輸，所以在一般情況下消息定長法不會被采用。

特定分隔符

在每次發(fā)送報文的尾部加上特定分隔符，接收方就可以根據(jù)特殊分隔符進行消息拆分。分隔符的選擇一定要避免和消息體中字符相同，以免沖突。否則可能出現(xiàn)錯誤的消息拆分。比較推薦的做法是將消息進行編碼，例如 base64 編碼，然后可以選擇 64 個編碼字符之外的字符作為特定分隔符

消息長度 + 消息內(nèi)容

消息長度 + 消息內(nèi)容是項目開發(fā)中最常用的一種協(xié)議，接收方根據(jù)消息長度來讀取消息內(nèi)容。

本項目就是利用 “消息長度 + 消息內(nèi)容” 方式解決TCP粘包、拆包問題的。所以在解碼時要判斷數(shù)據(jù)是否夠長度讀取，沒有不夠說明數(shù)據(jù)沒有準備好，繼續(xù)讀取數(shù)據(jù)并解碼，這里這種方式可以獲取一個個完整的數(shù)據(jù)包。

序列化和反序列化

序列化和反序列化在 rpc-core 模塊 com.rrtv.rpc.core.serialization 包下，提供了 HessianSerialization 和 JsonSerialization 序列化。

默認使用 HessianSerialization 序列化。用戶不可以自定義。

序列化性能：

空間上

serialization_space.png

時間上

serialization_time.png

網(wǎng)絡(luò)傳輸，使用netty

netty 代碼固定的，值得注意的是 handler 的順序不能弄錯，以服務(wù)端為例，編碼是出站操作（可以放在入站后面），解碼和收到響應(yīng)都是入站操作，解碼要在前面。

image.png

客戶端 RPC 調(diào)用方式

成熟的 RPC 框架一般會提供四種調(diào)用方式，分別為同步 Sync、異步 Future、回調(diào) Callback和單向 Oneway。

Sync 同步調(diào)用

客戶端線程發(fā)起 RPC 調(diào)用后，當前線程會一直阻塞，直至服務(wù)端返回結(jié)果或者處理超時異常。

sync.png

Future 異步調(diào)用

客戶端發(fā)起調(diào)用后不會再阻塞等待，而是拿到 RPC 框架返回的 Future 對象，調(diào)用結(jié)果會被服務(wù)端緩存，客戶端自行決定后續(xù)何時獲取返回結(jié)果。當客戶端主動獲取結(jié)果時，該過程是阻塞等待的

future.png

Callback 回調(diào)調(diào)用

客戶端發(fā)起調(diào)用時，將 Callback 對象傳遞給 RPC 框架，無須同步等待返回結(jié)果，直接返回。當獲取到服務(wù)端響應(yīng)結(jié)果或者超時異常后，再執(zhí)行用戶注冊的 Callback 回調(diào)

callback.png

Oneway 單向調(diào)用

客戶端發(fā)起請求之后直接返回，忽略返回結(jié)果

oneway.png

這里使用的是第一種：客戶端同步調(diào)用，其他的沒有實現(xiàn)。邏輯在 RpcFuture 中，使用 CountDownLatch 實現(xiàn)阻塞等待（超時等待）

整體架構(gòu)和流程

流程分為三塊：服務(wù)提供者啟動流程、服務(wù)消費者啟動、調(diào)用過程

服務(wù)提供者啟動

服務(wù)提供者 provider 會依賴 rpc-server-spring-boot-starter
ProviderApplication 啟動，根據(jù)springboot 自動裝配機制，RpcServerAutoConfiguration 自動配置生效
RpcServerProvider 是一個bean后置處理器，會發(fā)布服務(wù)，將服務(wù)元數(shù)據(jù)注冊到ZK上
RpcServerProvider.run 方法會開啟一個 netty 服務(wù)

服務(wù)消費者啟動

服務(wù)消費者 consumer 會依賴 rpc-client-spring-boot-starter
ConsumerApplication 啟動，根據(jù)springboot 自動裝配機制，RpcClientAutoConfiguration 自動配置生效
將服務(wù)發(fā)現(xiàn)、負載均衡、代理等bean加入IOC容器
后置處理器 RpcClientProcessor 會掃描 bean ,將被 @RpcAutowired 修飾的屬性動態(tài)賦值為代理對象

調(diào)用過程

服務(wù)消費者發(fā)起請求http://localhost:9090/hello/world?name=hello
服務(wù)消費者調(diào)用 helloWordService.sayHello() 方法，會被代理到執(zhí)行 ClientStubInvocationHandler.invoke() 方法
服務(wù)消費者通過ZK服務(wù)發(fā)現(xiàn)獲取服務(wù)元數(shù)據(jù)，找不到報錯404
服務(wù)消費者自定義協(xié)議，封裝請求頭和請求體
服務(wù)消費者通過自定義編碼器 RpcEncoder 將消息編碼
服務(wù)消費者通過服務(wù)發(fā)現(xiàn)獲取到服務(wù)提供者的ip和端口，通過Netty網(wǎng)絡(luò)傳輸層發(fā)起調(diào)用
服務(wù)消費者通過 RpcFuture 進入返回結(jié)果（超時）等待
服務(wù)提供者收到消費者請求
服務(wù)提供者將消息通過自定義解碼器 RpcDecoder 解碼
服務(wù)提供者解碼之后的數(shù)據(jù)發(fā)送到 RpcRequestHandler 中進行處理，通過反射調(diào)用執(zhí)行服務(wù)端本地方法并獲取結(jié)果
服務(wù)提供者將執(zhí)行的結(jié)果通過編碼器 RpcEncoder 將消息編碼。（由于請求和響應(yīng)的協(xié)議是一樣，所以編碼器和解碼器可以用一套）
服務(wù)消費者將消息通過自定義解碼器 RpcDecoder 解碼
服務(wù)消費者通過RpcResponseHandler將消息寫入請求和響應(yīng) 池中，并設(shè)置 RpcFuture 的響應(yīng)結(jié)果
服務(wù)消費者獲取到結(jié)果

以上流程具體可以結(jié)合代碼分析，代碼后面會給出

環(huán)境搭建

操作系統(tǒng)：Windows
集成開發(fā)工具：IntelliJ IDEA
項目技術(shù)棧：SpringBoot 2.5.2 + JDK 1.8 + Netty 4.1.42.Final
項目依賴管理工具：Maven 4.0.0
注冊中心：Zookeeeper 3.7.0

項目測試

啟動 Zookeeper 服務(wù)器：bin/zkServer.cmd
啟動 provider 模塊 ProviderApplication
啟動 consumer 模塊 ConsumerApplication
測試：瀏覽器輸入 http://localhost:9090/hello/world?name=hello，成功返回您好：hello, rpc 調(diào)用成功

項目代碼地址

??https://gitee.com/listen_w/rpc.git??

責(zé)任編輯：龐桂玉來源： Java知音

RPC 框架后端