什么是rpc框架？
先回答第一個問題：什么是RPC框架？ 如果用一句話概括RPC就是：遠(yuǎn)程調(diào)用框架（Remote Procedure Call）
那什么是遠(yuǎn)程調(diào)用？
通常我們調(diào)用一個php中的方法，比如這樣一個函數(shù)方法: localAdd(10, 20)，localAdd方法的具體實(shí)現(xiàn)要么是用戶自己定義的，要么是php庫函數(shù)中自帶的，也就說在localAdd方法的代碼實(shí)現(xiàn)在本地，它是一個本地調(diào)用！
遠(yuǎn)程調(diào)用意思就是：被調(diào)用方法的具體實(shí)現(xiàn)不在程序運(yùn)行本地，而是在別的某個遠(yuǎn)程地方。
最早在 Nelson 的論文中指出實(shí)現(xiàn) RPC 的程序包括 5 個理論模型部分：
User
User-stub
RPCRuntime
Server-stub
Server
這 5 個部分的關(guān)系如下圖所示：
這里 User 就是 Client 端。當(dāng) User 想發(fā)起一個遠(yuǎn)程調(diào)用時(shí)，它實(shí)際是通過本地調(diào)用 User-stub。 User-stub 負(fù)責(zé)將調(diào)用的接口、方法和參數(shù)通過約定的協(xié)議規(guī)范進(jìn)行編碼并通過本地的 RPCRuntime 實(shí)例傳輸?shù)竭h(yuǎn)端的實(shí)例。 遠(yuǎn)端 RPCRuntime 實(shí)例收到請求后交給 Server-stub 進(jìn)行解碼后發(fā)起向本地端 Server 的調(diào)用，調(diào)用結(jié)果再返回給 User 端。
遠(yuǎn)程調(diào)用原理
比如 A (client) 調(diào)用 B (server) 提供的remoteAdd方法：
首先A與B之間建立一個TCP連接；
然后A把需要調(diào)用的方法名（這里是remoteAdd）以及方法參數(shù)（10， 20）序列化成字節(jié)流發(fā)送出去；
B接受A發(fā)送過來的字節(jié)流，然后反序列化得到目標(biāo)方法名，方法參數(shù)，接著執(zhí)行相應(yīng)的方法調(diào)用（可能是localAdd）并把結(jié)果30返回；A接受遠(yuǎn)程調(diào)用結(jié)果,輸出30。
RPC框架就是把我剛才說的這幾點(diǎn)些細(xì)節(jié)給封裝起來，給用戶暴露簡單友好的API使用。
遠(yuǎn)程調(diào)用的好處
解耦：當(dāng)server需要對方法內(nèi)實(shí)現(xiàn)修改時(shí)，client完全感知不到，不用做任何變更；這種方式在跨部門，跨公司合作的時(shí)候經(jīng)常用到，并且方法的提供者我們通常稱為：服務(wù)的暴露。
RPC與Socket有什么區(qū)別？
通過上面的簡單闡述，好像RPC與Socket 好像啊。都是調(diào)用遠(yuǎn)程的方法，都是client/server模式，我之前也寫了一篇文章: 細(xì)說socket 那他們有啥區(qū)別呢?
RPC（遠(yuǎn)程過程調(diào)用）采用客戶機(jī)/服務(wù)器模式實(shí)現(xiàn)兩個進(jìn)程之間相互通信。socket是RPC經(jīng)常采用的通信手段之一，RPC是在Socket的基礎(chǔ)上實(shí)現(xiàn)的，它比socket需要更多的網(wǎng)絡(luò)和系統(tǒng)資源。除了Socket，RPC還有其他的通信方法，比如：http、操作系統(tǒng)自帶的管道等技術(shù)來實(shí)現(xiàn)對于遠(yuǎn)程程序的調(diào)用。微軟的windows系統(tǒng)中，RPC就是采用命名管道進(jìn)行通信。
RPC與REST有什么區(qū)別？
通過了解RPC后，我們知道是RPC是client/server模式的，調(diào)用遠(yuǎn)程的方法，REST也是我們熟悉的一套API調(diào)用協(xié)議方法，它也是基于client/server模式的，調(diào)用遠(yuǎn)程的方法的，那他倆又有啥區(qū)別呢？
REST API 和 RPC 都是在 Server端 把一個個函數(shù)封裝成接口暴露出去，以供 Client端 調(diào)用，不過 REST API 是基于 HTTP協(xié)議的，REST致力于通過http協(xié)議中的POST/GET/PUT/DELETE等方法和一個可讀性強(qiáng)的URL來提供一個http請求。而 RPC 則可以不基于 HTTP協(xié)議
因此，如果是后端兩種語言互相調(diào)用，用 RPC 可以獲得更好的性能（省去了 HTTP 報(bào)頭等一系列東西），應(yīng)該也更容易配置。如果是前端通過 AJAX 調(diào)用后端，那么用 REST API 的形式比較好（因?yàn)闊o論如何也避不開 HTTP 這道坎）。
本地過程調(diào)用
RPC就是要像調(diào)用本地的函數(shù)一樣去調(diào)遠(yuǎn)程函數(shù)。在研究RPC前，我們先看看本地調(diào)用是怎么調(diào)的。假設(shè)我們要調(diào)用函數(shù)Multiply來計(jì)算lvalue * rvalue的結(jié)果:
int Multiply(int l, int r) {
int y = l * r;
return y;
}
int lvalue = 10;
int rvalue = 20;
int l_times_r = Multiply(lvalue, rvalue);
復(fù)制代碼
那么在第8行時(shí)，我們實(shí)際上執(zhí)行了以下操作：
將 lvalue 和 rvalue 的值壓棧
進(jìn)入Multiply函數(shù)，取出棧中的值10 和 20，將其賦予 l 和 r
執(zhí)行第2行代碼，計(jì)算 l * r ，并將結(jié)果存在 y
將 y 的值壓棧，然后從Multiply返回
第8行，從棧中取出返回值 200 ，并賦值給 l_times_r
以上5步就是執(zhí)行本地調(diào)用的過程。
遠(yuǎn)程過程調(diào)用帶來的新問題
在遠(yuǎn)程調(diào)用時(shí)，我們需要執(zhí)行的函數(shù)體是在遠(yuǎn)程的機(jī)器上的，也就是說，Multiply是在另一個進(jìn)程中執(zhí)行的。這就帶來了幾個新問題：
Call ID映射。 我們怎么告訴遠(yuǎn)程機(jī)器我們要調(diào)用Multiply，而不是Add或者FooBar呢？在本地調(diào)用中，函數(shù)體是直接通過函數(shù)指針來指定的，我們調(diào)用Multiply，編譯器就自動幫我們調(diào)用它相應(yīng)的函數(shù)指針。但是在遠(yuǎn)程調(diào)用中，函數(shù)指針是不行的，因?yàn)閮蓚€進(jìn)程的地址空間是完全不一樣的。所以，在RPC中，所有的函數(shù)都必須有自己的一個ID。這個ID在所有進(jìn)程中都是唯一確定的。客戶端在做遠(yuǎn)程過程調(diào)用時(shí)，必須附上這個ID。然后我們還需要在客戶端和服務(wù)端分別維護(hù)一個 {函數(shù) <--> Call ID} 的對應(yīng)表。兩者的表不一定需要完全相同，但相同的函數(shù)對應(yīng)的Call ID必須相同。當(dāng)客戶端需要進(jìn)行遠(yuǎn)程調(diào)用時(shí)，它就查一下這個表，找出相應(yīng)的Call ID，然后把它傳給服務(wù)端，服務(wù)端也通過查表，來確定客戶端需要調(diào)用的函數(shù)，然后執(zhí)行相應(yīng)函數(shù)的代碼。
序列化和反序列化。 客戶端怎么把參數(shù)值傳給遠(yuǎn)程的函數(shù)呢？在本地調(diào)用中，我們只需要把參數(shù)壓到棧里，然后讓函數(shù)自己去棧里讀就行。但是在遠(yuǎn)程過程調(diào)用時(shí)，客戶端跟服務(wù)端是不同的進(jìn)程，不能通過內(nèi)存來傳遞參數(shù)。甚至有時(shí)候客戶端和服務(wù)端使用的都不是同一種語言（比如服務(wù)端用C++，客戶端用JAVA或者Python/ target=_blank class=infotextkey>Python）。這時(shí)候就需要客戶端把參數(shù)先轉(zhuǎn)成一個字節(jié)流，傳給服務(wù)端后，再把字節(jié)流轉(zhuǎn)成自己能讀取的格式。這個過程叫序列化和反序列化。同理，從服務(wù)端返回的值也需要序列化反序列化的過程。
網(wǎng)絡(luò)傳輸。 遠(yuǎn)程調(diào)用往往用在網(wǎng)絡(luò)上，客戶端和服務(wù)端是通過網(wǎng)絡(luò)連接的。所有的數(shù)據(jù)都需要通過網(wǎng)絡(luò)傳輸，因此就需要有一個網(wǎng)絡(luò)傳輸層。網(wǎng)絡(luò)傳輸層需要把Call ID和序列化后的參數(shù)字節(jié)流傳給服務(wù)端，然后再把序列化后的調(diào)用結(jié)果傳回客戶端。只要能完成這兩者的，都可以作為傳輸層使用。因此，它所使用的協(xié)議其實(shí)是不限的，能完成傳輸就行。盡管大部分RPC框架都使用TCP協(xié)議，但其實(shí)UDP也可以，而gRPC干脆就用了HTTP2。Java?.NETty也屬于這層的東西。
所以，要實(shí)現(xiàn)一個RPC框架，其實(shí)只需要把以上三點(diǎn)實(shí)現(xiàn)了就基本完成了。
Call ID映射可以直接使用函數(shù)字符串，也可以使用整數(shù)ID。映射表一般就是一個哈希表。
序列化反序列化可以自己寫，也可以使用Protobuf或者FlatBuffers之類的。
網(wǎng)絡(luò)傳輸庫可以自己寫socket，或者用asio，ZeroMQ，Netty之類。
大廠流行的rpc框架有哪些？
1、google之gprc
github.com/grpc/grpc
github.com/google/prot…
doc.oschina.net/grpc
2、Facebook之thrift
Thrift 源于Facebook,在 2007 年 Facebook 將 Thrift 作為一個開源項(xiàng)目提交給了 Apache 基金會。
thrift.apache.org/
thrift.apache.org/lib/
thrift.apache.org/lib/cpp
github.com/apache/thri…
3、Tencent之Tars
騰訊微服務(wù)框架Tars介紹
github.com/TarsCloud/T…
github.com/TarsCloud/T…
github.com/TarsCloud/T…
github.com/Tencent/phx…，前身是Svrkit
github.com/loveyacper/… 熱心前騰訊大咖diy，C++實(shí)現(xiàn)
4、Baidu之brpc
brpc又稱為baidu-rpc,是百度開發(fā)一款“遠(yuǎn)程過程調(diào)用”網(wǎng)絡(luò)框架。C++實(shí)現(xiàn)。
github.com/brpc/brpc
5、golang之rpcx
rpcx是一個類似阿里巴巴 Dubbo 和微博 Motan 的分布式的RPC服務(wù)框架，基于Golang net/rpc實(shí)現(xiàn)。號稱是最好的Go語言的RPC服務(wù)治理框架，快、易用卻功能強(qiáng)大，性能遠(yuǎn)遠(yuǎn)高于 Dubbo、Motan、Thrift等框架，是gRPC性能的兩倍。
rpcx.io/
github.com/smallnest/r…
6、搜狗之srpc
Sogou基于Workflow的自研RPC框架，C++實(shí)現(xiàn)
github.com/sogou/srpc -- RPC based on Sogou C++ Workflow
github.com/sogou/workf… -- Sogou’s C++ Asynchronous Programming Engine
www.zhihu.com/people/liyi…
其它小眾的開源C++ RPC
1. RCF: 純c++的RPC, 不引入IDL, 大量用到boost，比較強(qiáng)大.
2. casocklib: protobuf + asio 較完善實(shí)現(xiàn)
3. eventrpc: protobuf + libevent 較完善實(shí)現(xiàn)
www.exit1.org/Event-RPC/
4. evproto: protobuf + libevent 簡單實(shí)現(xiàn)
github.com/chenshuo/ev…
github.com/chenshuo/ev…
5. febird：同樣無IDL的c++ RPC，自己實(shí)現(xiàn)了串行化和網(wǎng)絡(luò)IO.
6. libHttp, xmlrpc 都是xml封裝的RPC
7.rest_rpc
github.com/topcpporg/r…
8.muduo_rpc
github.com/chenshuo/mu…
github.com/chenshuo/mu…
9.other
github.com/IronsDu/gay…
github.com/guangqianpe…
github.com/hjk41/tinyr…
github.com/button-chen…
github.com/persistents… 一個基于protocol buffer的RPC實(shí)現(xiàn)
www.cnblogs.com/persistents… 一個基于protocol buffer的RPC實(shí)現(xiàn)
java rpc
java，一起寫rpc框架
blog.csdn.net/linuu/artic…
作者：firecat全宏
鏈接：https://juejin.cn/post/6963591648915914782
來源：稀土掘金
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。
