前言

遠(yuǎn)古時(shí)期，每個(gè)進(jìn)程各干各的，但隨著發(fā)展有時(shí)候會(huì)存在A進(jìn)程調(diào)用B進(jìn)程某一方法，使用其功能的場(chǎng)景，比如說(shuō)把畫(huà)圖統(tǒng)一都在某一個(gè)進(jìn)程中，其他進(jìn)程只需要調(diào)用它就ok了（代碼沒(méi)有散落到各地、也減少了一部分動(dòng)態(tài)鏈接的管理），但是最初是不支持的，就產(chǎn)生了所謂的IPC（Inter-process communication 本地進(jìn)程間通信），沒(méi)錯(cuò)這里的IPC就是上學(xué)的時(shí)候經(jīng)常背的 共享內(nèi)存等進(jìn)程間通訊方式。
再后來(lái)越來(lái)越多的單機(jī)系統(tǒng)復(fù)雜到無(wú)法維護(hù)面臨拆分，小型機(jī)的瓶頸凸顯及性價(jià)比越來(lái)越低，由pc和廉價(jià)服務(wù)器構(gòu)成的集群、分布式方案逐漸形成，開(kāi)始出現(xiàn)多個(gè)pc或者服務(wù)器 搭建分布式系統(tǒng)的場(chǎng)景，之前單機(jī)上的IPC也演變成了現(xiàn)在的RPC（遠(yuǎn)程過(guò)程調(diào)用）。
做服務(wù)器端研發(fā)，經(jīng)常會(huì)有這樣的一些名詞RMI(remote method invocation，面向?qū)ο蟮倪h(yuǎn)程方法調(diào)用)、RPC（remote procedure call，遠(yuǎn)程過(guò)程調(diào)用）、SOAP(simple object access protoal，簡(jiǎn)單對(duì)象訪問(wèn)協(xié)議)、REST(representational state transfer，表達(dá)性狀態(tài)轉(zhuǎn)移)，這些都可以理解為調(diào)用遠(yuǎn)程方法的一些通信技術(shù)“風(fēng)格”，其中RPC是一個(gè)泛化的概念，嚴(yán)格來(lái)說(shuō)一切遠(yuǎn)程過(guò)程調(diào)用手段都屬于rpc范疇，本系列要說(shuō)的就是這個(gè)泛化的RPC。

定義

RPC（Remote Procedure Call Protocol）遠(yuǎn)程過(guò)程調(diào)用協(xié)議，就是允許程序調(diào)用另一個(gè)地址空間（通常是共享網(wǎng)絡(luò)的另一臺(tái)機(jī)器上）的過(guò)程或函數(shù)，且不需要顯式編碼這個(gè)遠(yuǎn)程調(diào)用的細(xì)節(jié)。
它是一種架設(shè)在計(jì)算機(jī)網(wǎng)絡(luò)之上并隱藏底層網(wǎng)絡(luò)技術(shù)，像調(diào)用本地服務(wù)一樣調(diào)用遠(yuǎn)端程序，在編碼代價(jià)不高的情況下提升吞吐的能力。
通俗來(lái)說(shuō)，就是為了使程序員從網(wǎng)絡(luò)處理中釋放出來(lái)，在分布式環(huán)境下編程變得簡(jiǎn)單，無(wú)需關(guān)系底層網(wǎng)絡(luò)實(shí)現(xiàn)細(xì)節(jié)&協(xié)議僅關(guān)注業(yè)務(wù)邏輯實(shí)現(xiàn)即可，比如Java的Dubbo、Go的net/rpc & RPCX、谷歌的grpc等。我們只需要按照約定定義對(duì)外接口，按照約定發(fā)起調(diào)用即可，操作起來(lái)跟調(diào)了一個(gè)函數(shù)差異不大。

核心關(guān)注點(diǎn)

看完定義之后，應(yīng)該清楚rpc所要解決的核心問(wèn)題：進(jìn)程間通信時(shí)，減少網(wǎng)絡(luò)編碼的成本&出錯(cuò)概率
在看rpc時(shí)首先想到的是它的構(gòu)成，通常來(lái)說(shuō)是長(zhǎng)這樣的：

image.png

通信協(xié)議

在通信協(xié)議方面，RPC跨越了傳輸層和應(yīng)用層，像grpc 就是基于http 2.0的協(xié)議、Dubbo在tcp基礎(chǔ)上研發(fā)的應(yīng)用層傳輸協(xié)議。
這一塊后續(xù)會(huì)單獨(dú)對(duì)于常見(jiàn)的應(yīng)用層網(wǎng)絡(luò)協(xié)議（基于TCP的自研協(xié)議、基于現(xiàn)有的HTTP 2.0）進(jìn)行介紹，包括其中的特點(diǎn)優(yōu)勢(shì)等
另外，好多同學(xué)剛接觸RPC時(shí)，可能會(huì)對(duì)RPC or http 產(chǎn)生一點(diǎn)疑惑，為什么有了http還要使用RPC，這兩個(gè)概念的維度上是不同的：
HTTP ：提供標(biāo)準(zhǔn)的報(bào)文格式，都認(rèn)可的通訊特性等，對(duì)外仍然暴露出標(biāo)準(zhǔn)的網(wǎng)絡(luò)編程接口。
RPC ：針對(duì)某些領(lǐng)域的特定場(chǎng)景提供具有更靈活、可定制的、更加保密的協(xié)議?？梢园裄PC理解是通訊協(xié)議之上，站在服務(wù)的角度，做的更高一級(jí)的封裝。
換句話說(shuō)，如果你想 在http 1.1 上包一層函數(shù)代理（隱藏網(wǎng)絡(luò)通信細(xì)節(jié)）、集成服務(wù)注冊(cè)發(fā)現(xiàn)（某場(chǎng)景下的特定訴求）等具有加成作用的功能，你可能就寫(xiě)出了一個(gè)RPC框架。

編碼協(xié)議

首先RPC協(xié)議是語(yǔ)言無(wú)關(guān)的，客戶端的實(shí)現(xiàn)語(yǔ)言與服務(wù)端的實(shí)現(xiàn)語(yǔ)言可以是相同的也可以是不同的，在RPC調(diào)用時(shí)必然需要一種標(biāo)準(zhǔn)的編碼協(xié)議來(lái)約定接口數(shù)據(jù)格式、處理傳輸內(nèi)容的編碼解碼操作，具體要看框架的實(shí)現(xiàn)程度和支持。
后續(xù)會(huì)對(duì)業(yè)界常見(jiàn)的 基于文本編碼的json、xml、基于二進(jìn)制編碼protobuf 為例進(jìn)行介紹。

RPC框架選型

常見(jiàn)的RPC 框架是很多的，在我們進(jìn)行新業(yè)務(wù)開(kāi)發(fā)的時(shí)候RPC框架的選型問(wèn)題會(huì)變得很凸顯，通常有如下幾個(gè)方面考慮：（核心就是成本（現(xiàn)在&將來(lái)），不能因?yàn)樾录夹g(shù)或者大家都在用就貿(mào)然引入）
1、機(jī)器成本（比較各個(gè)RPC所能帶來(lái)的性能提升，從而節(jié)省出的機(jī)器）
2、研發(fā)效率成本（引入新的技術(shù)所帶來(lái)的效率提升比較）
3、研發(fā)質(zhì)量成本（引入新的技術(shù)會(huì)不會(huì)引入新的風(fēng)險(xiǎn)，該風(fēng)險(xiǎn)是否可控，解決風(fēng)險(xiǎn)的代價(jià)）
4、人力成本（引入新的技術(shù)時(shí)，團(tuán)隊(duì)對(duì)該技術(shù)該語(yǔ)言的熟悉程度，引入&熟悉時(shí)需要付出的人力成本，要考慮團(tuán)隊(duì)技術(shù)棧等多方面因素）
前三點(diǎn)是引入的價(jià)值比較（是否值得引入、應(yīng)該用哪個(gè)），最后一點(diǎn)是當(dāng)前情況下是否值得引入。
分布式RPC框架性能大比拼 dubbo、motan、rpcx、gRPC、thrift的性能比較

小記

本系列文章是2020 年第一個(gè)系列的文章，同步更新中（服務(wù)注冊(cè)發(fā)現(xiàn)等服務(wù)治理范疇內(nèi)的內(nèi)容本系列暫不敘述，僅說(shuō)RPC）
《RPC 概述》
《由RPC 再探網(wǎng)絡(luò)--高效率網(wǎng)絡(luò)通信》
《由RPC 再探網(wǎng)絡(luò)--http 2.0等應(yīng)用層協(xié)議》
《由RPC 再探編碼--高效率編碼》
《用Netty手寫(xiě)RPC》
《用Go手寫(xiě)RPC》
《學(xué)RPC？來(lái)看看Dubbo》
《學(xué)RPC？來(lái)看看BRPC》
《學(xué)RPC？來(lái)看看GRPC》
《學(xué)RPC？來(lái)看看RPCX》
《通訊&編碼，Redis應(yīng)用層協(xié)議實(shí)現(xiàn)》
《通訊&編碼，Kafka應(yīng)用層協(xié)議實(shí)現(xiàn)》