ITer_ZC的专栏

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

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

前面七篇文章分析了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流还是底层的网络流。还不如

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

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

我之前在传统IT公司干活，后来来了互联网，感受到了很多不同，其中有一点就是两者使用到的技术有一些差别。比如说分布式调用技术。我在的这家公司内部的服务架构是基于Thrift的，服务基于Thrift进行发布，以至于很多人没有听过、使用过Web Service。话说传统IT传了很多年的SOA就是基于Web Service，已经有了一整套完整的理论和产品进行支持，互联网竟然很多没涉及过。后来想了想

很多RPC技术都会使用中间语言来定义接口描述，比如Web Service常用的WSDL, Thrift使用的IDL。这类文件都是接口定义/描述语言 (Interface Definition/Description Language)，有几个特点：1. 采用中间语言来描述接口，以及接口使用到的数据结构(类)2. 一般都采用文本文件，方便传递3. 语法上可以使用XML,也可以

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

RMI是Java原生的分布式服务机制，支持Java对Java的分布式访问，采用Java的序列化协议进行CodeC操作。这里简单说下RMI发布服务和客户端引用服务的方式。RMI发布服务时支持两种方式，一种是RMI本身的发布协议，另外一种是采用通用的JNDI的方式来发布服务。采用JMI本身的发布协议，可以使用Registry接口，也可以使用Naming工具类。使用Registry接