2. 程式人生 > >Thrift原理簡析(JAVA)

Thrift原理簡析(JAVA)

阿新 • • 發佈：2019-01-24

 Apache Thrift是一個跨語言的服務框架,本質上為RPC，同時具有序列化、反序列化機制；當我們開發的service需要開放出去的時候,就會遇到跨語言呼叫的問題,JAVA語言開發了一個UserService用來提供獲取使用者資訊的服務,如果服務消費端有PHP/Python/C++等,我們不可能為所有的語言都適配出相應的呼叫方式,有時候我們會很無奈的使用Http來作為訪問協議;但是如果服務消費端不能使用HTTP,而且更加傾向於以操作本地API的方式來使用服務,那麼我們就需要Thrift來提供支援.

    不過,如果你的JAVA服務,並沒有跨語言呼叫的需求,那麼使用thrift作為RPC框架,似乎不是最好的選擇,不管thrift是否效能優越,但是它使用起來確實沒有類似於Hessian/CXF等那樣便捷和易於使用.

    本文以UserService為例,描述一下使用thrift的方式,以及其原理..

一. service.thrift

Java程式碼  收藏程式碼
  1. struct User{  
  2.     1:i64 id,  
  3.     2:string name,  
  4.     3:i64 timestamp,  
  5.     4:bool vip    
  6. }  
  7. service UserService{  
  8.     User getById(1:i64 id)  
  9. }  

    你可以將自己的JAVA服務通過".thrift"檔案描述出來,並提供給服務消費端,那麼消費端即可以生成自己的API檔案..Thrift框架目前已經支援大部分主流的語言,.需要注意,因為Thrift考慮到struct/service定義需要相容多種語言的"風格",所以它只支援一些基本的資料型別(比如i32,i64,string等),以及service定義的方法不能重名,即使引數列表不同.(並不是所有的語言都能像JAVA一樣支援過載)

二. 生成API檔案

    首先下載和安裝thrift客戶端,比如在windows平臺下,下載thrift.exe,不過此處需要提醒,不同的thrift客戶端版本生成的API可能不相容.本例使用thrift-0.9.0.exe;通過"--gen"指定生成API所適配的語言.本例項為生成java客戶端API.

Java程式碼  收藏程式碼
  1. //windows平臺下,將API檔案輸出在service目錄下(此目錄需要存在)  
  2. > thrift.exe --gen java -o service service.thrift  

    需要明確的是:Thrift和其他RPC框架不同,thrift在生成的API檔案中,已經描述了"呼叫過程"(即硬編碼),而不是像其他RPC那樣在執行時(runtime)動態解析方法呼叫或者引數.

三. UserService實現類

Java程式碼  收藏程式碼
  1. public class UserServiceImpl implements UserService.Iface {  
  2.     @Override  
  3.     public User getById(long id){  
  4.         System.out.println("invoke...id:" + id);  
  5.         return new User();//for test  
  6.     }  
  7. }  

    實現類,需要放在Thrift server端.  

四.原理簡析

    1. User.java: thrift生成API的能力還是非常的有限,比如在struct中只能使用簡單的資料型別(不支援Date,Collection<?>等),不過我們能從User中看出,它生成的類實現了"Serializable"介面和"TBase"介面.

    其中Serializable介面表明這個類的例項是需要序列化之後在網路中傳輸的,為了不干擾JAVA本身的序列化和反序列化機制,它還重寫了readObject和writeObject方法.不過這對thrift本身並沒有幫助.

    TBase介面是thrift序列化和反序列化時使用的,它的兩個核心方法:read和write.在上述的thrift檔案中,struct定義的每個屬性都有一個序號,比如:1:id,那麼thrift在序列化時,將會根據序號的順序依次將屬性的"名稱 + 值"寫入inputStream中,反序列化也是如此.(具體參見read和write的實現).

Java程式碼  收藏程式碼
  1. //read方法逐個讀取欄位,按照"索引",最終將"struct"物件封裝完畢.  
  2. //write方法也非常類似,按照"索引"順序逐個輸出到流中.  
  3. while (true){  
  4.         schemeField = iprot.readFieldBegin();  
  5.         if (schemeField.type == org.apache.thrift.protocol.TType.STOP) {   
  6.           break;  
  7.         }  
  8.         switch (schemeField.id) {  
  9.           case 1: // ID  
  10.             if (schemeField.type == org.apache.thrift.protocol.TType.I32) {  
  11.               struct.id = iprot.readI32();  
  12.               struct.setIdIsSet(true);  
  13.             } else {   
  14.               org.apache.thrift.protocol.TProtocolUtil.skip(iprot, schemeField.type);  
  15.             }  
  16.             break;  
  17.           case 2: // NAME  
  18.           ..  
  19.         }  
  20. }  

    因為thrift的序列化和反序列化例項資料時,是根據"屬性序號"進行,這可以保證資料在inputstream和outputstream中順序是嚴格的,此外每個struct中"序號"不能重複,但是可以不需要從"1"開始.如果"序號"有重複,將導致無法生成API檔案.這一點也要求API開發者,如果更改了thrift檔案中的struct定義,需要重新生成客戶端API,否則服務將無法繼續使用(可能報錯,也可能資料錯誤).thrift序列化/反序列化的過程和JAVA自帶的序列化機制不同,它將不會攜帶額外的class結構,此外thrift這種序列化機制更加適合網路傳輸,而且效能更加高效.

    2. UserService.Client:  在生成的UserService中,有個Client靜態類,這個類就是一個典型的代理類,此類已經實現了UserService的所有方法.開發者需要使用Client類中的API方法與Thrift server端互動,它將負責與Thrift server的Socket連結中,傳送請求和接收響應.

    需要注意的時,每次Client方法呼叫,都會在一個Socket連結中進行,這就意味著,在使用Client消費服務之前,需要和Thrift server建立有效的TCP連結.(稍後程式碼示例)

    1) 傳送請求:

Java程式碼  收藏程式碼
  1. //參見:TServiceClient  
  2. //API方法呼叫時,傳送請求資料流  
  3. protected void sendBase(String methodName, TBase args) throws TException {  
  4.     oprot_.writeMessageBegin(new TMessage(methodName, TMessageType.CALL, ++seqid_));//首先寫入"方法名稱"和"seqid_"  
  5.     args.write(oprot_);//序列化引數  
  6.     oprot_.writeMessageEnd();  
  7.     oprot_.getTransport().flush();  
  8. }  
  9. protected void receiveBase(TBase result, String methodName) throws TException {  
  10.     TMessage msg = iprot_.readMessageBegin();//如果執行有異常  
  11.     if (msg.type == TMessageType.EXCEPTION) {  
  12.       TApplicationException x = TApplicationException.read(iprot_);  
  13.       iprot_.readMessageEnd();  
  14.       throw x;  
  15.     }//檢測seqid是否一致  
  16.     if (msg.seqid != seqid_) {  
  17.       throw new TApplicationException(TApplicationException.BAD_SEQUENCE_ID, methodName + " failed: out of sequence response");  
  18.     }  
  19.     result.read(iprot_);//反序列化  
  20.     iprot_.readMessageEnd();  
  21. }  

    Thrift提供了簡單的容錯方式:每次方法呼叫,都會在Client端標記一個seqid,這是一個自增的本地ID,在TCP請求時將此seqid追加到流中,同時Server端響應時,也將此seqid原樣返回過來;這樣客戶端就可以根據此值用來判斷"請求--響應"是對應的,如果出現亂序,將會導致此請求以異常的方式結束.

    2) 響應

Java程式碼  收藏程式碼
  1. //參考: TBaseProcessor.java  
  2. @Override  
  3. public boolean process(TProtocol in, TProtocol out) throws TException {  
  4.     TMessage msg = in.readMessageBegin();  
  5.     ProcessFunction fn = processMap.get(msg.name);//根據方法名,查詢"內部類"  
  6.     if (fn == null) {  
  7.       TProtocolUtil.skip(in, TType.STRUCT);  
  8.       in.readMessageEnd();  
  9.       TApplicationException x = new TApplicationException(TApplicationException.UNKNOWN_METHOD, "Invalid method name: '"+msg.name+"'");  
  10.       out.writeMessageBegin(new TMessage(msg.name, TMessageType.EXCEPTION, msg.seqid));  
  11.       x.write(out);//序列化響應結果,直接輸出  
  12.       out.writeMessageEnd();  
  13.       out.getTransport().flush();  
  14.       return true;  
  15.     }  
  16.     fn.process(msg.seqid, in, out, iface);  
  17.     return true;  
  18. }  

    thrift生成的UserService.Processor類,就是server端用來處理請求過程的"代理類";server端從socket中讀取請求需要呼叫的"方法名" +引數列表,並交付給Processor類處理;和其他的RPC呼叫不同的時,thrift並沒有使用類似於"反射機制"的方式來呼叫方法,而是將UserService的每個方法生成一個"內部類":

Java程式碼  收藏程式碼
  1. public static class getById<I extends Iface> extends org.apache.thrift.ProcessFunction<I, getById_args> {  
  2.   public getById() {  
  3.     super("getById");//其中getById為識別符號  
  4.   }  
  5.   public getById_args getEmptyArgsInstance() {  
  6.     return new getById_args();  
  7.   }  
  8.   protected boolean isOneway() {  
  9.     return false;  
  10.   }  
  11.   //實際處理方法  
  12.   public getById_result getResult(I iface, getById_args args) throws org.apache.thrift.TException {  
  13.     getById_result result = new getById_result();  
  14.     result.success = iface.getById(args.id);//直接呼叫例項的具體方法，硬編碼  
  15.     return result;  
  16.   }  
  17. }  

    這個"內部類",將會在Processor初始化的時候,放入到一個map中,此後即可以通過"方法名"查詢,然後呼叫其"getResult"方法了.由此可見，thrift客戶端與server端均沒有使用到“反射機制”，全程都是硬編碼實現，之所以這麼做的原因可能是考慮到效能，也可能是考慮到開發者可以在生成的程式碼基礎上任意調整以適應特殊的情況；如果使用反射機制，將會無法兼顧上述2個情況。

Java程式碼  收藏程式碼
  1. public static class Processor<I extends Iface> extends org.apache.thrift.TBaseProcessor<I> implements org.apache.thrift.TProcessor {  
  2.     public Processor(I iface) {  
  3.       super(iface, getProcessMap(new HashMap<String, org.apache.thrift.ProcessFunction<I, ? extends org.apache.thrift.TBase>>()));  
  4.     }  
  5.     protected Processor(I iface, Map<String,  org.apache.thrift.ProcessFunction<I, ? extends  org.apache.thrift.TBase>> processMap) {  
  6.       super(iface, getProcessMap(processMap));  
  7.     }  
  8.     private static <I extends Iface> Map<String,  org.apache.thrift.ProcessFunction<I, ? extends  org.apache.thrift.TBase>> getProcessMap(Map<String,  org.apache.thrift.ProcessFunction<I, ? extends  org.apache.thrift.TBase>> processMap) {  
  9.       //放入map  
  10.       processMap.put("getById", new getById());  
  11.       return processMap;  
  12.     }  
  13.     ....  
  14. }  

    3) Server端Socket管理和執行策略

Java程式碼  收藏程式碼
  1. TThreadPoolServer  
  2. public void serve() {  
  3.     try {  
  4.       //啟動服務  
  5.       serverTransport_.listen();  
  6.     } catch (TTransportException ttx) {  
  7.       LOGGER.error("Error occurred during listening.", ttx);  
  8.       return;  
  9.     }  
  10.     // Run the preServe event  
  11.     if (eventHandler_ != null) {  
  12.       eventHandler_.preServe();  
  13.     }  
  14.     stopped_ = false;  
  15.     setServing(true);  
  16.     //迴圈,直到被關閉  
  17.     while (!stopped_) {  
  18.       int failureCount = 0;  
  19.       try {  
  20.         //accept客戶端Socket連結,  
  21.         //對於每個新連結,將會封裝成runnable,並提交給執行緒或者執行緒池中執行.  
  22.         TTransport client = serverTransport_.accept();  
  23.         WorkerProcess wp = new WorkerProcess(client);  
  24.         executorService_.execute(wp);  
  25.       } catch (TTransportException ttx) {  
  26.         if (!stopped_) {  
  27.           ++failureCount;  
  28.           LOGGER.warn("Transport error occurred during acceptance of message.", ttx);  
  29.         }  
  30.       }  
  31.     }  
  32.     //....  
  33. }  

    Thrift Server端,設計思路也非常的直接...當前Service server啟動之後,將會以阻塞的方式偵聽Socket連結(程式碼參考TThreadPoolServer),每建立一個Socket連結,都會將此Socket經過封裝之後,放入執行緒池中,本質上也是一個Socket連結對應一個Worker Thread.這個Thread只會處理此Socket中的所有資料請求,直到Socket關閉.

Java程式碼  收藏程式碼
  1. //參考:WorkerProcess  
  2. while (true) {  
  3.     if (eventHandler != null) {  
  4.       eventHandler.processContext(connectionContext, inputTransport, outputTransport);  
  5.     }  
  6.     if(stopped_ || !processor.process(inputProtocol, outputProtocol)) {  
  7.       break;  
  8.     }  
  9. }  

    當有Socket連結不是很多的時候,TThreadPoolServer並不會有太大的效能問題,可以通過指定ThreadPool中執行緒的個數進行簡單的調優..如果Socket連結很多,我們只能使用TThreadedSelectorServer來做支撐,TThreadedSelectorServer內部基於NIO模式,具有非同步的特性,可以極大的提升server端的併發能力;不過在絕大多數情況下,在thrift中使用"非同步"似乎不太容易讓人接受,畢竟這意味著Client端需要阻塞,並且在高併發環境中這個阻塞時間是不可控的.但SelecorServer確實可以有效的提升Server的併發能力，而且在一定程度上可以提升吞吐能力，這或許是我們優化Thrift Server比較可靠的方式之一.

    3. Client端程式碼示例

Java程式碼  收藏程式碼
  1. public class UserServiceClient {  
  2.     public void startClient() {  
  3.         TTransport transport;  
  4.         try {  
  5.             transport = new TSocket("localhost", 1234);  
  6.             TProtocol protocol = new TBinaryProtocol(transport);  
  7.             UserService.Client client = new UserService.Client(protocol);  
  8.             transport.open();  
  9.             User user = client.getById(1000);  
  10.             ////  
  11.             transport.close();  
  12.         } catch (TTransportException e) {  
  13.             e.printStackTrace();  
  14.         } catch (TException e) {  
  15.             e.printStackTrace();  
  16.         }  
  17.     }  
  18. }  

    4. Server端程式碼示例 

Java程式碼  收藏程式碼
  1. public class Server {  
  2.     public void startServer() {  
  3.         try {  
  4.             TServerSocket serverTransport = new TServerSocket(1234);  
  5.             UserService.Processor process = new Processor(new UserServiceImpl());//入口  
  6.             Factory portFactory = new TBinaryProtocol.Factory(true, true);  
  7.             Args args = new<

相關推薦

Thrift原理簡析(JAVA)

 Apache Thrift是一個跨語言的服務框架,本質上為RPC，同時具有序列化、反序列化機制；當我們開發的service需要開放出去的時候,就會遇到跨語言呼叫的問題,JAVA語言開發了一個UserService用來提供獲取使用者資訊的服務,如果服務消費端有PHP/Py

Thrift原理簡析

Apache Thrift是一個跨語言的服務框架,本質上為RPC，同時具有序列化、反序列化機制；當我們開發的service需要開放出去的時候,就會遇到跨語言呼叫的問題,JAVA語言開發了一個UserService用來提供獲取使用者資訊的服務,如果服務消費端有PH

Java堆和棧分配原理簡析以及靜態和非靜態關係簡述

1.棧：函式中定義的基本型別變數以及物件的引用變數都是存在於棧中，當定義了一個變數後，就會在棧中為其分配記憶體空間，當這個變數的作用域結束後，就會釋放此變數的記憶體空間，以便另作他用。棧的優勢是，存取速度比堆要快，僅次於直接位於CPU中的暫存器。但存在棧中的資料

簡析java執行緒池 實現原理

什麼是執行緒池     執行緒池是一種多執行緒處理的形式，通過把處理的任務新增到佇列中，然後在建立執行緒後自動執行這些任務。執行緒池可以同時執行多個任務，如果任務佇列已經滿了，則新來的任務就會排隊等待，執行緒池執行緒的數量永遠不會大於既定最大值。 Exector

番外 01：Spring IoC 實現原理簡析，Java的反射機制，通過類名建立物件

轉載請註明來源 賴賴的部落格 前景概要 在 01 走進Spring，Context、Bean和IoC 中，我們看到了強大的Spring通過ApplicationContext實現了bean工廠（也就是物件工廠），那究竟是怎麼實現的呢，本次給大家寫一個小D

libco hook原理簡析

mysq 協程 調用 blog type 全部 同名 自己的 動態 我們先看一下libco協程庫的特性描述 libco的特性 無需侵入業務邏輯，把多進程、多線程服務改造成協程服務，並發能力得到百倍提升; 支持CGI框架，輕松構建web服務(New);

JavaScript深拷貝實現原理簡析

不出 附加 als 實現 code == 除了 目標 ring Why: 引用類型拷貝為了不出現數據共享問題，需要使用深拷貝。 So: 1.內部原理： 1 function inCopy(obj1,obj2) { 2 var obj1 = obj1

NLP之jieba分詞原理簡析

一、jieba介紹 jieba庫是一個簡單實用的中文自然語言處理分詞庫。 jieba分詞屬於概率語言模型分詞。概率語言模型分詞的任務是：在全切分所得的所有結果中求某個切分方案S，使得P(S)最大。 jieba支援三種分詞模式： 全模式，把句子中所有的可以成詞的詞語都掃描出來,

Vue的資料依賴實現原理簡析

先讓我們從最簡單的一個例項Vue入手: const app = new Vue({ // options 傳入一個選項obj.這個obj即對於這個vue例項的初始化 }) 通過查閱文件，我們可以知道這個options可以接受: 選項/資料

網路庫Retrofit2原理簡析

之前我們分析過了Okhttp這個優秀的網路請求庫，但是在實際的使用時，還是會覺得有很多的不方便，你會發現它跟HttpUrlConnection，或者HttpClient一樣，是一個比較底層的網路請求庫，處理的是底層的網路請求和響應的問題。而我們在業務中要處理上層的邏輯，比如響應內容解析，

讓react用起來更得心應手——（react-router原理簡析）

讓react用起來更得心應手系列文章： 前端路由和後臺路由 在剛入行的時候一直明白什麼單頁面應用是什麼，說白了就是混淆了前臺路由和後臺路由，現在來縷縷它們: 前臺路由:頁面的顯示由前臺js控制，在url的路徑中輸入雜湊值是不會往後臺傳送請求的，所以前臺可以通過將雜湊和頁

LinkedHashMap結構簡析 Java集合之LinkedHashMap

這篇講得比較透徹Java集合之LinkedHashMap。 本文屬於原始碼閱讀筆記。 1.LinkedHashMap簡要介紹。 LinkedHashMap繼承hashMap,並維護一個雙向連結串列保持有序   2.LRU應用 package hashmap_thread; i

暈！常見視訊介面轉接器的原理簡析

https://www.bilibili.com/read/cv277138 數碼 3-9 546閱讀24點贊4評論 Mizuiro-Aqua/ETAC/E/Com 建議閱讀這篇文章，瞭解一下各種視訊介面的傳輸原理。 [ETAC/SS]HDMI?DP?視訊介面該選哪個？談常見視訊介面

Android熱補丁技術—dexposed原理簡析(阿里Hao)

本文由嵌入式企鵝圈原創團隊成員、阿里資深工程師Hao分享。上篇文章《Android無線開發的幾種常用技術》我們介紹了幾種android移動應用開發中的常用技術，其中的熱補丁正在被越來越多的開發團隊所使用

Android的IPC機制（七）—— Socket的原理簡析與使用

綜述 　　在前面的幾篇文章中，我們介紹了許多在Android中有關程序間通訊的方式，但都是在一個裝置上進行的程序間通訊，而這時候我們兩個應用在不同的裝置上的時候，在這個時候我們就不能通過前方介紹的那些方法來解決了。但是我們通過網路進行通訊來處理這個問題。今天就

OkHttp3使用解析：實現下載進度的監聽及其原理簡析

前言 本篇文章主要介紹如何利用OkHttp3實現下載進度的監聽。其實下載進度的監聽，在OkHttp3的官方原始碼中已經有了相應的實現（傳送門），我們可以參考它們的實現方法，並談談它們的實現原理，以便我們更好地理解。 引入依賴 筆者在寫下這篇文章的時候，

簡析java反射

一.什麼是反射：java反射機制是在執行狀態中，對於任意一個類，都能知道這個類的所有屬性和方法；對於任意一個物件，都能呼叫它的任意方法和屬性 ；反射就是把java類中的各個成分對映成一個個物件；它是框架設計的靈魂。二.反射的作用：  1. 編譯：.java->.clas

Laravel 模板引擎（Blade）原理簡析

轉自 http://0x1.im/blog/laravel/laravel-blade-engine.html?utm_source=tuicool&amp;utm_medium=referral 上次提到過，模板引擎一般是要做三件事情： 變數值的輸出（ec

《深入理解java虛擬機器》筆記——簡析java類檔案結構

　　一直不太搞得明白jvm到底是如何進行類載入的，在看資料的過程中迷迷糊糊，在理解類載入之前，首先看看java的類檔案結構到底是怎樣的，都包含了哪些內容。 　　我寫了一個最簡單的java程式，根據這個程式來分析一下.class檔案中到底都存了些什麼。 j

JDK框架簡析--java.util包中的工具類庫

題記 JDK，Java Development Kit。 我們必須先認識到，JDK只是，僅僅是一套Java基礎類庫而已，是Sun公司開發的基礎類庫，僅此而已，JDK本身和我們自行書寫總結的類庫，從技術含量來說，還是在一個層級上，它們都是需要被編譯成位元組碼，在JRE中執