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

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

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

一、需求緣起

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

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

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

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

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

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

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

在達成【“使用統(tǒng)一的RPC框架”是正確的道路】這個一致的前提下，本文期望用簡單通俗的言語簡述一下一個通用RPC框架的技術點與實現(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)用一個跨進程(所以叫“遠程”，典型的，這個進程部署在另一臺服務器上)的函數(shù)呢?

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

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

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

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

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

同時可以設計響應報文協(xié)議是一個4字節(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ā)給服務B

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

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

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

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

這個過程也很好理解：

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

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

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

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

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

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

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

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

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

(3)socket接受

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

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

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

三、RPC框架職責

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

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

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

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

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

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

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

四、結論

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

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

文章轉載自微信公眾號“架構師之路”