什麼是RPC？

Remote Procedure Call Protocol，遠端過程呼叫。

什麼是“遠端”？

先來看下什麼是“近”，即“本地函式呼叫”。

int result = Add(1,2);

這行程式碼的時候，到底發生了什麼？

• 傳遞兩個入參
• 呼叫了原生程式碼段中的函式，執行運算邏輯
• 返回一個出參

這三個動作，都發生在同一個程式空間裡，這是本地函式呼叫。

那有沒有辦法，呼叫一個跨程式的函式呢？

典型的，這個程式部署在另一臺伺服器上。

最容易想到的，兩個程式約定一個協議格式，使用Socket通訊，來傳輸：

• 入參
• 呼叫哪個函式
• 出參

如果能夠實現，那這就是“遠端”過程呼叫。

Socket通訊只能傳遞連續的位元組流，如何將入參、函式都放到連續的位元組流裡呢？

假設，設計一個11位元組的請求報文：

• 前3個位元組填入函式名“add”
• 中間4個位元組填入第一個引數“1”
• 末尾4個位元組填入第二個引數“2”

同理，可以設計一個4位元組響應報文：

• 4個位元組填入處理結果“3”

呼叫方的程式碼可能變為：

request = MakePacket(“add”,1,2);

SendRequest_ToService_B(request);

response = RecieveRespnse_FromService_B();

int result = unMakePacket(respnse);

這4個步驟是：

（1）將傳入引數變為位元組流；

（2）將位元組流發給服務B；

（3）從服務B接受返回位元組流；

（4）將返回位元組流變為傳出引數；

服務方的程式碼可能變為：

request = RecieveRequest();

args/function = unMakePacket(request);

result = Add(1,2);

response = MakePacket(result);

SendResponse(response);

這個5個步驟也很好理解：

（1）服務端收到位元組流；

（2）將位元組流轉為函式名與引數；

（3）本地呼叫函式得到結果；

（4）將結果轉變為位元組流；

（5）將位元組流傳送給呼叫方；

這個過程用一張圖描述如下：

呼叫方與服務方的處理步驟都是非常清晰。

這個過程存在最大的問題是什麼呢？

呼叫方太麻煩了，每次都要關注很多底層細節：

• 入參到位元組流的轉化，即序列化應用層協議細節
• socket傳送，即網路傳輸協議細節
• socket接收
• 位元組流到出參的轉化，即反序列化應用層協議細節

能不能呼叫層不關注這個細節？

可以，RPC框架就是解決這個問題的，它能夠讓呼叫方“像呼叫本地函式一樣呼叫遠端的函式（服務）”。

RPC框架的職責是什麼？

RPC框架，要向呼叫方遮蔽各種複雜性，要向服務提供方也遮蔽各類複雜性：

• 服務呼叫方client感覺就像呼叫本地函式一樣，來呼叫服務
• 服務提供方server感覺就像實現一個本地函式一樣，來實現服務

所以整個RPC框架又分為client部分與server部分，實現上面的目標，把複雜性遮蔽，就是RPC框架的職責。

如上圖所示，業務方的職責是：

• 呼叫方A，傳入引數，執行呼叫，拿到結果
• 服務方B，收到引數，執行邏輯，返回結果

RPC框架的職責是，中間大藍框的部分：

• client端：序列化、反序列化、連線池管理、負載均衡、故障轉移、佇列管理，超時管理、非同步管理等等

• server端：服務端元件、服務端收發包佇列、io執行緒、工作執行緒、序列化反序列化等

先來看看RPC-client部分的“序列化反序列化”部分。

為什麼要進行序列化？

開發通常使用“物件”來進行資料的操縱：

class User{

​ std::String user_name;

​ uint64_t user_id;

​ uint32_t user_age;

};

User u = new User(“xiaoming”);

u.setUid(123);

u.setAge(35);

但當需要對資料進行儲存或者傳輸時，“物件”就不這麼好用了，往往需要把資料轉化成連續空間的“二進位制位元組流”，一些典型的場景是：

• 資料庫索引的磁碟儲存：資料庫的索引在記憶體裡是b+樹，但這個格式是不能夠直接儲存到磁碟上的，所以需要把b+樹轉化為連續空間的二進位制位元組流，才能儲存到磁碟上
• 快取的KV儲存：redis/memcache是KV型別的快取，快取儲存的value是連續空間的二進位制位元組流，而不能夠是User物件
• 資料的網路傳輸：socket傳送的資料必須是連續空間的二進位制位元組流，也不能是物件

所謂序列化（Serialization），就是將“物件”形態的資料轉化為“連續空間二進位制位元組流”形態資料的過程。這個過程的逆過程叫做反序列化。

怎麼進行序列化？

這是一個非常細節的問題，要是讓你來把“物件”轉化為位元組流，你會怎麼做？很容易想到的一個方法是xml（或者json）這類具有自描述特性的標記性語言：

規定好轉換規則，傳送方很容易把User類的一個物件序列化為xml，服務方收到xml二進位制流之後，也很容易將其範序列化為User物件。

第二個方法是自己實現二進位制協議來進行序列化，還是以上面的User物件為例，可以設計一個這樣的通用協議：

• 頭4個位元組表示序號
• 序號後面的4個位元組表示key的長度m
• 接下來的m個位元組表示key的值
• 接下來的4個位元組表示value的長度n
• 接下來的n個位元組表示value的值
• 像xml一樣遞迴下去，直到描述完整個物件

上面的User物件，用這個協議描述出來可能是這樣的：

• 第一行：序號4個位元組（設0表示類名），類名長度4個位元組（長度為4），接下來4個位元組是類名（”User”），共12位元組
• 第二行：序號4個位元組（1表示第一個屬性），屬性長度4個位元組（長度為9），接下來9個位元組是屬性名（”user_name”），屬性值長度4個位元組（長度為8），屬性值8個位元組（值為”shenjian”），共29位元組
• 第三行：序號4個位元組（2表示第二個屬性），屬性長度4個位元組（長度為7），接下來7個位元組是屬性名（”user_id”），屬性值長度4個位元組（長度為8），屬性值8個位元組（值為123），共27位元組
• 第四行：序號4個位元組（3表示第三個屬性），屬性長度4個位元組（長度為8），接下來8個位元組是屬性名（”user_name”），屬性值長度4個位元組（長度為4），屬性值4個位元組（值為35），共24位元組

整個二進位制位元組流共12+29+27+24=92位元組。

實際的序列化協議要考慮的細節遠比這個多，例如：強型別的語言不僅要還原屬性名，屬性值，還要還原屬性型別；複雜的物件不僅要考慮普通型別，還要考慮物件巢狀型別等。無論如何，序列化的思路都是類似的。

序列化協議要考慮什麼因素？

不管使用成熟協議xml/json，還是自定義二進位制協議來序列化物件，序列化協議設計時都需要考慮以下這些因素。

• 解析效率：這個應該是序列化協議應該首要考慮的因素，像xml/json解析起來比較耗時，需要解析doom樹，二進位制自定義協議解析起來效率就很高
• 壓縮率，傳輸有效性：同樣一個物件，xml/json傳輸起來有大量的xml標籤，資訊有效性低，二進位制自定義協議佔用的空間相對來說就小多了
• 擴充套件性與相容性：是否能夠方便的增加欄位，增加欄位後舊版客戶端是否需要強制升級，都是需要考慮的問題，xml/json和上面的二進位制協議都能夠方便的擴充套件
• 可讀性與可除錯性：這個很好理解，xml/json的可讀性就比二進位制協議好很多
• 跨語言：上面的兩個協議都是跨語言的，有些序列化協議是與開發語言緊密相關的，例如dubbo的序列化協議就只能支援Java的RPC呼叫
• 通用性：xml/json非常通用，都有很好的第三方解析庫，各個語言解析起來都十分方便，上面自定義的二進位制協議雖然能夠跨語言，但每個語言都要寫一個簡易的協議客戶端

有哪些常見的序列化方式？

• xml/json：解析效率，壓縮率都較差，擴充套件性、可讀性、通用性較好
• thrift
• protobuf：Google出品，必屬精品，各方面都不錯，強烈推薦，屬於二進位制協議，可讀性差了點，但也有類似的to-string協議幫助除錯問題
• Avro
• CORBA
• …

RPC-client除了：

• 序列化反序列化的部分（上圖中的1、4）

還包含：

• 傳送位元組流與接收位元組流的部分（上圖中的2、3）

這一部分，又分為同步呼叫與非同步呼叫兩種方式，下面一一來進行介紹。

同步呼叫的程式碼片段為：

Result = Add(Obj1,Obj2);// 得到Result之前處於阻塞狀態

非同步呼叫的程式碼片段為：

Add(Obj1,Obj2,callback);// 呼叫後直接返回，不等結果

處理結果通過回撥為：

callback(Result){// 得到處理結果後會呼叫這個回撥函式

​ …

}

這兩類呼叫，在RPC-client裡，實現方式完全不一樣。

RPC-client同步呼叫架構如何？

所謂同步呼叫，在得到結果之前，一直處於阻塞狀態，會一直佔用一個工作執行緒，上圖簡單的說明瞭一下元件、互動、流程步驟：

• 左邊大框，代表了呼叫方的一個工作執行緒
• 左邊粉色中框，代表了RPC-client元件
• 右邊橙色框，代表了RPC-server
• 藍色兩個小框，代表了同步RPC-client兩個核心元件，序列化元件與連線池元件
• 白色的流程小框，以及箭頭序號1-10，代表整個工作執行緒的序列執行步驟：

1）業務程式碼發起RPC呼叫：

Result=Add(Obj1,Obj2)

2）序列化元件，將物件呼叫序列化成二進位制位元組流，可理解為一個待傳送的包packet1；

3）通過連線池元件拿到一個可用的連線connection；

4）通過連線connection將包packet1傳送給RPC-server；

5）傳送包在網路傳輸，發給RPC-server；

6）響應包在網路傳輸，發回給RPC-client；

7）通過連線connection從RPC-server收取響應包packet2；

8）通過連線池元件，將conneciont放回連線池；

9）序列化元件，將packet2範序列化為Result物件返回給呼叫方；

10）業務程式碼獲取Result結果，工作執行緒繼續往下走；

連線池元件有什麼作用？

RPC框架支援的負載均衡、故障轉移、傳送超時等特性，都是通過連線池元件去實現的。

典型連線池元件對外提供的介面為：

int ConnectionPool::init(…);

Connection ConnectionPool::getConnection();

int ConnectionPool::putConnection(Connection t);

init做了些什麼？

和下游RPC-server（一般是一個叢集），建立N個tcp長連線，即所謂的連線“池”。

getConnection做了些什麼？

從連線“池”中拿一個連線，加鎖（置一個標誌位），返回給呼叫方。

putConnection做了些什麼？

將一個分配出去的連線放回連線“池”中，解鎖（也是置一個標誌位）。

如何實現負載均衡？

連線池中建立了與一個RPC-server叢集的連線，連線池在返回連線的時候，需要具備隨機性。

如何實現故障轉移？

連線池中建立了與一個RPC-server叢集的連線，當連線池發現某一個機器的連線異常後，需要將這個機器的連線排除掉，返回正常的連線，在機器恢復後，再將連線加回來。

如何實現傳送超時？

因為是同步阻塞呼叫，拿到一個連線後，使用帶超時的send/recv即可實現帶超時的傳送和接收。

總的來說，同步的RPC-client的實現是相對比較容易的，序列化元件、連線池元件配合多工作執行緒數，就能夠實現。

遺留問題，工作執行緒數設定為多少最合適？

RPC-client非同步回撥架構如何？

所謂非同步回撥，在得到結果之前，不會處於阻塞狀態，理論上任何時間都沒有任何執行緒處於阻塞狀態，因此非同步回撥的模型，理論上只需要很少的工作執行緒與服務連線就能夠達到很高的吞吐量，如上圖所示：

• 左邊的框框，是少量工作執行緒（少數幾個就行了）進行呼叫與回撥
• 中間粉色的框框，代表了RPC-client元件
• 右邊橙色框，代表了RPC-server
• 藍色六個小框，代表了非同步RPC-client六個核心元件：上下文管理器，超時管理器，序列化元件，下游收發佇列，下游收發執行緒，連線池元件
• 白色的流程小框，以及箭頭序號1-17，代表整個工作執行緒的序列執行步驟：

1）業務程式碼發起非同步RPC呼叫；

Add(Obj1,callback)

2）上下文管理器，將請求，回撥，上下文儲存起來；

3）序列化元件，將物件呼叫序列化成二進位制位元組流，可理解為一個待傳送的包packet1；

4）下游收發佇列，將報文放入“待傳送佇列”，此時呼叫返回，不會阻塞工作執行緒；

5）下游收發執行緒，將報文從“待傳送佇列”中取出，通過連線池元件拿到一個可用的連線connection；

6）通過連線connection將包packet1傳送給RPC-server；

7）傳送包在網路傳輸，發給RPC-server；

8）響應包在網路傳輸，發回給RPC-client；

9）通過連線connection從RPC-server收取響應包packet2；

10）下游收發執行緒，將報文放入“已接受佇列”，通過連線池元件，將conneciont放回連線池；

11）下游收發佇列裡，報文被取出，此時回撥將要開始，不會阻塞工作執行緒；

12）序列化元件，將packet2範序列化為Result物件；

13）上下文管理器，將結果，回撥，上下文取出；

14）通過callback回撥業務程式碼，返回Result結果，工作執行緒繼續往下走；

如果請求長時間不返回，處理流程是：

15）上下文管理器，請求長時間沒有返回；

16）超時管理器拿到超時的上下文；

17）通過timeout_cb回撥業務程式碼，工作執行緒繼續往下走；

序列化元件和連線池元件上文已經介紹過，收發佇列與收發執行緒比較容易理解。下面重點介紹上下文管理器與超時管理器這兩個總的元件。

為什麼需要上下文管理器？

由於請求包的傳送，響應包的回撥都是非同步的，甚至不在同一個工作執行緒中完成，需要一個元件來記錄一個請求的上下文，把請求-響應-回撥等一些資訊匹配起來。

如何將請求-響應-回撥這些資訊匹配起來？

這是一個很有意思的問題，通過一條連線往下游服務傳送了a，b，c三個請求包，非同步的收到了x，y，z三個響應包：

怎麼知道哪個請求包與哪個響應包對應？

怎麼知道哪個響應包與哪個回撥函式對應？

可以通過“請求id”來實現請求-響應-回撥的串聯。

整個處理流程如上，通過請求id，上下文管理器來對應請求-響應-callback之間的對映關係：

1）生成請求id；

2）生成請求上下文context，上下文中包含傳送時間time，回撥函式callback等資訊；

3）上下文管理器記錄req-id與上下文context的對映關係；

4）將req-id打在請求包裡發給RPC-server；

5）RPC-server將req-id打在響應包裡返回；

6）由響應包中的req-id，通過上下文管理器找到原來的上下文context；

7）從上下文context中拿到回撥函式callback；

8）callback將Result帶回，推動業務的進一步執行；

如何實現負載均衡，故障轉移？

與同步的連線池思路類似，不同之處在於：

• 同步連線池使用阻塞方式收發，需要與一個服務的一個ip建立多條連線
• 非同步收發，一個服務的一個ip只需要建立少量的連線（例如，一條tcp連線）

如何實現超時傳送與接收？

超時收發，與同步阻塞收發的實現就不一樣了：

• 同步阻塞超時，可以直接使用帶超時的send/recv來實現
• 非同步非阻塞的nio的網路報文收發，由於連線不會一直等待回包，超時是由超時管理器實現的

超時管理器如何實現超時管理？

超時管理器，用於實現請求回包超時回撥處理。

每一個請求傳送給下游RPC-server，會在上下文管理器中儲存req-id與上下文的資訊，上下文中儲存了請求很多相關資訊，例如req-id，回包回撥，超時回撥，傳送時間等。

超時管理器啟動timer對上下文管理器中的context進行掃描，看上下文中請求傳送時間是否過長，如果過長，就不再等待回包，直接超時回撥，推動業務流程繼續往下走，並將上下文刪除掉。

如果超時回撥執行後，正常的回包又到達，通過req-id在上下文管理器裡找不到上下文，就直接將請求丟棄。

無論如何，非同步回撥和同步回撥相比，除了序列化元件和連線池元件，會多出上下文管理器，超時管理器，下游收發佇列，下游收發執行緒等元件，並且對呼叫方的呼叫習慣有影響。

總結

什麼是RPC呼叫？

像呼叫本地函式一樣，呼叫一個遠端服務。

為什麼需要RPC框架？

RPC框架用於遮蔽RPC呼叫過程中的序列化，網路傳輸等技術細節。讓呼叫方只專注於呼叫，服務方只專注於實現呼叫。

什麼是序列化？為什麼需要序列化？

把物件轉化為連續二進位制流的過程，叫做序列化。磁碟儲存，快取儲存，網路傳輸只能操作於二進位制流，所以必須序列化。

同步RPC-client的核心元件是什麼？

同步RPC-client的核心元件是序列化元件、連線池元件。它通過連線池來實現負載均衡與故障轉移，通過阻塞的收發來實現超時處理。

非同步RPC-client的核心元件是什麼？

非同步RPC-client的核心元件是序列化元件、連線池元件、收發佇列、收發執行緒、上下文管理器、超時管理器。它通過“請求id”來關聯請求包-響應包-回撥函式，用上下文管理器來管理上下文，用超時管理器中的timer觸發超時回撥，推進業務流程的超時處理。