***章聊了【“為什么要進行服務(wù)化，服務(wù)化究竟解決什么問題”】

第二章聊了【“微服務(wù)的服務(wù)粒度選型”】

今天開始聊一些微服務(wù)的實踐，***塊，RPC框架的原理及實踐，為什么說要搞定微服務(wù)架構(gòu)，先搞定RPC框架呢?

一、需求緣起

服務(wù)化的一個好處就是，不限定服務(wù)的提供方使用什么技術(shù)選型，能夠?qū)崿F(xiàn)大公司跨團隊的技術(shù)解耦，如下圖：

服務(wù)A是歐洲團隊提供服務(wù)，歐洲團隊的技術(shù)背景是Java，可以用Java實現(xiàn)服務(wù);

服務(wù)B是美洲團隊提供服務(wù)，可以用C++實現(xiàn)服務(wù);

服務(wù)C是中國團隊提供服務(wù)，可以用Go實現(xiàn)服務(wù);

服務(wù)的上游調(diào)用方，按照接口、協(xié)議即可完成對遠端服務(wù)的調(diào)用。

但實際上，99.9%的公司的團隊規(guī)模有限，技術(shù)團隊人數(shù)也有限，基本是使用同一套技術(shù)體系來調(diào)用和提供服務(wù)的：

這樣的話，如果沒有統(tǒng)一的服務(wù)框架，RPC框架，各個團隊的服務(wù)提供方就需要各自實現(xiàn)一套序列化、反序列化、網(wǎng)絡(luò)框架、連接池、收發(fā)線程、超時處理、狀態(tài)機等“業(yè)務(wù)之外”的重復(fù)技術(shù)勞動，造成整體的低效。所以，統(tǒng)一RPC框架把上述“業(yè)務(wù)之外”的技術(shù)勞動統(tǒng)一處理，是服務(wù)化首要解決的問題。

在達成【“使用統(tǒng)一的RPC框架”是正確的道路】這個一致的前提下，本文期望用簡單通俗的言語簡述一下一個通用RPC框架的技術(shù)點與實現(xiàn)。

二、RPC背景與過程

什么是RPC(Remote Procedure Call Protocol)，遠程過程調(diào)用?

先來看下什么是本地函數(shù)調(diào)用，當我們寫下：

int result = Add(1, 2);

這段代碼的時候，我們知道，我們傳入了1，2兩個入?yún)?shù)，調(diào)用了本地代碼段中的一個Add函數(shù)，得到了result出參。此時，傳入數(shù)據(jù)，傳出數(shù)據(jù)，代碼段在同一個進程空間里，這是本地函數(shù)調(diào)用。

那有沒有辦法，我們能夠調(diào)用一個跨進程(所以叫“遠程”，典型的，這個進程部署在另一臺服務(wù)器上)的函數(shù)呢?

最容易想到的，兩個進程約定一個協(xié)議格式，使用Socket通信，來傳輸【入?yún)ⅰ俊菊{(diào)用哪個函數(shù)】【出參】。

假設(shè)請求報文協(xié)議是一個11字節(jié)的字節(jié)流：

(1)前3個字節(jié)填入函數(shù)名

(2)中間4個字節(jié)填入***個參數(shù)

(3)末尾4個字節(jié)填入第二個參數(shù)

同時可以設(shè)計響應(yīng)報文協(xié)議是一個4字節(jié)的字節(jié)流：

即處理結(jié)果。

調(diào)用方的代碼可能變?yōu)椋?/p>

request = MakePacket(“add”, 1, 2);  
SendRequest_ToService_B(request); 
response = RecieveRespnse_FromService_B(); 
int result = unMakePacket(respnse); 

簡單解釋一下：

(1)講傳入?yún)?shù)變?yōu)樽止?jié)流

(2)將字節(jié)流發(fā)給服務(wù)B

(3)從服務(wù)B接受返回字節(jié)流

(4)將返回字節(jié)流變?yōu)閭鞒鰠?shù)

服務(wù)方的代碼可能變?yōu)椋?/p>

request = RecieveRequest(); 
args/function = unMakePacket(request); 
result = Add(1, 2); 
response = MakePacket(result); 
SendResponse(response); 

這個過程也很好理解：

(1)服務(wù)端收到字節(jié)流

(2)將字節(jié)流轉(zhuǎn)為函數(shù)名與參數(shù)

(3)本地調(diào)用函數(shù)得到結(jié)果

(4)將結(jié)果轉(zhuǎn)變?yōu)樽止?jié)流

(5)將字節(jié)流發(fā)送給調(diào)用方

這個過程用一張圖描述如上，調(diào)用方與服務(wù)方的處理步驟都是非常清晰的。這個過程存在***的問題是什么呢?

回答：調(diào)用方太麻煩了，每次都要關(guān)注很多底層細節(jié)

(1)入?yún)⒌阶止?jié)流的轉(zhuǎn)化，即序列化應(yīng)用層協(xié)議細節(jié)

(2)socket發(fā)送，即網(wǎng)絡(luò)傳輸協(xié)議細節(jié)

(3)socket接受

(4)字節(jié)流到出參的轉(zhuǎn)化，即反序列化應(yīng)用層協(xié)議細節(jié)

能不能調(diào)用層不關(guān)注這個細節(jié)呢?

回答：可以，RPC框架就是解決這個問題的，它能夠讓調(diào)用方“像調(diào)用本地函數(shù)一樣調(diào)用遠端的函數(shù)(服務(wù))”。

三、RPC框架職責

通過上面的討論，RPC框架要向調(diào)用方屏蔽各種復(fù)雜性，要向服務(wù)提供方也屏蔽各類復(fù)雜性：

(1)調(diào)用方感覺就像調(diào)用本地函數(shù)一樣

(2)服務(wù)提供方感覺就像實現(xiàn)一個本地函數(shù)一樣來實現(xiàn)服務(wù)

所以整個RPC框架又分為client部分與server部分，負責把整個非(1)(2)的各類復(fù)雜性屏蔽，這些復(fù)雜性就是RPC框架的職責。

再細化一些，client端又包含：序列化、反序列化、連接池管理、負載均衡、故障轉(zhuǎn)移、隊列管理，超時管理、異步管理等等等等職責。

server端包含：服務(wù)端組件、服務(wù)端收發(fā)包隊列、io線程、工作線程、序列化反序列化、上下文管理器、超時管理、異步回調(diào)等等等等職責。

however，因為篇幅有限，這些細節(jié)不做深入展開。

四、結(jié)論

(1)RPC框架是架構(gòu)微服務(wù)化的首要基礎(chǔ)組件，它能大大降低架構(gòu)微服務(wù)化的成本，提高調(diào)用方與服務(wù)提供方的研發(fā)效率，屏蔽跨進程調(diào)用函數(shù)(服務(wù))的各類復(fù)雜細節(jié)

(2)RPC框架的職責是：讓調(diào)用方感覺就像調(diào)用本地函數(shù)一樣調(diào)用遠端函數(shù)、讓服務(wù)提供方感覺就像實現(xiàn)一個本地函數(shù)一樣來實現(xiàn)服務(wù)

文章轉(zhuǎn)載自微信公眾號“架構(gòu)師之路”