進(jìn)程間通信（IPC)是在多任務(wù)操作系統(tǒng)或聯(lián)網(wǎng)的計(jì)算機(jī)之間運(yùn)行的程序和進(jìn)程所采用的通信技術(shù)产场，IPC有兩種類型的進(jìn)程間通信的方式分別是本地過程調(diào)用（LPC）和遠(yuǎn)程過程調(diào)用（RPC)派昧。

本地過程調(diào)用LPC

本地過程調(diào)用（LPC）用于多任務(wù)操作系統(tǒng)中，使同時(shí)運(yùn)行的任務(wù)能夠相互會(huì)話踢械，任務(wù)共享內(nèi)存空間以實(shí)現(xiàn)任務(wù)同步和互相發(fā)送消息。

例如：完成一個(gè)本地函數(shù)的調(diào)用

int add(int x, int y){
  return x + y;
}
int a = 1;
int b = 2;
int result = add(a, b);

add()函數(shù)的執(zhí)行流程

1. 分別將變量a和b的值壓入棧
2. 執(zhí)行add()函數(shù)，從棧中取出a和b的值爱谁，賦值給x和y辈末。
3. 計(jì)算x加y的值并保存到棧中
4. 退出add()函數(shù)將x加y的值賦值給result

本地過程調(diào)用發(fā)生在同一進(jìn)程中愚争，共享內(nèi)存區(qū)域。而RPC通信則需要跨域不同機(jī)器挤聘、不同進(jìn)程轰枝，因此需要解決三個(gè)問題：函數(shù)ID（服務(wù)尋址）、數(shù)據(jù)流的序列化和反序列化组去、網(wǎng)絡(luò)傳輸

如果add()函數(shù)調(diào)用在客戶端鞍陨，執(zhí)行函數(shù)的函數(shù)體卻在遠(yuǎn)程機(jī)器上，如何告知機(jī)器如何調(diào)用這個(gè)方法呢从隆？

首先客戶端需要告訴服務(wù)器诚撵，需要調(diào)用的函數(shù)，這里函數(shù)和進(jìn)程ID存在一個(gè)映射键闺，客戶端遠(yuǎn)程調(diào)用時(shí)需要檢查一下函數(shù)以找到對應(yīng)的ID寿烟，然后執(zhí)行函數(shù)的代碼。

客戶端需要將本地參數(shù)傳遞給遠(yuǎn)程函數(shù)艾杏，本地調(diào)用的過程中直接壓棧即可韧衣。但在遠(yuǎn)程調(diào)用過程中不在同一個(gè)內(nèi)存中，無法直接傳遞參數(shù)的參數(shù)购桑，因此需要客戶端將參數(shù)轉(zhuǎn)換為字節(jié)流畅铭，傳遞給服務(wù)器。服務(wù)器再將字節(jié)流轉(zhuǎn)換為自身能讀取的格式勃蜘，這是一個(gè)序列化和反序列化的過程硕噩。

當(dāng)數(shù)據(jù)準(zhǔn)備好之后，如何進(jìn)行傳輸呢缭贡？網(wǎng)絡(luò)傳輸層需要將調(diào)用的ID和序列化后的參數(shù)傳遞給服務(wù)器炉擅，然后將計(jì)算好的結(jié)果序列化傳遞給客戶端。因此TCP層可以完成上述操作阳惹。那么為什么不使用HTTP層呢谍失？由于HTTP在應(yīng)用層中完成，整個(gè)通信的代價(jià)比較高莹汤，RPC直接基于TCP進(jìn)行遠(yuǎn)程調(diào)用快鱼，數(shù)據(jù)傳輸在傳輸層TCP完成，更加適合對效率要求比較高的場景。RPC主要依賴于客戶端和服務(wù)器之間建立的Socket鏈接進(jìn)行抹竹，但底層實(shí)現(xiàn)比REST更為復(fù)雜线罕。

遠(yuǎn)程過程調(diào)用RPC

遠(yuǎn)程過程調(diào)用（RPC）類似于LPC，只是在網(wǎng)絡(luò)中工作窃判，RPC開始是出現(xiàn)在SUN微系統(tǒng)公司和HP公司運(yùn)行的UNIX操作系統(tǒng)中钞楼。

RPC的概念與技術(shù)早在1981年由Neison提出，1984年Birrel和Neison將其用于支持異構(gòu)型分布式系統(tǒng)的通訊袄琳。Birrell的RPC模型引入存根進(jìn)程（stub）作為遠(yuǎn)程的本地代理询件，調(diào)用RPC運(yùn)行時(shí)庫來傳遞網(wǎng)絡(luò)中的調(diào)用。Stub和RPC runtime屏蔽了網(wǎng)路所涉及的細(xì)節(jié)跨蟹。特別是參數(shù)編碼與轉(zhuǎn)碼以及網(wǎng)絡(luò)任務(wù)的多樣性雳殊。RPC作為網(wǎng)絡(luò)通訊與委托計(jì)算的實(shí)現(xiàn)機(jī)制，在方法窗轩、協(xié)議夯秃、語義和實(shí)現(xiàn)上不斷發(fā)展，種類繁多痢艺，其中SUN公司和開發(fā)軟件基金會(huì)在分布式產(chǎn)品中所建立和使用的RPC較為典型仓洼。

RPC（Romote Procedure Call）遠(yuǎn)程過程調(diào)用，RPC是通信協(xié)議堤舒，該協(xié)議允許運(yùn)行于一臺(tái)計(jì)算機(jī)的程序調(diào)用另一臺(tái)計(jì)算機(jī)的子程序色建，開發(fā)人員無需額外為交互作用編程。若軟件采用面向?qū)ο缶幊躺噻停敲碦PC又稱為遠(yuǎn)程調(diào)用或遠(yuǎn)程方法調(diào)用箕戳。簡單來說，遠(yuǎn)程調(diào)用協(xié)議是一種通過網(wǎng)絡(luò)從遠(yuǎn)程計(jì)算機(jī)程序上請求服務(wù)国撵，同時(shí)無需了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議陵吸。

RPC是一種用于構(gòu)建基于客戶端/服務(wù)器（C/S）的分布式應(yīng)用程序技術(shù)，調(diào)用者與被調(diào)用者可能在同一臺(tái)服務(wù)器上介牙，也可能在由網(wǎng)絡(luò)連接的不同服務(wù)器上壮虫。對客戶端和服務(wù)器而言，使用RPC時(shí)網(wǎng)絡(luò)通信是透明的环础，遠(yuǎn)程調(diào)用如何本地調(diào)用一樣簡單囚似。簡單來說，RPC就是要像調(diào)用本地函數(shù)一樣去調(diào)用遠(yuǎn)程函數(shù)线得。

RPC

RPC解決了什么問題饶唤？

1. 解決分布式系統(tǒng)中，服務(wù)之間的調(diào)用問題贯钩。
2. 遠(yuǎn)程調(diào)用時(shí)搬素，能夠像本地調(diào)用一樣方便呵晨，讓調(diào)用者感知不到遠(yuǎn)程調(diào)用的邏輯。

為什么需要RPC熬尺？

1. RPC可以用HTTP協(xié)議實(shí)現(xiàn)，HTTP是建立在TCP之上最廣泛使用的RPC谓罗，互聯(lián)網(wǎng)公司往往會(huì)使用自己的私有協(xié)議粱哼，比如騰訊的JCE協(xié)議，私有協(xié)議不具備通用性檩咱，但相比HTTP協(xié)議揭措，RPC采用二進(jìn)制字節(jié)碼傳輸，更加高效也更為安全刻蚯。
2. 業(yè)界提倡的微服務(wù)中绊含，服務(wù)之間通信方式中RPC是其中之一，RPC可以保證不同服務(wù)之間的相互調(diào)用炊汹，即使是跨語言跨平臺(tái)也不是問題躬充，讓構(gòu)建分布式系統(tǒng)更為容易。
3. RPC框架都會(huì)存在服務(wù)降級讨便、流量控制的功能充甚，以保證服務(wù)的高可用。

RPC其實(shí)是一種技術(shù)思想而非規(guī)范或協(xié)議霸褒，常見RPC技術(shù)和框架有

• 應(yīng)用級的服務(wù)框架：阿里的Dubbo/Dubbox伴找、Google的gRPC、Spring Boot/Spring Clound
• 遠(yuǎn)程通信協(xié)議：RMI废菱、Socket技矮、SOAP(HTTP XML)、REST(HTTP JSON)
• 通信框架：MINA殊轴、Netty

RPC核心

RPC核心功能是指實(shí)現(xiàn)一個(gè)RPC最重要的功能模塊即RPC協(xié)議部分衰倦，一個(gè)RPC的核心功能主要由5部分組成分別是：客戶端、客戶端存根梳凛、網(wǎng)絡(luò)傳輸模式耿币、服務(wù)器、服務(wù)器存根韧拒。

RPC過程

RPC原理

一次客戶端對服務(wù)器的遠(yuǎn)程過程調(diào)用，其內(nèi)部操作可分為以下步驟：

RPC核心功能

RPC調(diào)用流程

1. 客戶端client（caller 服務(wù)調(diào)用者）

• 通過本地服務(wù)調(diào)用的方式調(diào)用遠(yuǎn)程服務(wù)

2. 客戶端存根 client stub

• 接收到調(diào)用請求后負(fù)責(zé)將方法和參數(shù)等信息序列化（組裝）為能夠在網(wǎng)絡(luò)中傳輸?shù)南Ⅲw。
• 調(diào)用客戶端句柄斑鸦，執(zhí)行傳送參數(shù)愕贡。

3. 客戶端存根 client stub

• 尋找到遠(yuǎn)程服務(wù)器地址并將消息通過網(wǎng)路發(fā)送給服務(wù)器
• 調(diào)用本地系統(tǒng)內(nèi)核發(fā)送網(wǎng)絡(luò)消息，消息傳遞到遠(yuǎn)程主機(jī)巷屿。

4. 服務(wù)器存根 server stub

• 接收到客戶端消息后進(jìn)行解碼即反序列化操作
• 服務(wù)器句柄得到消息并獲取參數(shù)

5. 服務(wù)器存根 server stub

• 根據(jù)解碼結(jié)果調(diào)用本地服務(wù)進(jìn)行處理
• 執(zhí)行遠(yuǎn)程過程

6. 服務(wù)器 server （callee 服務(wù)提供方）

• 本地業(yè)務(wù)處理

7. 服務(wù)器 server

• 服務(wù)器處理結(jié)果返回給服務(wù)器存根
• 執(zhí)行過程將結(jié)果返回給服務(wù)器句柄
• 服務(wù)器句柄返回結(jié)果并調(diào)用遠(yuǎn)程系統(tǒng)內(nèi)核
• 消息傳回本地主機(jī)

8. 服務(wù)器存根 server stub

• 序列化結(jié)果

9. 服務(wù)器存根 server stub

• 將序列化結(jié)果通過網(wǎng)絡(luò)發(fā)送至客戶端消費(fèi)方

10. 客戶端存根 client stub

• 接收到服務(wù)器返回的消息并進(jìn)行反序列化解碼
• 客戶端接收句柄并返回?cái)?shù)據(jù)
• 客戶端句柄由內(nèi)核接收消息

11. 客戶端 client

• 服務(wù)器消費(fèi)方獲得最終結(jié)果

RPC技術(shù)點(diǎn)

一個(gè)典型的RPC使用場景中固以，包含服務(wù)發(fā)現(xiàn)、負(fù)載嘱巾、容錯(cuò)憨琳、網(wǎng)絡(luò)傳輸、序列化等組件旬昭，其中RPC協(xié)議指明了程序如何進(jìn)行網(wǎng)絡(luò)傳輸和序列化篙螟。

RPC框架

實(shí)現(xiàn)RPC重點(diǎn)需要實(shí)現(xiàn)三個(gè)技術(shù)，分別是：服務(wù)尋址问拘、數(shù)據(jù)流的序列化和反序列化遍略、網(wǎng)絡(luò)傳輸

RPC

服務(wù)尋址

遠(yuǎn)程過程調(diào)用中包含三個(gè)角色的節(jié)點(diǎn)分別是服務(wù)調(diào)用方、服務(wù)提供方场梆、注冊中心

服務(wù)注冊發(fā)現(xiàn)機(jī)制

可靠的服務(wù)尋址方式主要是為了提供服務(wù)的發(fā)現(xiàn)墅冷，是RPC實(shí)現(xiàn)的基石。從服務(wù)提供方的角度來看或油，當(dāng)提供方服務(wù)啟動(dòng)時(shí)需要自動(dòng)向注冊中心注冊機(jī)器IP寞忿、端口和提供的服務(wù)列表，當(dāng)提供方服務(wù)停止時(shí)需要向注冊中心注銷服務(wù)顶岸。提供方需定時(shí)向注冊中心發(fā)送心跳腔彰，當(dāng)一段時(shí)間未收到來自提供方的心跳后，會(huì)認(rèn)為提供方已經(jīng)停止服務(wù)辖佣，此時(shí)會(huì)從注冊中心上摘掉對應(yīng)的服務(wù)霹抛。服務(wù)調(diào)用方啟動(dòng)時(shí)會(huì)向注冊中心獲取服務(wù)提供方地址列表。

服務(wù)尋址可以使用Call ID映射卷谈，在本地調(diào)用中杯拐，函數(shù)體是直接通過函數(shù)指針來指定的，但在遠(yuǎn)程調(diào)用中世蔗，函數(shù)指針是不行的端逼，因?yàn)閮蓚€(gè)進(jìn)程的地址空間是完全不一樣的。所以在RPC中所有的函數(shù)都必須具有自己的ID污淋，這個(gè)ID在所有進(jìn)程中都是唯一的顶滩。

客戶端在做遠(yuǎn)程過程調(diào)用時(shí)，必須附上這個(gè)函數(shù)ID寸爆，還需要在客戶端和服務(wù)端分別維護(hù)函數(shù)和Call ID的對應(yīng)表礁鲁。當(dāng)客戶端需要進(jìn)行遠(yuǎn)程調(diào)用時(shí)盐欺，會(huì)差這個(gè)對應(yīng)表找出對應(yīng)的Call ID，然后將其傳遞給服務(wù)器仅醇，服務(wù)器也通過查對應(yīng)表來確定客戶端需要調(diào)用的函數(shù)冗美，最終執(zhí)行相對應(yīng)函數(shù)的代碼。

序列化和反序列化

遠(yuǎn)程過程調(diào)用最重要的是序列化與反序列化着憨，因?yàn)閭鬏數(shù)臄?shù)據(jù)庫必須是二進(jìn)制的墩衙，因此客戶端必須將數(shù)據(jù)序列化為二進(jìn)制格式傳遞給服務(wù)器。為什么需要使用二進(jìn)制甲抖，可直接使用文本嗎？

傳送無符號單字節(jié)整數(shù)對比

采用原始的二進(jìn)制可以省掉中間轉(zhuǎn)換環(huán)節(jié)心铃，而且數(shù)據(jù)量會(huì)大大減少准谚，效率更高。采用文本方式則需要將整數(shù)轉(zhuǎn)換為字符串后發(fā)送去扣，服務(wù)端接收時(shí)又需要再次進(jìn)行數(shù)據(jù)轉(zhuǎn)換柱衔。

客戶端如何將參數(shù)傳遞給遠(yuǎn)程的函數(shù)呢？在本地過程調(diào)用中愉棱，只需要將參數(shù)壓入棧唆铐，讓函數(shù)自己去棧中讀取即可。但在遠(yuǎn)程過程調(diào)用中奔滑，客戶端跟服務(wù)器是不同的進(jìn)程艾岂，不能通過內(nèi)存來傳遞參數(shù)。此時(shí)就需要客戶端將參數(shù)先轉(zhuǎn)換為字節(jié)流再傳遞給服務(wù)器朋其，服務(wù)器接收后再將字節(jié)流轉(zhuǎn)換為自己能讀取的格式王浴。而在網(wǎng)絡(luò)中只有二進(jìn)制數(shù)據(jù)才能傳輸，因此序列化與反序列化的定義也就是將對象轉(zhuǎn)換成二進(jìn)制流的過程是序列化梅猿，將二進(jìn)制轉(zhuǎn)換為對象的過程則是反序列化氓辣。

網(wǎng)絡(luò)傳輸

遠(yuǎn)程調(diào)用往往使用在網(wǎng)絡(luò)環(huán)境中，客戶端和服務(wù)器是通過網(wǎng)絡(luò)連接的袱蚓，所有的數(shù)據(jù)都需要通過網(wǎng)絡(luò)傳輸钞啸，因此需要一個(gè)網(wǎng)絡(luò)傳輸層。網(wǎng)絡(luò)傳輸層需要將Call ID和序列化后的參數(shù)字節(jié)流傳遞給服務(wù)器喇潘，然后再將序列化后的調(diào)用結(jié)果傳回給客戶端体斩。只要能完成這兩個(gè)操作，都可以作為傳輸層使用响蓉。因此它所使用的網(wǎng)絡(luò)傳輸協(xié)議是不限的硕勿，只要能完成傳輸即可。盡管大部分RPC框架都是用TCP協(xié)議枫甲，其實(shí)UDP也可以源武。

TCP連接是最常見的扼褪，通常TCP連接可以是按需連接，即需要調(diào)用時(shí)先建立調(diào)用后斷開粱栖。也可以是長連接话浇，客戶端和服務(wù)器建立連接后保持長期持有，不管此時(shí)有無數(shù)據(jù)包的發(fā)送闹究，可以配合心跳檢測機(jī)制和定期檢測建立的連接是否存活有效幔崖。另外，多個(gè)遠(yuǎn)程過程調(diào)用可以共享同一個(gè)連接渣淤。

簡單來說赏寇，實(shí)現(xiàn)一個(gè)RCP框架只需要實(shí)現(xiàn)三點(diǎn)：

• Call ID映射：可以直接使用函數(shù)字符串，也可以使用整數(shù)ID价认，映射表通常是要一個(gè)哈希表嗅定。
• 序列化和反序列化：可使用Protobuf、FlatBuffers等之類
• 網(wǎng)絡(luò)傳輸庫：可使用Socket用踩、Asio渠退、ZeroMQ、Netty等

網(wǎng)絡(luò)I/O模型（NIO）

客戶端和服務(wù)器通信依賴Socket I/O脐彩，網(wǎng)絡(luò)I/O模型可分為傳統(tǒng)的阻塞I/O碎乃、非阻塞I/O、I/O多路復(fù)用惠奸、異步I/O梅誓。

RPC網(wǎng)絡(luò)傳輸協(xié)議

在RPC中可選的網(wǎng)絡(luò)傳輸方式有很多種，可選的包括TCP晨川、UDP证九、HTTP，每種協(xié)議對整體的性能和效率都有不同的影響共虑。如何選擇一個(gè)正確的網(wǎng)絡(luò)傳輸協(xié)議呢愧怜？

• 基于TCP的RPC

基于TCP協(xié)議的RPC調(diào)用是由服務(wù)調(diào)用方和服務(wù)提供方建立Socket連接，并由服務(wù)調(diào)用方通過Socket將需要調(diào)用的接口名稱妈拌、方法名稱拥坛、參數(shù)序列化后傳遞給服務(wù)提供方，服務(wù)提供方反序列化后再利用反射調(diào)用相關(guān)的方法尘分。最后將結(jié)果返回給服務(wù)調(diào)用方猜惋，整個(gè)基于TCP協(xié)議的RPC調(diào)用大致如此。

• 基于HTTP的RPC

基于HTTP的RPC累加類似于訪問網(wǎng)頁培愁，只是它返回的結(jié)果更為單一簡單著摔。首先由服務(wù)調(diào)用者向服務(wù)提供者發(fā)送請求，這種請求可能是GET定续、POST谍咆、PUT禾锤、DELETE等其中的一種，服務(wù)提供者可能會(huì)根據(jù)不同請求方式做出不同處理摹察，或者某個(gè)方法只允許某種請求方式恩掷。調(diào)用的具體方法則根據(jù)URL進(jìn)行方法調(diào)用，方法所需參數(shù)可能是對服務(wù)器調(diào)用方傳輸過去的XML或JSON數(shù)據(jù)解析后的結(jié)果供嚎，最后返回JSON或XML的數(shù)據(jù)結(jié)果黄娘。

兩種方式對比

基于TCP實(shí)現(xiàn)的RPC由于TCP處于協(xié)議棧的下層，能夠更加靈活地對協(xié)議字段進(jìn)行定制克滴，減少網(wǎng)路開銷提高性能逼争，實(shí)現(xiàn)更大的吞吐量和并發(fā)數(shù)。但需要更多關(guān)注底層復(fù)雜的細(xì)節(jié)劝赔，實(shí)現(xiàn)代價(jià)更高氮凝。同時(shí)對不同平臺(tái)比如安卓、iOS等需要重新開發(fā)不同的工具包來進(jìn)行請求發(fā)送和相應(yīng)的解析望忆，因此工作量大且難以快速響應(yīng)和滿足用戶需求。

基于HTTP實(shí)現(xiàn)的RPC則可以使用JSON和XML格式的請求或響應(yīng)數(shù)據(jù)竿秆，JSON和XML作為通用的格式開源解析工具已經(jīng)相當(dāng)成熟启摄。但由于HTTP是上層協(xié)議，發(fā)送包含同等內(nèi)容信息傳輸所占用的字節(jié)數(shù)會(huì)比TCP更高幽钢。

因此在同等網(wǎng)絡(luò)下通過HTTP傳輸相同的內(nèi)容效率會(huì)比TCP要低歉备，信息傳輸所占的時(shí)間也會(huì)更長，雖然壓縮數(shù)據(jù)能夠減少這一差距匪燕。