thrift介绍及应用（二）—简单应用

【接上文“thrift介绍及应用（一）—介绍”】

六、一个最简单的实例

Thrift文件（demo.thirft,来自官网）如下：

struct UserProfile 
{
  1:i32 uid,
  2:string name,
  3:string blurb
}

service UserStorage 
{
 void store(1: UserProfile user),
 UserProfile retrieve(1: i32 uid)
}

运行

thrift –gen cpp demo.thrift

则生成的文件如下：

• 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。】