thrift 简介
thrift 是由facebook发起的基于网络通信RPC 协议的开源库,之后交由 apache 基金会维护的。 据说facebook 多数软件均基于此库开发。
优点
- 家大业大, 长期维护,品牌效应很强
- 由于有facebook 和 apache 基金会这样的大树支撑, thrift 所培养的社群团体能够让新进开发者获得足够的信息和帮助
- 底层封装良好,提高编程效率
- thrift 将绝大多数涉及到底层的分包发送, 压缩等问题均封装处理好, 无需开发者关心底层的具体细节。开发者仅需要关注需要传输的数据本身,以及数据处理返回等环节即可。极大的减轻了开发者的负担,和提升了开发效率
- 面向接口函数编程, 提供最直接的数据类型, 免除网络编程的诸多问题
- Thrift 是面向接口函数设计的。 客户端和服务端均采用同一个接口函数。 将数据归属本身的问题从数据身上剥离出来。 让网络数据交互 如同调用一个接口函数那般简单。
- 支持多语言开发
- thrift 自身提供多种语言的开发, 提供多平台的支持。
缺点
- 官方文档难度较高
- 官方的文档的假设前提开发者开发实力很强,可以说thrift 基本不适合开发新手使用。可以说写给高手看的,几句话就把事情说完了。操作起来往往会遇到各种各样的问题。 这时候就只能依靠社区的帮助了。
- 入门曲线较高
- thrift 本身要求开发者具备较高的开发素养。 对开发各个环节基本都很熟悉。 官方demo 也不是下载即可使用。 需要一番调试,一些语言还需要先生成库后方可使用。 笔者也是先下载了第三方demo 经过一番调试之后才基本上手thrift 。刚开始需要折腾的东西还是比较多的
- 不适合缺乏系统级的开发环境
- thrift 是需要系统支持的,并不适合不带系统的嵌入式开发。
thrift 通信机制简述
thrift 采用统一的接口函数设计机制, 同一份数据段, 客户端和服务器都由统一个函数负责发送 或者接受处理。 发送和接受均通过函数参数的形式进行数据传递, 返回值则作为响应。 这种方式很好的实现了 数据本身 和数据归属的分离。 开发者可以快速的实现开发者分类处理。
同步通信小览
客户端
① ——————————- ②
string helloString( string t_send_data) ;
① : return data from server
② : send data to server
服务器
① ——————————- ②
string helloString( string t_send_data) ;
① : return data to client
② : send data from client
thrift 的异步通信和 同步通信大同小异。 不过在函数的参数项中增加了回调函数一项。客户端 函数发送完数据后直接返回。 当客户端接受到服务器响应之后,则直接执行指定的回调函数,进行自动处理。
关于编译部署那些事
thrift 对各个语言的编译部署的难度差距很大。
笔者个人觉得 C++ 的编译部署是最为复杂的。六七个库要求安装,网上教程多是面对linux 的, 对windows 开发者感觉非常不友好。 如果想用C++ 作为Thrift 性能研究测试, 这无疑是最糟糕的想法。
实际的编译过程中,会遇到SSL 问题,以及libthriftnb 库无法编译通过等诸多问题。
正常情况下,仅需配置指定boost库后,即可完成libthrift 库的编译。编译之后将生成一个将近19M 的静态库。 但是libthriftnb 库(异步非阻塞) 却需要libevent 库的支持。笔者调试了将建一下午,各种问题频发,解决一个问题,又冒出另外一个问题,实在是蛋的很Java 相比之下就简单好多, 网上教程也非常丰富。
基本思路都是:
- 生成调用库文件
- 编写thrift IDL 文件
- 将thrift 文件转换成 .java 文件
调用库和加载由thrift 生成的文件
C# 的官方demo搞得很复杂,连从thrift 生成 cs 文件都容易。 用C# 搞研究真是是纯研究,除了微软库,其他库基本就像异端。基本没有社区生态的概念。网上资料也少的可怜。不过由于C# 的设计思路基本和java 保持一致, 玩转了java 再玩C# 就完全没有难度了。
python 延续的java 的风格,一如既往的简单. 但是在实际的开发过程中,使用官网的python setup.py运行老是出错。 导致库无法正常安装。 经过一番折腾之后, 下载使用python 官网的thifit 即可正常安装。 安装完后,直接import 相关的库即可运行程序