ITer_ZC的专栏

最近有一个分布式调用跟踪系统，需要给基于Thrift的RPC调用添加调用链上下文信息，从而可以生成一次调用的调用链。这篇讲讲如何扩展Thrift框架来实现RPC过程中无侵入地添加额外attachment信息的场景。Thrift框架本身提供了很多机制来支持扩展，比如1. 实现TProtocol接口来实现

前面七篇文章分析了Thrfit的方方面面，看到这里时应该对Thrift有了深入的理解。Thrift源码分析（一）-- 基本概念Thrift源码分析（二）-- 协议和编解码Thrift源码分析（三）-- IDL和生成代码分析Thrift源码分析（四）-- 方法调用模型分析Thrift源码分析（五）-- FrameBuffer类分析Thrift源码分析（六）-- Transpo

Thrift采用了TServer来作为服务器的抽象，提供了多种类型的服务器实现。用TServerTransport作为服务器的Acceptor抽象，来监听端口，创建客户端Socket连接先来看看TServerTransport。主要有两类1. TNonblockingServerTransport和TNonblockingServerSocket作为非阻塞IO的Acceptor,封装了

RPC作为一种特殊的网络编程，会封装一层传输层来支持底层的网络通信。Thrift使用了Transport来封装传输层，但Transport不仅仅是底层网络传输，它还是上层流的封装。关于Transport的设计，从架构上看，IO流和网络流都是IO的范畴，用一个统一的接口来抽象并无不可，但是个人感觉看Thrift的代码时，都用的Transport来表示流，不知道是普通IO流还是底层的网络流。还不如

FrameBuffer是Thrift NIO服务器端的一个核心组件，它一方面承担了NIO编程中的缓冲区的功能，另一方面还承担了RPC方法调用的职责。FrameBufferState定义了FrameBuffer作为缓冲区的读写状态private enum FrameBufferState { // in the midst of reading the fra

RPC调用本质上就是一种网络编程，客户端向服务器发送消息，服务器拿到消息之后做后续动作。只是RPC这种消息比较特殊，它封装了方法调用，包括方法名，方法参数。服务端拿到这个消息之后，解码消息，然后要通过方法调用模型来完成实际服务器端业务方法的调用。这篇讲讲Thrfit的方法调用模型。Thrift的方法调用模型很简单，就是通过方法名和实际方法实现类的注册完成，没有使用反射机制，类加载机制。

IDL是很多RPC框架用来支持跨语言环境调用的一个服务

协议和编解码是一个网络应用程序的核心问题之一，客户端和服务器通过约定的协议来传输消息(数据)，通过特定的格式来编解码字节流，并转化成业务消息，提供给上层框架调用。Thrift的协议比较简单，它把协议和编解码整合在了一起。抽象类TProtocol定义了协议和编解码的顶层接口。个人感觉采用抽象类而不是接口的方式来定义顶层接口并不好，TProtocol关联了一个TTransport传输对象，而不是提

我所在的公司使用Thrift作为基础通信组件，相当一部分的RPC服务基于Thrift框架。公司的日UV在千万级别，Thrift很好地支持了高并发访问，并且Thrift相对简单地编程模型也提高了服务地开发效率。Thrift源于Facebook, 目前已经作为开源项目提交给了Apahce。Thrift解决了Facebook各系统的大数据量传输通信和内部不同语言环境的跨平台调用。Thrift的官