Thrift架构~从图中理解thrift，它事实上是一种远程过程调用

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组件注入的问题，敬请期待！