跨語言服務部署框架Thrift簡介[轉]

參考文檔: http://dongxicheng.org/search-engine/thrift-framework-intro/

 

Thrift是一個跨語言的服務部署框架，最初由Facebook於2007年開發，2008年進入Apache開源項目。Thrift經過一箇中間語言(IDL, 接口定義語言)來定義RPC的接口和數據類型，而後經過一個編譯器生成不一樣語言的代碼（目前支持C++,Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk和OCaml）,並由生成的代碼負責RPC協議層和傳輸層的實現。

Thrift的系統架構

Thrift包含一個完整的堆棧結構用於構建客戶端和服務器端。下圖描繪了 Thrift 的總體架構。

如圖所示，圖中黃色部分是用戶實現的業務邏輯，褐色部分是根據 Thrift 定義的服務接口描述文件生成的客戶端和服務器端代碼框架，紅色部分是根據 Thrift 文件生成代碼實現數據的讀寫操做。紅色部分如下是 Thrift 的傳輸體系、協議以及底層 I/O 通訊，使用 Thrift 能夠很方便的定義一個服務而且選擇不一樣的傳輸協議和傳輸層而不用從新生成代碼。

Thrift其實是實現了C/S模式，經過代碼生成工具將接口定義文件生成服務器端和客戶端代碼（能夠爲不一樣語言），從而實現服務端和客戶端跨語言的支持。用戶在Thirft描述文件中聲明本身的服務，這些服務通過編譯後會生成相應語言的代碼文件，而後用戶實現服務（客戶端調用服務，服務器端提服務）即可以了。其中protocol（協議層, 定義數據傳輸格式，能夠爲二進制或者XML等）和transport（傳輸層，定義數據傳輸方式，能夠爲TCP/IP傳輸，內存共享或者文件共享等）被用做運行時庫。

Thrift代碼產生方式

Thrift的網絡棧以下所示：

• Transport層提供了一個簡單的網絡讀寫抽象層。這使得thrift底層的transport從系統其它部分（如：序列化/反序列化）解耦。Transport接口提供的方法：open,close,read,write,flush。
• Protocol抽象層定義了一種將內存中數據結構映射成可傳輸格式的機制。換句話說，Protocol定義了datatype怎樣使用底層的Transport對本身進行編解碼。所以，Protocol的實現要給出編碼機制並負責對數據進行序列化。
• Processor封裝了從輸入數據流中讀數據和向數據數據流中寫數據的操做。讀寫數據流用Protocol對象表示。Processor的結構體很是簡單:與服務相關的processor實現由編譯器產生。Processor主要工做流程以下：從鏈接中讀取數據（使用輸入protocol），將處理受權給handler（由用戶實現），最後將結果寫到鏈接上（使用輸出protocol）。
• Server將以上全部特性集成在一塊兒：
  • 建立一個transport對象
  • 爲transport對象建立輸入輸出protocol
  • 基於輸入輸出protocol建立processor
  • 等待鏈接請求並將之交給processor處理

Thrift支持的數據類型

Thrift 腳本可定義的數據類型包括如下幾種類型：

• Base Types：基本類型
• Struct：結構體類型
• Container：容器類型，即List、Set、Map
• Exception：異常類型
• Service： 定義對象的接口，和一系列方法

Thrift支持的傳輸格式

Thrift可讓你選擇客戶端與服務端之間傳輸通訊協議的類別，在傳輸協議上整體上劃分爲文本(text)和二進制(binary)傳輸協議, 爲節約帶寬，提供傳輸效率，通常狀況下使用二進制類型的傳輸協議爲多數，但有時會仍是會使用基於文本類型的協議，這須要根據項目/產品中的實際需求：

• TBinaryProtocol – 二進制編碼格式進行數據傳輸。
• TCompactProtocol –高效率的、密集的二進制編碼格式進行數據傳輸，這種協議很是有效的，使用Variable-Length Quantity (VLQ) 編碼對數據進行壓縮。
• TJSONProtocol – 使用JSON的數據編碼協議進行數據傳輸。
• TSimpleJSONProtocol –只提供JSON只寫的協議，適用於經過腳本語言解析
• TDebugProtocol – 在開發的過程當中幫助開發人員調試用的，以文本的形式展示方便閱讀。

使用Thrift和其餘方式的所產生的內容大小比較結果以下：

在上圖中咱們能明顯看出，最臃腫的是RMI，其次是xml，使用Thrift的TCompactProtocol協議和Google 的 Protocol Buffers 相差的不算太多，相比而言仍是Google 的 Protocol Buffers效果最佳。

使用Thrift 中的協議和其餘方式的所產生的運行開銷比較結果以下：

在上圖中咱們能明顯看出，最佔資源是REST-XML協議，使用Thrift的TCompactProtocol協議和Google 的 Protocol Buffers 相差的不算太多，相比而言Thrift的TCompactProtocol協議效果最佳。

Thrift支持的傳輸方式

• TSocket- 使用堵塞式I/O進行傳輸，也是最多見的模式。
• TFramedTransport- 使用非阻塞方式，按塊的大小，進行傳輸，相似於Java中的NIO。
• TFileTransport- 顧名思義按照文件的方式進程傳輸，雖然這種方式不提供Java的實現，可是實現起來很是簡單。
• TMemoryTransport- 使用內存I/O，就比如Java中的ByteArrayOutputStream實現。
• TZlibTransport- 使用執行zlib壓縮，不提供Java的實現。

Thrift支持的服務模型

• TSimpleServer – 單線程服務器端使用標準的堵塞式I/O。經常使用於測試。
• TThreadPoolServer – 多線程服務器端使用標準的堵塞式I/O。
• TNonblockingServer – 多線程服務器端使用非堵塞式I/O，而且實現了Java中的NIO通道。（需使用TFramedTransport數據傳輸方式）

參考資料：

• http://thrift.apache.org/
• http://jnb.ociweb.com/jnb/jnbJun2009.html