最近有一个分布式调用跟踪系统的项目,需要给基于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调用字节流大致如下: