thrift源码解析之protocol

最新推荐文章于 2022-07-08 08:40:54 发布

跟屁虫

最新推荐文章于 2022-07-08 08:40:54 发布

阅读量663

点赞数 1

分类专栏： RPC框架

原文链接：https://www.cnblogs.com/brucewoo/archive/2012/06/05/2535473.html

版权

RPC框架专栏收录该内容

16 篇文章 1 订阅

订阅专栏

文章目录

前言
概览：
- 类继承架构分析
二进制协议类TBinaryProtocolT

前言

thrift文章整理：
1.thrift简介
2.thrift源码解析之compiler
3.thrift源码解析之processor
4.thrift源码解析之protocol
5.thrift源码解析之transport
6.thrift源码解析之server

概览：

协议和编解码（序列化/反序列化）是一个网络应用程序的核心问题之一。
thrift的协议和编解码整合在了一起。抽象类TProtocol定义了协议和编解码的顶层接口。（个人感觉采用抽象类而不是接口的方式来定义顶层接口并不好，TProtocol关联了一个TTransport传输对象，而不是提供一个类似getTransport()的接口，导致抽象类的扩展性比接口差。）

TProtocol主要做的两件事情：
1.关联TTrasnport对象
2.定义一系列读写消息的编解码接口：
复杂数据结构：readMessageBegin, readMessageEnd, writeMessageBegin, writMessageEnd
基本数据结构：比如readI32, writeI32, readString, writeString

传输数据主要有：
调用方:
1.方法的名称，包括类的名称和方法的名称
2.方法的参数，包括类型和参数值
3.一些附加的数据，比如附件，超时事件，自定义的控制信息等等

返回方:
1.调用的返回码
2.返回值
3.异常信息

从TProtocol的定义我们可以看出Thrift的协议约定如下事情:
1.先writeMessageBegin表示开始传输消息了，写消息头。Message里面定义了方法名，调用的类型，版本号，消息seqId
2.**接下来是写方法的参数，实际就是写消息体。**如果参数是一个类，就writeStructBegin
3.接下来写字段，writeFieldBegin, 这个方法会写接下来的字段的数据类型和顺序号。这个顺序号是Thrfit对要传输的字段的一个编码，从１开始
4.如果是一个集合就writeListBegin/writeMapBegin，如果是一个基本数据类型，比如int, 就直接writeI32
5.每个复杂数据类型写完都调用writeXXXEnd，直到writeMessageEnd结束
6.读消息时根据数据类型读取相应的长度
类图：
在这里插入图片描述

类继承架构分析

为什么需要对这部分的类继承架构进行分析了？上面不是有很清楚的类继承关系图了吗？但是Facebook在实现时并不是简单的这样继承下来就可以了，Facebook为了后期协议的可扩展性和允许其他组织、团队或个人实现自己的数据传输（主要是数据格式的封装）协议，里面多加了一层继承关系，就是类图中的TVirtualProtocol类，从类的名称可以看出这是一个虚的协议。怎样理解这个虚的协议了？通过阅读代码我觉得可以这样理解：因为它定义为一个模板类，这个模板类有两个参数，一个用于数据传输的真正协议，一个是用来继承的，它本身没有对协议具体内容做实现，所以说它是一个虚的协议类。下面我们对这个类继承架构结合代码实现来具体分析。

1 抽象类TProtocol和默认实现类TProtocolDefaults

抽象类对于每一种数据类型都提供了读写的开始和介绍的方法，这里读写方法应该是针对网络IO读写，不过真正实现网络读写还不是这里的方法，这里方法主要处理数据，例如对数据格式做调整。真正实现网络IO读写是下一章介绍的TTransport相关类实现的，那里还会对传输的方式做相应控制，例如是否压缩。

除了具体的数据类型有写入和读取的方法，消息也是需要通过网络传递，所以也定义了消息的传输读写方法。当然还定义了一些公用的功能，如跳过某一个结构不读、大小端数据格式调整、主机字节序和网络字节序的相互转换等。

（1）首先定义纯虚函数：

  virtual uint32_t writeMessageBegin_virt(const std::string& name,
                                          const TMessageType messageType,
                                          const int32_t seqid) = 0;
  virtual uint32_t writeMessageEnd_virt() = 0;
  virtual uint32_t writeStructBegin_virt(const char* name) = 0;
  virtual uint32_t writeStructEnd_virt() = 0;
  ......

（2）然后定义调用相应纯虚函数的函数：

uint32_t writeMessageBegin(const std::string& name,
                             const TMessageType messageType,
                             const int32_t seqid) {
    T_VIRTUAL_CALL();
    return writeMessageBegin_virt(name, messageType, seqid);
  }

  uint32_t writeMessageEnd() {
    T_VIRTUAL_CALL();
    return writeMessageEnd_virt();
  }

  ......

（3）其他公共函数

  uint32_t skip(TType type) {
    T_VIRTUAL_CALL();
    return skip_virt(type);
  }
  virtual uint32_t skip_virt(TType type);
  
  ......

还定义了一个对应抽象工厂类TProtocolFactory，用于生产具体的协议对象，这就是设计模式中最常用的抽象工厂设计模式。

至于默认实现类TProtocolDefaults主要重写了抽象类TProtocol的非虚拟化的方法，这些方法都抛出一个方法为实现（TProtocolException::NOT_IMPLEMENTED）的异常。这样做的主要目的为了下面要讲到的类TVirtualProtocol提供默认的继承基类，从而防止无限递归调用。

2 虚协议类TVirtualProtocol

首先看看这个特殊的模板类是怎样定义的：

template <class Protocol_, class Super_ = TProtocolDefaults>
class TVirtualProtocol : public Super_ {

 	......
 }

说它特殊我觉得主要是基于两个方面：

（1）继承的类可以通过模板参数传递，也就是说你现在没有办法肯定它现在到底继承什么类，只是默认参数值是我们上面介绍的抽象类的默认实现类：class Super_ = TProtocolDefaults给默认参数。

（2）类里面的方法实现全部是采用把this指针转换为第一个模板参数的类型然后调用模板参数类型的相关方法。如下面的一个方法的定义：

uint32_t writeMessageBegin_virt(const std::string& name,
                                          const TMessageType messageType,
                                          const int32_t seqid) override {
    return static_cast<Protocol_*>(this)->writeMessageBegin(name, messageType, seqid);
  }		//实现抽象类的writeMessageBegin_virt方法

由上面两个特点可以发现这个类只是提供一个空的架构壳，继承的类可以指定，当然也可以采用默认的，后面分析具体协议实现的时候可以发现大多数协议也确实是采用默认的继承类，且大多数继承这个虚协议的类都是传递第一个参数为自身，也就是调用自己定义的相应函数。如TBinaryProtocolT类的定义，如下：

template <class Transport_>

class TBinaryProtocolT : public TVirtualProtocol< TBinaryProtocolT<Transport_> > {

......

}

下面来分析如果不从定义的默认实现类继承，直接从抽象类继承怎样会产生无限递归调用。现在我们假设直接从抽象类继承，那么如果一个指向子类对象的父类（TProtocol）调用writeMessageBegin方法，因为这个方法不是虚拟函数（不会动态绑定）所以就会调用父类的writeMessageBegin方法，然后父类会直接调用它的纯虚函数writeMessageBegin_virt，这个函数就会动态绑定，就会执行子类的实现，在这里就是通过虚协议类TVirtualProtocol实现的，而这个函数又会调用之类的writeMessageBegin方法，如果子类没有实现这个方法，那么就又回到父类的这个方法了,从而产生无限递归调用。那么如果默认是从默认实现类TProtocolDefaults继承，那么就会执行它的writeMessageBegin方法，从而抛出一个异常，就不会产生无限递归调用。
以下代码就是对这个过程的解释：
1、没有中间类：在son中的方法没有实现时，就会发生无限递归：

//father *p->FUN()-->return FUN_virt()-->return static_cast<son__*>(this)->FUN()-
//			^				    				                                |	
//			|_________________________无限递归了 ________________________________|

#include <stdio.h>
class father{
	public:
		virtual ~father(){};
		virtual int FUN_virt() = 0;
		int FUN(){
			printf("fun");
			return FUN_virt();	
		}
};

template<class son__,class father__ = father>
class father_virt:public father__{
	public:
		int FUN_virt() override{
			return static_cast<son__*>(this)->FUN();
		}
};
class son:public father_virt<son>
{
public:
	//int FUN(){
	//	printf("son\n");
	//}
};

int main()
{
	father *p;
	son s;
	p=&s;
	p->FUN();
}

2、有中间类，在son类没有实现时，不会让程序跑崩：

//father *p->FUN()-->return FUN_virt()-->return static_cast<son__*>(this)->FUN()-->FUN()(father_default中实现的FUN)
//没有发生无限递归
#include <stdio.h>
class father{
	public:
		virtual ~father(){};
		virtual int FUN_virt() = 0;
		int FUN(){
			printf("fun");
			return FUN_virt();	
		}
};
class father_default:public father{
	public:
	int FUN(){
		printf("default");
	};
};
template<class son__,class father__ = father_default>
class father_virt:public father__{
	public:
		int FUN_virt() override{
			return static_cast<son__*>(this)->FUN();
		}
};
class son:public father_virt<son>
{
public:
	//int FUN(){
		//printf("son\n");
	//}
};

int main()
{
	father *p;
	son s;
	p=&s;
	p->FUN();
}

3 具体协议类或实现自己的协议类

这个就是类继承架构的最后一部分，也就是实现具体的数据传输协议。例如二进制协议类定义。

那么这个二进制协议类就不用实现那些虚拟方法了。那些具体的协议实现方式后面详细介绍。

现在对这部分的类继承架构已经分析完毕，后面开始介绍Thrift中实现的几个比较重要的协议.

二进制协议类TBinaryProtocolT

这个协议是Thrift支持的默认二进制协议，它以二进制的格式写所有的数据，基本上直接发送原始数据。因为它直接从TVirtualProtocol类继承，而且是一个模板类。它的模板参数就是一个封装具体传输发送的类，这个类才是真正实现数据传输的。

template <class Transport_, class ByteOrder_ = TNetworkBigEndian>
class TBinaryProtocolT : public TVirtualProtocol<TBinaryProtocolT<Transport_, ByteOrder_> > {

... ...

下面我就结合scribe的Log函数执行的具体过程来分析使用这个协议所执行的功能，看看二进制协议是怎样工作的。

RPC调用使用到协议部分主要是在发送函数相关信息到服务器和接收服务器返回结果。现在我就结合Log函数的实现代码具体分析。首先看看Log函数的发送相关信息函数send_log（在文件scribe.cpp）：

void scribeClient::send_Log(const std::vector<LogEntry> & messages)
{
  int32_t cseqid = 0;
  oprot_->writeMessageBegin("Log", ::apache::thrift::protocol::T_CALL, cseqid);//写入函数调用消息
  scribe_Log_pargs args;
  args.messages = &messages;
  args.write(oprot_);//调用参数类自己的写入函数写入参数到服务器
  oprot_->writeMessageEnd();//写入消息调用写入
  oprot_->getTransport()->writeEnd();//结束传输层的写入
  oprot_->getTransport()->flush();//刷新传输流，让写入马上执行，因为RPC调用需要马上得到结果
}

从上面代码可以看出：首先调用具体一个协议的writeMessageBegin函数，当然这个我们分析的是二进制协议，那就看看二进制协议这个函数的实现，代码如下：

template <class Transport_>
uint32_t TBinaryProtocolT<Transport_>::writeMessageBegin(const std::string& name,
                                     const TMessageType messageType, const int32_t seqid) {
  if (this->strict_write_) {//判断是否需要强制写入版本号
    int32_t version = (VERSION_1) | ((int32_t)messageType);//本版号是协议号和消息类型的与结果
    uint32_t wsize = 0;//记录写入的长度
    wsize += writeI32(version);//写版本号
    wsize += writeString(name);//写消息名称，这就是函数名称Log
    wsize += writeI32(seqid);//写调用序列号
    return wsize;//返回写入的长度
  } else {
    uint32_t wsize = 0;
    wsize += writeString(name);
    wsize += writeByte((int8_t)messageType);
    wsize += writeI32(seqid);
    return wsize;
  }
}

根据上面代码和注释可以看出，根据是否需要写入协议版本号写入的内有所差别，写入协议号的目的是可以坚持客户端和服务器端是否使用相同的协议来传输的数据，保证数据格式的正确性。二进制的协议定义如下：

static const int32_t VERSION_MASK = 0xffff0000;//取得协议的掩码
static const int32_t VERSION_1 = 0x80010000;//具体协议本版号

具体写入又调用了自己实现的相应的数据类型写入函数，看看writeString是怎么实现的，如下：

template <class Transport_>
uint32_t TBinaryProtocolT<Transport_>::writeString(const std::string& str) {
uint32_t size = str.size();//取得字符串的长度（大小）
  uint32_t result = writeI32((int32_t)size);//写入字符串的长度到服务器
  if (size > 0) {
      this->trans_->write((uint8_t*)str.data(), size);//调用具体某一个传输方式的写入函数写入字符串数据
  }
  return result + size;//返回写入的大小
}

从上面代码可以看出这些类型的函数就是将对应的数据类型写入服务器，而且具体写入在这里还没有真正的进行，因为后面会讲到的Transport相关类还会对传输方式进行包装。

现在我们继续回到send_Log函数，写入函数调用的消息以后就开始写函数调用需要的参数，函数参数的写入是通过函数参数对应的封装类进行的，Log函数的参数封装类是scribe_Log_pargs，把对应的参数传递给这个类的对象，然后调用它自己的写入函数写入参数到服务器，代码如下：

uint32_t scribe_Log_pargs::write(::apache::thrift::protocol::TProtocol* oprot) const {
uint32_t xfer = 0;
  xfer += oprot->writeStructBegin("scribe_Log_pargs");//写入参数类的名称
  xfer += oprot->writeFieldBegin("messages", ::apache::thrift::protocol::T_LIST, 1);//写入字段名称和类型
  {
//开始写入链表类型
    xfer += oprot->writeListBegin(::apache::thrift::protocol::T_STRUCT, (*(this->messages)).size());
    std::vector<LogEntry> ::const_iterator _iter6;
    for (_iter6 = (*(this->messages)).begin(); _iter6 != (*(this->messages)).end(); ++_iter6)
    {
      xfer += (*_iter6).write(oprot);//依次写入链表参数类型里面的每一个
    }
    xfer += oprot->writeListEnd();//结束链表类型写入
}
xfer += oprot->writeFieldEnd();//写入字段结束
xfer += oprot->writeFieldStop();//停止写入字段
xfer += oprot->writeStructEnd();//写入参数结束
return xfer;
}

具体参数的写入函数根据参数的类型具体处理并写入到服务器端。这样整个函数调用就做完了，剩下的就是处理写入后的一些善后处理，看具体代码有注释。

当函数调用的消息发送出去以后就开始准备接收函数远程调用的结果（异步调用除外），这里接收Log函数调用返回结果的函数是recv_log，代码如下：

ResultCode scribeClient::recv_Log()
{
  int32_t rseqid = 0;
  std::string fname;
  ::apache::thrift::protocol::TMessageType mtype;//接收返回消息的类型
  iprot_->readMessageBegin(fname, mtype, rseqid);//读取返回结果的消息
  if (mtype == ::apache::thrift::protocol::T_EXCEPTION) {//处理返回消息是异常的情况
    ::apache::thrift::TApplicationException x;
    x.read(iprot_);//读取异常信息
    iprot_->readMessageEnd();
    iprot_->getTransport()->readEnd();
    throw x;//抛出异常信息
  }
  if (mtype != ::apache::thrift::protocol::T_REPLY) {//处理不是正常回复的结果
    iprot_->skip(::apache::thrift::protocol::T_STRUCT);
    iprot_->readMessageEnd();
    iprot_->getTransport()->readEnd();
  }
  if (fname.compare("Log") != 0) {//比较是否是Log函数调用返回的结果
    iprot_->skip(::apache::thrift::protocol::T_STRUCT);
    iprot_->readMessageEnd();
    iprot_->getTransport()->readEnd();
  }
  ResultCode _return;
  scribe_Log_presult result;
  result.success = &_return;
  result.read(iprot_);//读取结果信息
  iprot_->readMessageEnd();
  iprot_->getTransport()->readEnd();
  if (result.__isset.success) {//成功就正常返回，否则抛出异常信息
    return _return;
  }
  throw ::apache::thrift::TApplicationException(::apache::thrift::TApplicationException::MISSING_RESULT,
"Log failed: unknown result");//抛出不知道结果的异常信息，调用失败了
}

接收RPC调用结果的函数都是根据返回消息的类型做相应处理，不成功就抛出相应的异常信息。首先这里调用二进制协议的readMessageBegin函数读取由二进制写入的消息（这个当然是服务器端写入的），这个函数代码实现如下：

template <class Transport_>
uint32_t TBinaryProtocolT<Transport_>::readMessageBegin(std::string& name,TMessageType& messageType, int32_t& seqid) {
  uint32_t result = 0;
  int32_t sz;
  result += readI32(sz);//读取消息的头部（可能是协议版本号和消息类型的组合，也可能直接是消息）
  if (sz < 0) {//如果小于0（就是二进制为第一位以1开头，说明是带有协议版本号的
    // Check for correct version number
    int32_t version = sz & VERSION_MASK;//取得消息的版本号
    if (version != VERSION_1) {//如果不匹配二进制协议的版本号就抛出一个坏的协议异常
      throw TProtocolException(TProtocolException::BAD_VERSION, "Bad version identifier");
    }
    messageType = (TMessageType)(sz & 0x000000ff);//取得消息类型
    result += readString(name);//取得消息名称（也就是函数名称）
    result += readI32(seqid);//取得函数调用ID号
  } else {
    if (this->strict_read_) {//要求读协议本版号，但是这种情况是不存在协议版本号的所以抛出异常
      throw TProtocolException(TProtocolException::BAD_VERSION,
 "No version identifier... old protocol client in strict mode?");
    } else {
      int8_t type;
      result += readStringBody(name, sz);//读取消息名称（也就是函数名称）
      result += readByte(type);//读取消息类型
      messageType = (TMessageType)type;
      result += readI32(seqid);//读取函数调用ID号
    }
  }
  return result;//f返回读取数据的长度
}

上面的函数代码向我们展示了怎样处理基于二进制协议消息的读取和处理的过程，当然这个过程必须是建立在相应的写入消息的过程，只有按照相应的格式才能正确的处理。还有一点需要强调一下，就是每一种数据类型的写入和读取函数也是相对应的，在这里我没有具体分析每一个数据类型的写入函数了，其实也没有必要，也是这些代码都是很容易的，关键是读和写必须配合起来。

到此一个完整的基于二进制协议的RPC调用分析完毕，下面对这个二进制协议进行一下简单的总结。

（1）如果需要传输协议版本号，那么0-4字节就是协议版本号和消息类型；否则0-4字节就直接是消息名称（其实就是函数的名称）的长度，假设长度为len。

（2）如果0-4字节是协议版本号和消息类型，那么5-8字节就是消息名称的长度，同样假设长度为len，然后再跟着len字节的消息名称；否则就是len字节的消息名称。

（3）接下来如果没有带协议版本号的还有1字节的消息类型；

（4）然后都是4字节的请求的序列号；

（5）接着继续写入参数类型的结构体（但是二进制协议并没有真正写入，所以没有占用字节）；

（6）如果真正的有参数的话就继续一次为每一个参数写入1字节的参数类型（在前面已经给出了参数类型的定义，就是一个枚举）、2字节的参数序号和具体参数需要的长度；

（7）具体参数长度的需求如下：

a) 对于以下具有固定长度的简单数据类型的参数：

简单数据类型	长度（byte）
T_STOP = 0	1
T_VOID = 1	1
T_BOOL = 2	1
T_BYTE = 3	1
T_I08 = 3	1
T_I16 = 6	2
T_I32 = 8	4
T_U64 = 9	8
T_I64 = 10	8
T_DOUBLE = 4	8

复合数据类型	长度说明
T_STRING = 11	前面4个字节：字符串的长度stringLen；接下来的stringLen个字节：字符串的内容
T_STRUCT = 12	假设这个结构体包含m个字段：(为了便于说明问题，下面所说的字节偏移是相对于struct内部结构而言的)；0-1字节：字段的数据类型；1-3字节：字段序号，取决于你定义的idl文件中参数所定义的序号；接下来的k个字节：看简单数据类型；以此类推，直至m个字段。其实，struct的字段和函数参数具有一样的编码方式
T_MAP = 13	(为了便于说明问题，下面所说的字节偏移是相对于map内部结构而言的)：0-1字节：key的数据类型。注意，可能是复合数据类型；1-2字节：value的数据类型。假设key的数据类型的长度为k个字节，value的数据类型的长度为v个字节，那么接下来每k+v个字节作为一个key-value值，至于key的值的分析和value的值的分析，看简单数据类型
T_SET = 14	(为了便于说明问题，下面所说的字节偏移是相对于set内部结构而言的)：0-1字节：set里面的元素的数据类型；1-5字节：元素个数；假设元素的数据类型的长度为k个字节，那么接下来每k个字节作为一个元素值，至于元素值的分析，看简单数据类型；注意，这里和函数参数/struct的区别在于，这里不存在元素的序号值
T_LIST = 15	和set类似

参考文章：https://www.cnblogs.com/brucewoo/archive/2012/06/05/2535473.html