微服務(wù)在用，RPC 框架也用了不少，HSF（丟大了，只想起來了這一個(gè) 腫么辦，很緊張啊~~~），其實(shí) dubbo 也用過了。
這篇文章 大概介紹下 為什么需要RPC 啊，RPC 有什么好處，或者這個(gè)鬼幫我們做了哪些工作啊？
不會涉及具體代碼及實(shí)現(xiàn)，后面一點(diǎn)點(diǎn)啃哈，莫急！
一、需求緣起
服務(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ù)
