原文: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。】