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

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

thrift是一個(gè)rpc框架，開(kāi)發(fā)者可以通過(guò)thrift自帶的接口定義語(yǔ)言（IDL）來(lái)自動(dòng)生成客戶(hù)端和服務(wù)端的rpc代碼。
thrift協(xié)議棧如下圖所示：

在client和server的最頂層都是用戶(hù)自定義的處理邏輯，也就是說(shuō)用戶(hù)只需要編寫(xiě)用戶(hù)邏輯，就可以完成整套的rpc調(diào)用流程。用戶(hù)邏輯的下一層是thrift自動(dòng)生成的代碼，這些代碼主要用于結(jié)構(gòu)化數(shù)據(jù)的解析、發(fā)送和接收，同時(shí)服務(wù)端的自動(dòng)生成代碼中還包含了rpc請(qǐng)求的轉(zhuǎn)發(fā)（client的A調(diào)用轉(zhuǎn)發(fā)到server A函數(shù)進(jìn)行處理）。

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

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

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

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

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

TServer負(fù)責(zé)接收client請(qǐng)求，并將請(qǐng)求轉(zhuǎn)發(fā)到processor進(jìn)行處理。TServer主要任務(wù)是高效地接受client的請(qǐng)求，特別是高并發(fā)請(qǐng)求的情況下快速完成請(qǐng)求。

processor負(fù)責(zé)對(duì)client的請(qǐng)求進(jìn)行響應(yīng)，包括rpc請(qǐng)求轉(zhuǎn)發(fā)，調(diào)用參數(shù)解析和用戶(hù)邏輯調(diào)用，返回值寫(xiě)回等處理步驟。processor是服務(wù)端從thrift框架轉(zhuǎn)入用戶(hù)邏輯的關(guān)鍵流程。processor同時(shí)也負(fù)責(zé)向消息結(jié)構(gòu)中寫(xiě)入數(shù)據(jù)或讀出數(shù)據(jù)。

thrift核心庫(kù)提供了一個(gè)TServer抽象類(lèi)。

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

TSimpleServer：使用阻塞io的單線程服務(wù)器，主要用于調(diào)試。

TThreadedServer：使用阻塞io的多線程服務(wù)器，每一個(gè)請(qǐng)求都在一個(gè)線程中處理，并發(fā)訪問(wèn)情況下會(huì)有很多線程同時(shí)運(yùn)行。

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

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

TServer對(duì)象通常如下工作：

使用TServerTransport獲得一個(gè)TTransport。

使用TTransportFactory，可選地將原始傳輸轉(zhuǎn)換為一個(gè)合適的應(yīng)用傳輸。

調(diào)用TProtocolFactory，為T(mén)Transport創(chuàng)建一個(gè)輸入和輸出。

調(diào)用TProcessor對(duì)象的process方法。

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

TTransport具體的有以下幾個(gè)類(lèi)：

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

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

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

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

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

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

TBinaryProtocl：二進(jìn)制編碼格式

TCompactProtocol：高效率的、密集的二進(jìn)制編碼格式

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

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

TDebugProtocol：簡(jiǎn)單易懂的文本格式，以便于debug

TProcessor主要對(duì)TServer中一次請(qǐng)求的inputProtocol和outputProtocol進(jìn)行操作，也就是從inputProtocol中讀出client的請(qǐng)求數(shù)據(jù)，向outputProtocol寫(xiě)入用戶(hù)邏輯的返回值。TProcessorprocess是一個(gè)非常關(guān)鍵的處理函數(shù)，因?yàn)閏lient所有的rpc調(diào)用都會(huì)經(jīng)過(guò)該函數(shù)處理并轉(zhuǎn)發(fā)。

TProcessor對(duì)一次rpc調(diào)用的處理流程可以概括為：

TServer接收到rpc請(qǐng)求之后，調(diào)用TProcessorprocess進(jìn)行處理。

TProcessorprocess首先調(diào)用TTransport.readMessageBegin接口，讀出rpc調(diào)用的名稱(chēng)和rpc調(diào)用類(lèi)型。如果rpc調(diào)用類(lèi)型是rpc call，則調(diào)用TProcessor.process_fn繼續(xù)處理，對(duì)于未知的rpc調(diào)用類(lèi)型，則拋出異常。

TProcessor.process_fn根據(jù)rpc調(diào)用名稱(chēng)，到自己的processMap中查找對(duì)應(yīng)的rpc處理函數(shù)。如果存在對(duì)應(yīng)的rpc處理函數(shù)，則調(diào)用該處理函數(shù)繼續(xù)進(jìn)行請(qǐng)求響應(yīng)。不存在則拋出異常。

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

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

參數(shù)解析完后，調(diào)用用戶(hù)邏輯，完成真正的請(qǐng)求響應(yīng)。

用戶(hù)邏輯的返回值使用返回值打包類(lèi)進(jìn)行打包，寫(xiě)入TProtocol。

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

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

send結(jié)束后，thriftClient便立即進(jìn)入receive狀態(tài)等待TServer的響應(yīng)。對(duì)于TServer的響應(yīng)，使用返回值解析類(lèi)進(jìn)行返回值解析，完成rpc調(diào)用。