IT工程師數位筆記本

thrift為我們簡化了tcp通訊，它可以使用我們方便的建立各種語言的服務端與客戶端，并實現客戶端對服務器的遠程過程調用，簡單的說就是服務器通過thrift架構對外開放一些接口，并自己實現這些接口，如操作文件，操作圖片，文件下載等等，然后客戶端通過thrift架構生成的接口，去簡單的調用它，我們不需要關心服務端實現的方式，我們只關注它對外提供的接口，這也是面向對象的好處，呵呵。

下面是我對thrift的理解，并用圖示來表示一下，請看圖：

對于thrift的使用者來說，我們關心的是接口，或者說方法簽名，而不需要太過關心數據，這是正確的，數據本身在傳遞的過程中就應該被保護起來，用面向對象的說法就是封裝起來，不對外公開，這可以大大保證數據的安全性，使用thrift架構，我們不需要對數據結構

進行破壞，在之前的10幾年，我們在進行數據通訊時，最常見的作法就是使用類型標識符來區別個個數據的作用，如，1表示文件上業務，2表示文件下載業務，其實這樣做了之后我們的數據結構是混亂的，而有了thrift之后，我們的數據實現是獨立的，是職責分明的，當然也是受保護的，即，文件上傳與文件下載的數據是相互獨立的，呵呵。

我們可以通過方法簽名來看一下二者的區別：

thrift 環境下的

bool Upload(DataSegment dataSegment);
DataSegment Download(DataSegment dataSegment);

普通socket通訊的

bool Send(byte[] data,string type);
byte[] Receive(string fileName,string type);

從上面的兩處代碼來看，我們可以看出其中的不同了，事實上，thrift是將業務功能代碼最小化了，以業務為單位將代碼分離，相不影響，而后者的代碼，它的業務一定會混在一個send方法里，當然你可以使用一些設計模塊來實現解耦，但對于我們程序員來說，程序的

可讀性一定會受到不少影響，呵呵！

下一節，我們將會一起討論在項目中實現thrift環境的AOP組件注入的問題，敬請期待！