原文：http://blog.csdn.net/guxch/article/details/12162131
-----------------------------------------------------------------------------------
【接上文“thrift介紹及應用（一）—介紹”】
六、一個最簡單的實例
Thrift文件（demo.thirft,來自官網）如下：
運行則生成的文件如下：
- demo_constants：這個文件似乎沒有用，可以在其中定義全局變量之類的東西。
- demo_types：類型定義（例子中的structUserProfile）都在這個文件中。
- UserStorage：這個文件比較重要，內容比較多，其中的內如下圖。圖左邊是兩個service方法的傳入傳出參數，注意其中每個的實現都有兩個，一個是帶p的，被用在客戶端代碼中，另一個是不帶p的，被用在服務器端代碼中，其實它們的代碼相當一致（相同的函數部分），不知道thrift這樣做的用意在哪。圖右邊UserStorageIf是消息接口定義，UserStorageIfFactory等是接口的“工廠”。UserStorageNull挺有意思，大概是什么都不做（既然什么都不做，要它做什么呢？）。UserStorageMultiface是將多個UserStorageIf集合起來（vector）處理。對用戶來講，客戶端真正有意義的代碼在UserStorageClient中，寫客戶端時，需要認真查看其接口，在其上編寫自己的業務邏輯。服務器的處理過程在UserStorageProcess類中（但我們自己邏輯在另外的地方）。
- UserStorage_server.skeleton：這個是服務器端的框架（其實它可以運行），我們自己的邏輯（例子中store到數據庫中或從數據庫中retrieve）在UserStorageHandler類中實現，這個類從UserStorageIf繼承而來。文件中還有一個main函數，其中給出了以TSimpleServer形式（單線程）實現的服務器。實際的應用中，UserStorage_server.skeleton這個文件將被拆分，業務邏輯可能有若干文件，服務器端的實現也許要復雜一些，與其他業務構成一個main函數，這里的main可能叫做thriftserver_main更合適一些。
需要強調的是，thrift有自己的網絡傳輸格式，因此thrift應用適合于我們不關心傳輸過程，只關心我們自己的應用層的消息的傳遞（也就是RPC的概念）的場合，如果規定了網絡傳輸協議，thrift并不適合。
其他實際的應用見hadoop和Hbase的Thrift接口說明。
?
【注：本文參考了Mark Slee, Aditya Agarwal and Marc Kwiatkowski寫的“Thrift:Scalable Cross-Language Services Implementation”一文，該文是Thrift的White Paper。】
