RPC框架之Thrift分析

1、簡介

一、Thrift是Facebook開發的跨語言的RPC服務框架。隨後貢獻給Apache開源組織。成爲RPC服務的主流框架。

二、特色：

 優勢：

      跨語言，支持java、c/c++、python等多種編程語言

      IDL定義接口函數和數據類型

      支持二進制傳輸，效率高

      支持多種工做模型，單線程模型、線程池模型、非阻塞模型

 

 缺點：

      文檔很少

      各版本不兼容，升級不方便

2、分析

Thrift分爲服務端（server）和客戶端（Client）兩個對應的部分。代碼分層設計，分爲Transport（傳輸層）、Protocol（協議層）、Processor（處理層）和Server（服務層）。

一、主要的處理流程：

各部分類圖：

傳輸層

TTransport：客戶端傳輸層抽象基礎類，主要方法：read、write、flush、open、close。read、write方法爲核心

TSocket 與 TNonBlockingSocket：分別是基於BIO和NIO客戶端傳輸類。 TSocket持有Socket，設置輸入輸出流使用1K的BufferedStream，

TNonBlockingSocket持有SocketChannel，read和write方法裏的byte會每次被wrap成一個ByteBuffer。

TServerSocket 與 TNonBlockingServerSocket：分別是基於BIO和NIO服務端傳輸類。TServerSocket持有ServerSocket，TNonBlockingServerSocket持有ServerSocketChannel。

TFramedTransport與TFastFramedTransport：將數據封裝Frame(幀)實現的， TFastFramedTransport效率內存使用率高，使用了自動擴展長度的buffer

TZlibTransport：讀取時按1K爲單位將數據讀出並調用JDK的zip函數進行解壓再放到Buffer，寫入時，在flush時先zip再寫入。

TSaslClientTransport與TSaslServerTransport：提供SSL校驗

協議層：

1)IDL 定義支持類型：

   基本類型: i16，i32，i64, double, boolean，byte，byte[], String。

   容器類型: List，Set，Map，TList/TSet/TMap類包含其元素的類型與元素的總個數。

   Struct類型：即面向對象的Class，繼承於TBase。TStruct類有Name屬性，還含有一系列的Field。TField類有本身的Name，類型，順序id屬性。

   Exception類型：Struct，繼承於TException這個checked exception。

   Enum類型：傳輸時是個i32。

   Message類型：封裝往返的RPC消息。TMessage類包含Name，類型(請求，返回，異常，ONEWAY)與seqId屬性。

2) 類分析：

TProtocol：基礎抽象類，擁有對IDL定義支持類型read和write方法，對於結構類型先readxxBegin()(或writexxBegin()),結束時調用readxxEnd() (或readxxEnd())方法。

TBinaryProtocol：二進制流傳輸協議類，把各種型轉換成byte數組，交給TTransport傳輸。

TCompactProtocol：壓縮方法二進制協議類，將Integer按照ZigZag

TTupleProtocol：繼承TCompactProtocol，Struct使用時更省空間

TJSONProtocol：Json格式協議類，將數據封裝成Json格式，再轉爲byte數組交給傳輸層。

TSimpleJSONProtocol：Json格式協議類，但只支持寫的功能。

TProtocolFactory：TProtocol的工廠基礎類，每一個TProtocol實現類均有一個工廠實現。

Server層

TServer ：基礎抽象類，實際上相似一個容器，持有TProcessor、TTransport、TProtocol的工廠對象，AbstractServerArgs做爲參數抽象類，提供一個serve()方法,用於啓動服務，stop()方法中止服務。

TSimpleServer :單線程阻塞式服務，只用於作測試的簡單服務類。

TNonblockingServer：支持非阻塞單線程服務模型，基於NIO的Select實現。

THsHaServer：繼承TNonblockingServer。單線程處理I/O,線程池請求的處理。

TThreadedSelectorServer： 繼承AbstractNonblockingServer。維持兩個線程池，一個線程池處理I/O,另外一個線程池處理請求。  TThreadPoolServer：專門的線程接受請求並交給線程池處理，完成後線程池鏈接釋放。請求處理線程和I/O線程爲同一線程。阻塞式線程池模型。

以上五種模型參見：

https://github.com/m1ch1/mapkeeper/wiki/Thrift-Java-Servers-Compared

http://blog.csdn.net/houjixin/article/details/42779915

Processer層

TProcessor：基礎接口，抽象方法process(TProtocol in, TProtocol out)

TBaseProcessor ：基礎抽象類，持有processMap對象，key爲方法名標示，value爲方法（ProcessFunction的實例），實現TProcessor的方法process，in.readMessageBegin()拿到傳過來的方法名，若是存在則準備交給具體業務類執行，不然拋出無效方法的異常。

Processor：IDL生成，實現TProcessor接口並繼承TBaseProcessor類。

TAsyncProcessor：異步處理接口，抽象方法process(final AsyncFrameBuffer fb) TBaseAsyncProcessor：異步處理抽象類，持有processMap對象，key爲方法名標示，value爲方法（AsyncProcessFunction的實例），實現TAsyncProcessor的方法process(final AsyncFrameBuffer fb)，AsyncProcessFunction的getResultHandler方法拿到一個AsyncMethodCallback，帶執行start方法後經過sendResponse方法返回。 AsyncProcessor 由IDL生成，實現TAsyncProcessor接口並繼承TAsyncProcessor類。

TProcessorFactory： 構建 TProcessor的工廠類

總結

Thrift代碼分析，能夠借鑑和學習的方面：

一、代碼分層設計，Thrift分傳輸層、協議層、處理層、服務層四個層設計，上層只依賴下層，方便擴展和維護。 二、基於接口編程和多用抽象工廠設計，每層之間都有一個核心的接口，各個實體初始化基本是使用工廠設計模式，下降耦合。

三、基於BIO和NIO，知足不一樣情景，便於性能調優。