Thrift源码分析（九）-- 扩展Thrift框架来实现Attachable的RPC调用

最近有一个分布式调用跟踪系统的项目，需要给基于Thrift的RPC调用添加调用链上下文信息，从而可以生成一次RPC调用的调用链信息。这篇讲讲如何扩展Thrift框架来实现RPC过程中无侵入地添加额外attachment信息的场景。

Thrift框架本身提供了很多机制来支持扩展，比如

1. 扩展TProtocol来实现自定义的序列化类

2. 扩展TTransport来实现自定义的流

3. 采用装饰器模式来装饰Processor，从而在服务实现方法被调用的前后插入自定义逻辑

4. 构建Client和Server时，可以把自定义的Protocol, Transport, Processor作为参数Args传入，从而使用自定义的这些类来处理请求

下图是Thrfit RPC调用涉及到的主要组件，RPC框架都大同小异，基本的结构差不多。绿色部分是可以扩展的点。比如在Client端包一层，可以增加服务寻址，负载均衡等分布式集群的功能，在Server端包一层，可以实现服务端的配置管理，监控等等。

在这个简化的例子中，只需要扩展TProtocol和Processor，就可以实现在RPC调用时添加额外的attachment。

TProtocol表示了RPC调用的序列化过程，更多可以看这篇Thrift源码分析（二）-- 协议和编解码 。TProtocol将序列化过程分为几步

1. write/read Message，读写消息头，消息头包含了方法名，序列号等信息

2. write/read Struct，将RPC方法的参数/返回值封装成结构体，读写结构体即表示要读写RPC方法参数了

3. write/read Field，每一个参数都被抽象成Field，Field主要包含了字段的索引信息，类型信息等

4. write/read Type，即读写各种具体的数据

TBinaryProtocol是使用地比较多的一种基于二进制流的协议，它实现了上述所有的write/read方法。

  public void writeMessageBegin(TMessage message) throws TException {
    if (strictWrite_) {
      int version = VERSION_1 | message.type;
      writeI32(version);
      writeString(message.name);
      writeI32(message.seqid);
    } else {
      writeString(message.name);
      writeByte(message.type);
      writeI32(message.seqid);
    }
  }

  public void writeMessageEnd() {}

  public void writeStructBegin(TStruct struct) {}

  public void writeStructEnd() {}

  public void writeFieldBegin(TField field) throws TException {
    writeByte(field.type);
    writeI16(field.id);
  }

  public void writeFieldEnd() {}

看一下上面TBinaryProtocol几个方法实现可以发现，它的write/read Struct是空实现，也即写完Message消息头之后直接开始写Field。具体一个Thrift服务生成的客户端中包含了一个服务方法所有的结构信息，比如所有的参数都被创建了相应的TFiled对象，TField都是从1开始往后编号，并且生成了如何序列化一个具体参数的方法，可以看这篇 Thrift源码分析（三）-- IDL和生成代码分析

所以基于TBinaryProtocol协议生成的RPC调用字节流大致如下：