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

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

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

一、需求緣起

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

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

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

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

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

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

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

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

二、RPC背景與過程

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

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

int result = Add(1, 2);

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

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

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

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

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

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

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

同時(shí)可以設(shè)計(jì)響應(yīng)報(bào)文協(xié)議是一個(gè)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); 

這個(gè)過程也很好理解：

(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)用方

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

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

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

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

(3)socket接受

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

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

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

三、RPC框架職責(zé)

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

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

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

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

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

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

however，因?yàn)槠邢蓿@些細(xì)節(jié)不做深入展開。

四、結(jié)論

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

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

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