thrift 是rpc協議

PC(Remote Procedure Call，遠程過程調用)是建立在Socket之上的,出於一種類比的願望,在一台機器上運行的主程序,可以調用另一台機器上准備好的子程序,就像LPC(本地過程調用).

    越底層，代碼越復雜、靈活性越高、效率越高；越上層，抽象封裝的越好、代碼越簡單、效率越差。Socket和RPC的區別再次說明了這點。

PC(Remote Procedure Call，遠程過程調用)是建立在Socket之上的,出於一種類比的願望,在一台機器上運行的主程序,可以調用另一台機器上准備好的子程序,就像 LPC(本地過程調用).RPC帶來了開發C/S程序的簡單可靠的手段,它通過一種叫XDR的數據表達方法描述數據,程序員書寫偽代碼,然后由 rpcgen程序翻譯為真正的可編譯的C語言源代碼,再編譯成真正的Client端和Server端程序。 
　　RPC作為普遍的C/S開發方 法,開發效率高效,可靠.但RPC方法的基本原則是－－以模塊調用的簡單性忽略通訊的具體細節,以便程序員不用關心C/S之間的通訊協議,集中精力對付實 現過程.這就決定了 RPC生成的通訊包不可能對每種應用都有最恰當的處理辦法,與Socket方法相比,傳輸相同的有效數據,RPC占用更多的網絡帶寬. 
　　RPC是在Socket的基礎上實現的,它比socket需要更多的網絡和系統資源.另外,在對程序優化時,程序員雖然可以直接修改由rpcgen產生的令人費解的源程序,但對於追求程序設計高效率的RPC而言,獲得的簡單性則被大大削弱. 
RPC與是Socket的類比 

 

什么是RPC

從網絡協議來說，Http協議與Rpc同屬於應用層， 他們的底層都是tcp協議。

      RPC（即Remote Procedure Call，遠程過程調用）和HTTP（HyperText Transfer Protocol，超文本傳輸協議）他們最本質的區別，就是RPC主要工作在TCP協議之上，而HTTP服務主要是工作在HTTP協議之上，我們都知道HTTP協議是在傳輸層協議TCP之上的，所以效率來看的話，RPC當然是要更勝一籌。

1、RPC服務

（1）RPC架構
      先說說RPC服務的基本架構吧。一個完整的RPC架構里面包含了四個核心的組件，分別是Client ,Server,Client Stub以及Server Stub，這個Stub大家可以理解為存根。分別說說這幾個組件：
    1)客戶端（Client），服務的調用方。
    2)服務端（Server），真正的服務提供者。
    3)客戶端存根，存放服務端的地址消息，再將客戶端的請求參數打包成網絡消息，然后通過網絡遠程發送給服務方。
    4)服務端存根，接收客戶端發送過來的消息，將消息解包，並調用本地的方法。

      RPC主要是用在大型企業里面，因為大型企業里面系統繁多，業務線復雜，而且效率優勢非常重要的一塊，這個時候RPC的優勢就比較明顯了。實際的開發當中是這么做的，項目一般使用maven來管理。比如我們有一個處理訂單的系統服務，先聲明它的所有的接口（這里就是具體指Java中的interface），然后將整個項目打包為一個jar包，服務端這邊引入這個二方庫，然后實現相應的功能，客戶端這邊也只需要引入這個二方庫即可調用了。為什么這么做？主要是為了減少客戶端這邊的jar包大小，因為每一次打包發布的時候，jar包太多總是會影響效率。另外也是將客戶端和服務端解耦，提高代碼的可移植性。

（2）同步調用與異步調用
      什么是同步調用？什么是異步調用？同步調用就是客戶端等待調用執行完成並返回結果。異步調用就是客戶端不等待調用執行完成返回結果，不過依然可以通過回調函數等接收到返回結果的通知。如果客戶端並不關心結果，則可以變成一個單向的調用。這個過程有點類似於Java中的callable和runnable接口，我們進行異步執行的時候，如果需要知道執行的結果，就可以使用callable接口，並且可以通過Future類獲取到異步執行的結果信息。如果不關心執行的結果，直接使用runnable接口就可以了，因為它不返回結果，當然啦，callable也是可以的，我們不去獲取Future就可以了。

（3）流行的RPC框架

    目前流行的開源RPC框架還是比較多的。下面重點介紹三種：
    1）gRPC是Google最近公布的開源軟件，基於最新的HTTP2.0協議，並支持常見的眾多編程語言。 我們知道HTTP2.0是基於二進制的HTTP協議升級版本，目前各大瀏覽器都在快馬加鞭的加以支持。 這個RPC框架是基於HTTP協議實現的，底層使用到了Netty框架的支持。
    2）Thrift是Facebook的一個開源項目，主要是一個跨語言的服務開發框架。它有一個代碼生成器來對它所定義的IDL定義文件自動生成服務代碼框架。用戶只要在其之前進行二次開發就行，對於底層的RPC通訊等都是透明的。不過這個對於用戶來說的話需要學習特定領域語言這個特性，還是有一定成本的。
    3）Dubbo是阿里集團開源的一個極為出名的RPC框架，在很多互聯網公司和企業應用中廣泛使用。協議和序列化框架都可以插拔是及其鮮明的特色。同樣 的遠程接口是基於Java Interface，並且依托於spring框架方便開發。可以方便的打包成單一文件，獨立進程運行，和現在的微服務概念一致。

2、HTTP服務

（1）HTTP接口
      相比RPC，HTTP接口開發也就是我們常說的RESTful風格的服務接口。的確，對於在接口不多、系統與系統交互較少的情況下，解決信息孤島初期常使用的一種通信手段；優點就是簡單、直接、開發方便。利用現成的http協議進行傳輸。做后台接口開發的時候，需要寫一份接口文檔，嚴格地標明輸入輸出是什么？說清楚每一個接口的請求方法，以及請求參數需要注意的事項等。
      比如這個例子：POST http://www.httpexample.com/restful/buyer/info/share
      接口可能返回一個JSON字符串或者是XML文檔。然后客戶端再去處理這個返回的信息，從而可以比較快速地進行開發。但是對於大型企業來說，內部子系統較多、接口非常多的情況下，RPC框架的好處就顯示出來了，首先就是長鏈接，不必每次通信都要像http一樣去3次握手什么的，減少了網絡開銷；其次就是RPC框架一般都有注冊中心，有豐富的監控管理；發布、下線接口、動態擴展等，對調用方來說是無感知、統一化的操作。

（2）restful：
      對應的中文是rest式的;Restful web service是一種常見的rest的應用,是遵守了rest風格的web服務;rest式的web服務是一種ROA(The Resource-Oriented Architecture)(面向資源的架構)。為什么會出現Restful？
    1）在Restful之前的操作：
    http://127.0.0.1/user/query   GET  根據用戶id查詢用戶數據
    http://127.0.0.1/user/save    POST 新增用戶
    http://127.0.0.1/user/update POST 修改用戶信息
    http://127.0.0.1/user/delete  GET/POST 刪除用戶信息
    2）RESTful用法：
    http://127.0.0.1/user  GET  根據用戶id查詢用戶數據
    http://127.0.0.1/user  POST 新增用戶
    http://127.0.0.1/user  PUT 修改用戶信息
    http://127.0.0.1/user  DELETE 刪除用戶信息
    之前的操作是沒有問題的,大神認為是有問題的,有什么問題呢?你每次請求的接口或者地址,都在做描述,例如查詢的時候用了query,新增的時候用了save,其實完全沒有這個必要,我使用了get請求,就是查詢.使用post請求,就是新增的請求,我的意圖很明顯,完全沒有必要做描述,這就是為什么有了restful。

3、總結

    RPC服務和HTTP服務還是存在很多的不同點的，一般來說，RPC服務主要是針對大型企業的，而HTTP服務主要是針對小企業的，因為RPC效率更高，而HTTP服務開發迭代會更快。總之，選用什么樣的框架不是按照市場上流行什么而決定的，而是要對整個項目進行完整地評估，從而在仔細比較兩種開發框架對於整個項目的影響，最后再決定什么才是最適合這個項目的。一定不要為了使用RPC而每個項目都用RPC，而是要因地制宜，具體情況具體分析。

 

 

 

 

從概念上來說，RPC是遠程過程調用，而其實Http其實也是屬於RPC調用的一種。RPC是一種網絡編程的模式，是我們程序員將對遠程服務器調用的抽象，而且一般需要實現服務注冊發現機制、序列化反序列化機制、方法派發機制，這些一般都需要我們使用的RPC框架（比如Thrift）默認實現的。

為什么要使用RPC

http協議其實是屬於面向桌面瀏覽器的一個通信協議，對於緩存，冪等或者Cookies相關的方面做了很多的事情。但是對於服務器之間直接的交互，Rpc就能夠體現出來他的優勢了。

• 自定義協議，減少數據傳輸：我們大概看一下http協議。請求行，請求頭部，請求數據，空行。很明顯對於遠程調用場景，我們對於請求行的依賴不是特別的強，那么這一部分在我們應用場景下，將會成為負擔，但是http協議又是固定的，我們也不可能隨便修改協議的格式。所以，通過rpc協議我們可以精簡請求的數據，來盡可能少的傳輸我們的數據。當前，rpc也可以通過http協議來進行傳輸。

 

 

• 使用長連接：直接基於socket進行連接，不用每個請求都重新走三次握手的流程

• Thrift默認提供了數據與實體類的轉換，不需要我們顯示的進行數據與實體類的轉換。

• 性能差距： 

• 6、測試結果對比
  網絡環境，內網千兆，依次循環1000次，發送數據包為1k
  
  http：
  http1000: 4879ms
  thrift：
  thrift1000: 1254ms
  網絡環境，內網千兆，依次循環1000次，發送數據包為100k
  
  http：
  http1000: 16924ms
  thrift：
  thrift1000: 2105ms
  網絡環境，內網千兆，並行執行1000次，發送數據包為1k，就是將async改為parallel
  
  http：
  http1000: 4265ms
  thrift：
  thrift1000: 437ms
  總結一下，在內網大數據包的傳輸上，還是用thrift性能更出色

  參考：小測thrift和http在node.js中的性能對比

OSI網絡結構的七層模型

各層的具體描述如下：

　　第七層：應用層     定義了用於在網絡中進行通信和數據傳輸的接口 - 用戶程式；提供標准服務，比如虛擬終端、文件以及任務的傳輸 和處理； 
　　第六層：表示層     掩蓋不同系統間的數據格式的不同性； 指定獨立結構的數據傳輸格式； 數據的編碼和解碼；加密和解密；壓縮和 解壓縮 
　　第五層：會話層     管理用戶會話和對話； 控制用戶間邏輯連接的建立和掛斷；報告上一層發生的錯誤 
　　第四層：傳輸層     管理網絡中端到端的信息傳送； 通過錯誤糾正和流控制機制提供可靠且有序的數據包傳送； 提供面向無連接的數 據包的傳送； 
　　第三層：網絡層     定義網絡設備間如何傳輸數據； 根據唯一的網絡設備地址路由數據包；提供流和擁塞控制以防止網絡資源的損耗 
　　第二層：數據鏈路層 定義操作通信連接的程序； 封裝數據包為數據幀； 監測和糾正數據包傳輸錯誤 
　　第一層：物理層      定義通過網絡設備發送數據的物理方式； 作為網絡媒介和設備間的接口；定義光學、電氣以及機械特性。

 在上述7層中，http協議是應用層協議。HTTP協議是超文本傳送協議(HyperText Transfer Protocol)的縮寫，它是萬維網(World Wide Web,www,也簡稱為Web)的基礎。HTTP協議設計之初就是為了實現Web的想法。HTTP協議位於TCP/IP協議棧的應用層。基於HTTP協議的客戶/服務器模式的信息交換過程，分四個過程：建立連接、發送請求信息、發送響應信息、關閉連接。

而關於RPC的基本概念介紹如下：

英文原義：Remote Procedure Call Protocol
中文釋義：（RFC-1831）遠過程調用協議
　　 注解：一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議。RPC協議假定某些傳輸協議的存在，如TCP或UDP，為通信程序之間攜帶信息數據。在OSI網絡通信模型中，RPC跨越了傳輸層和應用層。RPC使得開發包括網絡分布式多程序在內的應用程序更加輕易。
　　 RPC采用客戶機/服務器模式。請求程序就是一個客戶機，而服務提供程序就是一個服務器。首先，調用進程發送一個有進程參數的調用信息到服務進程，然后等待應答信息。在服務器端，進程保持睡眠狀態直到調用信息的到達為止。當一個調用信息到達，服務器獲得進程參數，計算結果，發送答復信息，然后等待下一個調用信息，最后，客戶端調用過程接收答復信息，獲得進程結果，然后調用執行繼續進行。
RPC信息協議由兩個不同結構組成：調用信息和答復信息。

 

同時也注意到 了 這樣的信息

遠程通信的幾種選擇（RPC，Webservice，RMI，JMS的區別）

幾種基於HTTP協議的RPC性能比較

參考：RPC和Socket的區別

 

RPC(Remote Procedure Call，遠程過程調用)是建立在Socket之上的,出於一種類比的願望,在一台機器上運行的主程序,可以調用另一台機器上准備好的子程序,就像LPC(本地過程調用).

    越底層，代碼越復雜、靈活性越高、效率越高；越上層，抽象封裝的越好、代碼越簡單、效率越差。Socket和RPC的區別再次說明了這點。

不論是程序員在編寫基於C/S(客戶端服務器)的程序時,還是網絡工程師在處理RPC問題時,他們問的最多的就是RPC和Socket有什么區別和聯系? 
　 　RPC(Remote Procedure Call，遠程過程調用)是建立在Socket之上的,出於一種類比的願望,在一台機器上運行的主程序,可以調用另一台機器上准備好的子程序,就像 LPC(本地過程調用).RPC帶來了開發C/S程序的簡單可靠的手段,它通過一種叫XDR的數據表達方法描述數據,程序員書寫偽代碼,然后由 rpcgen程序翻譯為真正的可編譯的C語言源代碼,再編譯成真正的Client端和Server端程序。 
　　RPC作為普遍的C/S開發方 法,開發效率高效,可靠.但RPC方法的基本原則是－－以模塊調用的簡單性忽略通訊的具體細節,以便程序員不用關心C/S之間的通訊協議,集中精力對付實 現過程.這就決定了 RPC生成的通訊包不可能對每種應用都有最恰當的處理辦法,與Socket方法相比,傳輸相同的有效數據,RPC占用更多的網絡帶寬. 
　　RPC是在Socket的基礎上實現的,它比socket需要更多的網絡和系統資源.另外,在對程序優化時,程序員雖然可以直接修改由rpcgen產生的令人費解的源程序,但對於追求程序設計高效率的RPC而言,獲得的簡單性則被大大削弱. 
RPC與是Socket的類比

 

服務化有什么好處？

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

• 服務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除了：

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

還包含：

發送字節流與接收字節流的部分（上圖中的2、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觸發超時回調，推進業務流程的超時處理。

思路比結論重要。

參考：離不開的微服務架構，脫不開的RPC細節（值得收藏）

參考：HTTP與RPC（Thrift）

參考：rpc與http的區別

參考：Http和RPC區別

參考：什么是RPC