RPC細節

服務化有什麼好處？

服務化的一個好處就是，不限定服務的提供方使用什麼技術選型，可以實現大公司跨團隊的技術解耦，以下圖所示：

• 服務A：歐洲團隊維護，技術背景是Java

• 服務B：美洲團隊維護，用C++實現

• 服務C：中國團隊維護，技術棧是go

服務的上游調用方，按照接口、協議便可完成對遠端服務的調用。

 

但實際上，大部分互聯網公司，研發團隊規模有限，大都使用同一套技術體系來實現服務：

這樣的話，若是沒有統一的服務框架，各個團隊的服務提供方就須要各自實現一套序列化、反序列化、網絡框架、鏈接池、收發線程、超時處理、狀態機等「業務以外」的重複技術勞動，形成總體的低效。

 

所以，統一服務框架把上述「業務以外」的工做統一實現，是服務化首要解決的問題。

 

什麼是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框架的職責是什麼？

RPC框架，要向調用方屏蔽各類複雜性，要向服務提供方也屏蔽各種複雜性：

• 服務調用方client感受就像調用本地函數同樣，來調用服務

• 服務提供方server感受就像實現一個本地函數同樣，來實現服務

因此整個RPC框架又分爲client部分與server部分，實現上面的目標，把複雜性屏蔽，就是RPC框架的職責。

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

• 調用方A，傳入參數，執行調用，拿到結果

• 服務方B，收到參數，執行邏輯，返回結果

 

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

• client端：序列化、反序列化、鏈接池管理、負載均衡、故障轉移、隊列管理，超時管理、異步管理等等

• server端：服務端組件、服務端收發包隊列、io線程、工做線程、序列化反序列化等

 

server端的技術你們瞭解的比較多，接下來重點講講client端的技術細節。

 

先來看看RPC-client部分的「序列化反序列化」部分。

 

爲何要進行序列化？

工程師一般使用「對象」來進行數據的操縱：

class User{

         std::String user_name;

         uint64_t user_id;

         uint32_t user_age;

};

 

User u = new User(「shenjian」);

u.setUid(123);

u.setAge(35);

 

但當須要對數據進行存儲或者傳輸時，「對象」就不這麼好用了，每每須要把數據轉化成連續空間的「二進制字節流」，一些典型的場景是：

• 數據庫索引的磁盤存儲：數據庫的索引在內存裏是b+樹，但這個格式是不可以直接存儲到磁盤上的，因此須要把b+樹轉化爲連續空間的二進制字節流，才能存儲到磁盤上

• 緩存的KV存儲：redis/memcache是KV類型的緩存，緩存存儲的value必須是連續空間的二進制字節流，而不可以是User對象

• 數據的網絡傳輸：socket發送的數據必須是連續空間的二進制字節流，也不能是對象

 

所謂序列化（Serialization），就是將「對象」形態的數據轉化爲「連續空間二進制字節流」形態數據的過程。這個過程的逆過程叫作反序列化。

 

怎麼進行序列化？

這是一個很是細節的問題，要是讓你來把「對象」轉化爲字節流，你會怎麼作？很容易想到的一個方法是xml（或者json）這類具備自描述特性的標記性語言：

<class name=」User」>

<element name=」user_name」 type=」std::String」 value=」shenjian」 />

<element name=」user_id」 type=」uint64_t」 value=」123」 />

<element name=」user_age」 type=」uint32_t」 value=」35」 />

</class>

規定好轉換規則，發送方很容易把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

• mc_pack：懂的同窗就懂，不懂的就不懂了，09年用過，傳說各方面都超越protobuf，懂行的同窗能夠說一下現狀

• …

 

RPC-client除了：

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

還包含：

• 發送字節流與接收字節流的部分（上圖中的二、3）

這一部分，又分爲同步調用與異步調用兩種方式，下面一一來進行介紹。

畫外音：搞通透RPC-client確實不容易。

 

同步調用的代碼片斷爲：

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結果，工做線程繼續往下走；

畫外音：請對照架構圖中的1-10步驟閱讀。

 

鏈接池組件有什麼做用？

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,Obj2, 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-client，能夠結合業務場景來選取。

 

總結

什麼是RPC調用？

像調用本地函數同樣，調用一個遠端服務。

 

爲何須要RPC框架？

RPC框架用於屏蔽RPC調用過程當中的序列化，網絡傳輸等技術細節。讓調用方只專一於調用，服務方只專一於實現調用。

 

什麼是序列化？爲何須要序列化？

把對象轉化爲連續二進制流的過程，叫作序列化。磁盤存儲，緩存存儲，網絡傳輸只能操做於二進制流，因此必須序列化。

 

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

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

 

異步RPC-client的核心組件是什麼？

異步RPC-client的核心組件是序列化組件、鏈接池組件、收發隊列、收發線程、上下文管理器、超時管理器。它經過「請求id」來關聯請求包-響應包-回調函數，用上下文管理器來管理上下文，用超時管理器中的timer觸發超時回調，推動業務流程的超時處理。

 

思路比結論重要。