摘要：由于工作需要使用，并且需要根據需求修改源碼，因此必須熟悉執行的流程。目前支持的模型包括使用阻塞的單線程服務器，主要用于調試。

由于工作需要使用thrift，并且需要根據需求修改thrift源碼，因此必須熟悉thrift執行的流程。以下是根據thrift源碼閱讀而得出流程分析。

thrift是一個rpc框架，開發者可以通過thrift自帶的接口定義語言（IDL）來自動生成客戶端和服務端的rpc代碼。
thrift協議棧如下圖所示：

在client和server的最頂層都是用戶自定義的處理邏輯，也就是說用戶只需要編寫用戶邏輯，就可以完成整套的rpc調用流程。用戶邏輯的下一層是thrift自動生成的代碼，這些代碼主要用于結構化數據的解析、發送和接收，同時服務端的自動生成代碼中還包含了rpc請求的轉發（client的A調用轉發到server A函數進行處理）。

從上面可以看出thrift的模塊是分層設計的，在每一個層次可以根據業務的實際需要選擇合適的實現方式。

thrift主要分為以下幾種層次模塊：

底層io模塊，負責實際的數據傳輸，包括socket、文件或壓縮數據流等。

transport層負責以字節流方式發送和接收消息，是底層io模塊在thrift框架中的實現，每一個底層io模塊都會有一個對于TTransport來負責thrift的字節流（byte stream）數據在該io模塊上的傳輸。例如，TSocket對應socket傳輸，TFileTransport對應文件傳輸。

TProtocol主要負責結構化數據組裝成消息，或者從消息結構中讀出結構化數據。TProtocol將一個有類型的數據轉化為特定類型的數據。如int32會被TBinaryProtocol編碼為一個4字節數據，或TBinaryProtocol從TTransport中取出4個字節數據解碼為int32。

TServer負責接收client請求，并將請求轉發到processor進行處理。TServer主要任務是高效地接受client的請求，特別是高并發請求的情況下快速完成請求。

processor負責對client的請求進行響應，包括rpc請求轉發，調用參數解析和用戶邏輯調用，返回值寫回等處理步驟。processor是服務端從thrift框架轉入用戶邏輯的關鍵流程。processor同時也負責向消息結構中寫入數據或讀出數據。

thrift核心庫提供了一個TServer抽象類。

TServer在thrift框架中的主要任務是接收client請求，并轉發到某個processor上進行請求處理。針對不同的訪問規模，thrift提供了不同TServer模型。thrift目前支持的server模型包括：

TSimpleServer：使用阻塞io的單線程服務器，主要用于調試。

TThreadedServer：使用阻塞io的多線程服務器，每一個請求都在一個線程中處理，并發訪問情況下會有很多線程同時運行。

TThreadPoolServer：使用阻塞io的多線程服務器，使用線程池管理處理線程。

TNonBlockingServer：使用非阻塞io的多線程服務器，使用少量線程既可以完成大并發量的請求響應，必須使用TFramedTransport。

TServer對象通常如下工作：

使用TServerTransport獲得一個TTransport。

使用TTransportFactory，可選地將原始傳輸轉換為一個合適的應用傳輸。

調用TProtocolFactory，為TTransport創建一個輸入和輸出。

調用TProcessor對象的process方法。

TTransport是與底層數據傳輸緊密相關的傳輸層。每一種支持的底層傳輸方式都存在一個與之對應的TTransport。在這一層，數據是按字節流處理的，即傳輸層看到的是一個又一個的字節，并把這些字節按順序發送和接收。TTransport并不了解它所傳輸的數據是什么類型，實際上傳輸層也不關心數據是什么類型，只需要按照字節方式對數據進行發送和接收即可。數據類型的解析在TProtocol這一層完成。

TTransport具體的有以下幾個類：

TSocket：使用阻塞的TCP socket進行數據傳輸，也是最常見的模式。

THttpTransport：采用http傳輸協議進行數據傳輸。

TFileTransport：文件（日志）傳輸類，允許client將文件傳給server，允許server將收到的數據寫到文件中。

TZlibTransport：與其他transport配合使用，壓縮后對數據進行傳輸，或者將收到的數據解壓。

TProtocol的主要任務是把TTransport中的字節流轉換為數據流。在TProtocol這一層就會出現具有數據類型的數據，如整型、浮點數、字符串和結構體等。TProtocol中數據雖然有了數據類型，但TProtocol只會按照指定類型將數據讀出和寫入，而對于數據的真正用途，需要在thrift自動生成的server和client中處理。

thrift可以讓用戶選擇客戶端與服務端之間傳輸通信協議的類別，在傳輸協議上總體劃分為文本和二進制傳輸協議，以節約帶寬，提高傳輸效率，一般情況下使用二進制類型的傳輸協議為大多數。常用協議有以下幾種：

TBinaryProtocl：二進制編碼格式

TCompactProtocol：高效率的、密集的二進制編碼格式

TJSONProtocol：使用JSON的數據編碼協議進行數據傳輸

TSimpleJSONProtocol：提供JSON只寫協議，生成的文件很容易通過腳本語言解析

TDebugProtocol：簡單易懂的文本格式，以便于debug

TProcessor主要對TServer中一次請求的inputProtocol和outputProtocol進行操作，也就是從inputProtocol中讀出client的請求數據，向outputProtocol寫入用戶邏輯的返回值。TProcessorprocess是一個非常關鍵的處理函數，因為client所有的rpc調用都會經過該函數處理并轉發。

TProcessor對一次rpc調用的處理流程可以概括為：

TServer接收到rpc請求之后，調用TProcessorprocess進行處理。

TProcessorprocess首先調用TTransport.readMessageBegin接口，讀出rpc調用的名稱和rpc調用類型。如果rpc調用類型是rpc call，則調用TProcessor.process_fn繼續處理，對于未知的rpc調用類型，則拋出異常。

TProcessor.process_fn根據rpc調用名稱，到自己的processMap中查找對應的rpc處理函數。如果存在對應的rpc處理函數，則調用該處理函數繼續進行請求響應。不存在則拋出異常。

而rpc處理函數是rpc請求的最終步驟，主要有以下三個過程：

調用rpc請求參數的解析類，從TProtocol中讀入數據完成參數解析。不管rpc調用的參數有多少個，thrift都會將參數放到一個結構體中。thrift會檢查讀出參數的字段id和字段類型是否與要求的參數匹配。對于不符合要求的參數都會跳過。這樣，rpc接口發生變化之后，舊的處理函數在不做修改的情況下，可以通過跳過不認識的參數，來繼續提供服務。

參數解析完后，調用用戶邏輯，完成真正的請求響應。

用戶邏輯的返回值使用返回值打包類進行打包，寫入TProtocol。

ThriftClient跟TProcessor一樣主要操作inputProtocol和outputProtocol，不同的是thriftClient將rpc調用分為send和receive兩個步驟：

send步驟，將用戶的調用參數作為一個整體的struct寫入TProtocol，并發送到TServer。

send結束后，thriftClient便立即進入receive狀態等待TServer的響應。對于TServer的響應，使用返回值解析類進行返回值解析，完成rpc調用。