Thrift源码分析(一)-- 基本概念

我所在的公司使用Thrift作为基础通信组件,相当一部分的RPC服务基于Thrift框架。公司的日UV在千万级别,Thrift很好地支持了高并发访问,并且Thrift相对简单地编程模型也提高了服务地开发效率。

Thrift源于Facebook, 目前已经作为开源项目提交给了Apahce。Thrift解决了Facebook各系统的大数据量传输通信和内部不同语言环境的跨平台调用。

Thrift的官方网站: http://thrift.apache.org/

作为一个高性能的RPC框架,Thrift的主要特点有

1. 基于二进制的高性能的编解码框架

2. 基于NIO的底层通信

3. 相对简单的服务调用模型

4. 使用IDL支持跨平台调用

这张图来自《深入浅出RPC - 深入篇》 描述了一个RPC框架的基本组件,包括服务器端发布和调用服务组件,NIO组件,协议和编解码组件,客户端调用组件,客户端代理组件等等

对照这个模型,Thrift的核心组件有:

TProtocol 协议和编解码组件

TTransport 传输组件

TProcessor 服务调用组件

TServer,Client 服务器和客户端组件

IDL 服务描述组件,负责生产跨平台客户端

这个系列会结合源码,深入分析Thrfit的RPC调用模型和核心组件

时间: 2024-10-22 04:47:11

Thrift源码分析(一)-- 基本概念的相关文章

Thrift源码分析(四)-- 方法调用模型分析

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

Thrift源码分析阅读(二)

Thrift总结 总体结构: Server: ServerSocket监听请求,请求到达时,读取请求数据. 根据请求数据创建一个InputTransport,创建OutputTransport 根据InputTransport和OutputTransport创建相应的input protocol 和 output protocol. 依据protocol 创建processor,在processor中完成业务分发操作. 将请求信息结果数据写回客户端. Transport: 提供了一个读取/写入网

Thrift源码分析阅读(一)

Thrift -Storm篇 从Nimbus启动说起: 当用户通过命令启动nimbus时,Classloader将会找到一个称之为bytetype.storm.daemon.nimbus的一个class文件,这个是由numbis.clj文件编译而成,来看nimbus.clj这个的启动方法: (defn -main [] (-launch (standalone-nimbus))) (standalone-nimbus) 执行这个方法返回一个INimbus接口的实例 执行launch(INimbu

Thrift源码分析(六)-- Transport传输层分析

RPC作为一种特殊的网络编程,会封装一层传输层来支持底层的网络通信.Thrift使用了Transport来封装传输层,但Transport不仅仅是底层网络传输,它还是上层流的封装. 关于Transport的设计,从架构上看,IO流和网络流都是IO的范畴,用一个统一的接口来抽象并无不可,但是个人感觉看Thrift的代码时,都用的Transport来表示流,不知道是普通IO流还是底层的网络流.还不如用Java的方式,把普通IO和网络接口用不同抽象隔离,至少代码逻辑比较清晰 废话不多说,看看Trasp

Thrift源码分析(二)-- 协议和编解码

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

Thrift源码分析(五)-- FrameBuffer类分析

FrameBuffer是Thrift NIO服务器端的一个核心组件,它一方面承担了NIO编程中的缓冲区的功能,另一方面还承担了RPC方法调用的职责. FrameBufferState定义了FrameBuffer作为缓冲区的读写状态 private enum FrameBufferState { // in the midst of reading the frame size off the wire // 读Frame消息头,实际是4字节表示Frame长度  READING_FRAME_SIZ

Thrift源码分析(三)-- IDL和生成代码分析

IDL是很多RPC框架用来支持跨语言环境调用的一个服务描述组件,一般都是采用文本格式来定义. 更多IDL的思考查看<理解WSDL, IDL> Thrift的不同版本定义IDL的语法也不太相同,这里使用Thrift-0.8.0这个版本来介绍Java下的IDL定义 1. namespace 定义包名 2. struct 定义服务接口的参数,返回值使用到的类结构.如果接口的参数都是基本类型,则不需要定义struct 3. service 定义接口 一个简单的例子,IDL文件以.thrift为后缀名.

Redux源码分析之compose

Redux源码分析之基本概念 Redux源码分析之createStore Redux源码分析之bindActionCreators Redux源码分析之combineReducers Redux源码分析之compose      解读之前先了准备一下基本知识 rest参数  形式为...变量名,用于获取函数的多余参数 ,该变量将多余的参数放入数组中, 只能是参数的最后一个. 扩展运算符 扩展运算符(spread)是三个点(...).它好比 rest 参数的逆运算,将一个数组转为用逗号分隔的参数序

Flume NG源码分析(五)使用ThriftSource通过RPC方式收集日志

上一篇说了利用ExecSource从本地日志文件异步的收集日志,这篇说说采用RPC方式同步收集日志的方式.笔者对Thrift比较熟悉,所以用ThriftSource来介绍RPC的日志收集方式. 整体的结构图如下: 1. ThriftSource包含了一个Thrift Server,以及一个Thrift Service服务的实现.这里的Thrift Service是由ThriftSourceProtocol定义 2. 应用程序调用Thrift Service的客户端,以RPC的方式将日志发送到Th