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下可用.