RPC(
Remote Procedure Call),中文翻译是远程过程调用,其实从原理来说这并不是一个新的概念.我的理解是, 不同的机器之间定义了一些接口, 也有客户端和服务器端,客户端可以通过协商好的接口调用服务器端已经注册好的服务.说白了,还是网络通信的那一套机制.既然还是网络通信,那么为什么需要使用RPC而不是自己去完成这样的一套工作呢?假如是自己做这样的事情,需要考虑编解码,网络层,尤其很多细节需要去关注:协议有哪些?如何定义格式?涉及到整数的还要考虑网络和主机字节序等,如果逻辑程序员还需要关注这些细节,显然太繁琐了.还有就是,国内的公司开发很少有文档,假如查找问题时还需要通过读代码才能知道协议中各个字段的含义,这样对项目的可维护性会有很大的影响.假如使用了RPC,通过RPC工具定义的格式来定义协议,可以一目了然.而且,网络层就应该只关注网络层的工作,逻辑层架构在网络层之上再完成逻辑的操作.把网络和逻辑分开,也是清晰的架构设计.
google protobuf 是google公开的一套用于网络通信时用于协议编解码的工具库,使用它定义的格式,你可以定义协议的字段,由它自带的编译器生成出负责编解码的代码文件(可生成许多不同的语言文件).同时,它还包括了基本的RPC接口定义.但是,这个工具用在RPC上比较大的问题是它只负责生成代码文件,而如果要真正使用起来做为一个RPC框架,还需要对它进行网络层上的封装,但是在它自己的官方文档上并没有给出一个demo告诉读者如何一步一步的来完成这样一个工作.
thrift是与google protobuf同样定位的一个工具库,除了具备google protobuf相同的功能外,如支持多语言,跨平台,高效的编解码,还集成了网络通信层,可以使用它完成所有RPC所需要完成的工作.在
这个页面中,google protobuf给出了一些已知的使用不同语言对它进行封装的项目.
chenshuo的
evproto同样也是集成libevent与google protobuf的RPC框架,不过在对libevent的使用上,这里的做法与他不尽相同:
1) 他使用了libevent自带的RPC功能, 而这里只使用到libevent对网络I/O进行的封装的最基本的功能.
2) 之所以有1)的考虑,是因为我认为一个工具最好应该是"do one thing, do it better"的(也许从这点可以解释为什么google protobuf没有像thrift那样自带网络层,而是把这个工作留给了用户),libevent已经越来越大,除了对I/O,信号,定时器等的封装之外,现在还有RPC,异步DNS,http协议的支持等等,说真的,如果只是关注到网络I/O的多路复用机制,那么几乎任何一个熟练的程序员都可以很快的自己做出这样的一套东西来,使用libevent无非就是为今后可能的跨平台做准备罢了.随着我对libevent发展方向的不认同,还曾经想过使用libev替代libevent,不过现在暂时不想折腾这个事情了.
eventrpc项目目前是
avidya下的一个子项目,avidya项目的定位是实现一些分布式的玩具系统(比如google已经公开论文的chubby,mapreduce,GFS等),也许以后不一定能被用上,但是也要实践做一把.由于有一个好用的RPC框架是做分布式的必需品,所有首先实现eventrpc这个子项目了,以后也许还会实现其他语言的版本,如python,java.
eventrpc的网络模型上,使用以前提到的
memcached的网络模型, 主线程负责接收新的连接, 再将这些新的连接交由副线程处理,每个副线程自带I/O dispatcher.在samples目录下,有一个实现了echo服务的客户端和服务器端示例.
在使用之前,请确保libevent和google protobuf已经安装成功,当前只在linux下可用.