菜菜哥，我最近終于把Socket通信調(diào)通了

這么底層的東西你現(xiàn)在都會了，恭喜你離漲薪又進一步呀

http協(xié)議不也是利用的Socket嗎

可以這么說，http協(xié)議是基于TCP協(xié)議的，底層的數(shù)據(jù)傳輸可以說是利用的socket

既然Socket通信會了，那一個rpc的框架不就很容易就能實現(xiàn)了嗎？

一個比較完備的rpc框架可能并非像你所想那樣簡單，要不然人人都可以出RPC框架了

有那么難嗎？我覺得沒有那么難呀

如果你能解決掉這些問題，我覺得你真的是大牛了

RPC是遠程過程調(diào)用（Remote Procedure Call）的縮寫形式,是在多任務操作系統(tǒng)或聯(lián)網(wǎng)的計算機之間運行的程序和進程所用的通信技術(shù)

01開局

擼碼的人都應該知道，現(xiàn)代編程中最常用的系統(tǒng)之間通信方式是：http調(diào)用和rpc調(diào)用。對于同一個網(wǎng)絡或者說是互通的網(wǎng)絡環(huán)境中，rpc調(diào)用方式是系統(tǒng)間通信交互最常用的方式，比基于http協(xié)議的通信方式性能高出數(shù)倍甚至數(shù)個量級。我司的平臺rpc通信，每秒在幾萬甚至更高，每次調(diào)用的通信時間在一定程度上幾乎可以忽略不計，再加上我們首席架構(gòu)師深厚的系統(tǒng)設(shè)計功力，采用進程內(nèi)緩存等等優(yōu)化措施，一次rpc調(diào)用的整體平均時間也在一毫秒之下。這是http協(xié)議無法達到的速度，如果你在瀏覽器的F12的窗口觀察過，一個http協(xié)議調(diào)用如果整體花費的時間在5毫秒甚至10毫秒，那么其實就可以認為這個http請求響應時間是很短的了。

所以絕大部分公司內(nèi)部的系統(tǒng)之間通信都會采用rpc調(diào)用這種方式。這里不要抬杠，如果你的公司內(nèi)部系統(tǒng)通信采用的是基于http協(xié)議的，那說明你們的系統(tǒng)很有可能沒有性能的要求。

RPC調(diào)用雖然簡化了擼碼的難度，但是想要實現(xiàn)一套rpc框架，何止容易，一套優(yōu)秀的rpc框架，更是難如登天。

01連接服務

多數(shù)rpc框架的服務端以service的方式來運行，為了避免和其他進程發(fā)生監(jiān)聽端口的沖突，一般會隨機選擇一個端口來進行監(jiān)聽。雖然這看上去很好，但是卻給client端帶來了麻煩，如果服務端監(jiān)聽固定端口，client連接服務端的時候，最少可以在代碼中固定寫死服務端的IP和端口。但是現(xiàn)在服務端監(jiān)聽的端口是隨機的，而且更可怕的是服務器有可能會更換或者切換IP，那client怎么才能正確的去和服務端建立連接呢？

服務端之所以會采用這種隨機方式來監(jiān)聽端口，其中很大一個原因是為了以后擴容。client如何正確的去連接服務器則采用了一個集中式的方案，服務端引入了一個服務注冊中心的概念，有的系統(tǒng)可能會以別的名稱來體現(xiàn)，但是作用是類似的。這個注冊中心存儲著所有的服務端信息，其中包括每個服務端的IP和端口，有的甚至還有版本信息，每個服務端進程啟動的時候，都是采用主動連接注冊中心，主動注冊的方式。client端在發(fā)起連接服務的時候，首先去注冊中心查找已經(jīng)注冊的服務端信息，然后進行連接。這樣rpc調(diào)用在某種程度上在連接步驟就實現(xiàn)了“自動化”。

02調(diào)用方法

當client和服務端建立tcp連接之后（有的rpc框架會采用udp協(xié)議），下一個問題就是client和服務端怎么相認的問題了。舉個栗子：客戶端想要實現(xiàn)一個獲取用戶姓名的方法，方法名怎么定義才能讓服務端正確識別出來呢？是傳一個字符串“GetName”,還是傳一個整數(shù)1來代表呢？服務端的返回結(jié)果，如果發(fā)生異常改如何返回呢？

當我們在本地調(diào)用一個函數(shù)，語法，語義，以及語法語義的分析，編譯器已經(jīng)幫我們做好了這些，但是rpc是遠程過程調(diào)用，雖然表面上和本地類似，但是已經(jīng)出現(xiàn)了跨網(wǎng)絡的情況，語法語義等等這些分析需要client和服務端協(xié)商一致。

其實現(xiàn)代幾乎大部分rpc通信都遵循一個標準：

當client發(fā)起一個遠程調(diào)用的時候，它首先會先調(diào)用本地的Stub，它負責將調(diào)用的接口，函數(shù)以及參數(shù)按照約定好的協(xié)議格式進行編碼，然后通過本地的Runtime進行傳輸，最后通過網(wǎng)卡將數(shù)據(jù)包發(fā)送到指定的服務器。

服務器Runtime接收到請求之后，會首先調(diào)用本地的Stub按照約定好的協(xié)議格式進行解碼，最后調(diào)用服務端具體的函數(shù)。函數(shù)執(zhí)行完畢，把結(jié)果利用本地的Stub編碼之后通過runtime發(fā)送給客戶端。客戶端Runtime接收到消息利用本地Stub進行解碼，然后進行其他處理。

由此可見，現(xiàn)代的rpc框架其實是把協(xié)議的封裝和數(shù)據(jù)的發(fā)送分別抽象成了單獨的層。Stub負責協(xié)議部分，Runtime處理數(shù)據(jù)發(fā)送以及網(wǎng)絡相關(guān)部分。

03網(wǎng)絡數(shù)據(jù)傳輸

數(shù)據(jù)通過網(wǎng)絡傳輸過程中，每個數(shù)據(jù)包的完整性如何來識別，如果是一個簡單int型數(shù)據(jù)很簡單，但是如果是一個類或者一個數(shù)組，甚至是其他變長的類型，rpc的通信協(xié)議如何約束這些，如果能正確識別出來數(shù)據(jù)是協(xié)議部分最難處理的部分。更何況還有大頭小頭編碼的問題。

凡是基于網(wǎng)絡傳輸?shù)男问?#xff0c;任何通信都是不可靠的，網(wǎng)絡本質(zhì)是不可靠的。包括網(wǎng)絡抖動，錯誤等造成的丟包，粘包現(xiàn)象，如何正確的處理也是一個rpc通信中很重要的部分。一個rpc請求失敗，是直接丟棄還是重試，這些策略都需要去規(guī)定。

04性能

1.一個rpc調(diào)用如果采用同步的方式，性能會大大打折扣，如何實現(xiàn)rpc的異步調(diào)用，這是一個rpc是否優(yōu)秀的重要指標。

2.無論rpc的網(wǎng)絡傳輸多么優(yōu)秀，都會有性能損耗，能否把某些結(jié)果數(shù)據(jù)設(shè)置緩存？

3.無論是client還是服務端，處理請求的線程能否重用（線程池）？

4.能否支持多語言呢？

socket雖易，RPC卻難

完

●●●
●●●●●●●●

總結(jié)

以上是生活随笔為你收集整理的程序员修神之路--设计一套RPC框架并非易事的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。