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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TServer對象通常如下工作：

使用TServerTransport獲得一個TTransport。

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

調用TProtocolFactory，為TTransport創(chuàng)建一個輸入和輸出。

調用TProcessor對象的process方法。

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

TTransport具體的有以下幾個類：

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

THttpTransport：采用http傳輸協(xié)議進行數(shù)據(jù)傳輸。

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

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

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

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

TBinaryProtocl：二進制編碼格式

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

TJSONProtocol：使用JSON的數(shù)據(jù)編碼協(xié)議進行數(shù)據(jù)傳輸

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

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

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

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

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

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

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

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

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

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

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

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

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

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