RPC(Remote Procedure Call),中文翻譯是遠程過程調(diào)用,其實從原理來說這并不是一個新的概念.我的理解是, 不同的機器之間定義了一些接口, 也有客戶端和服務器端,客戶端可以通過協(xié)商好的接口調(diào)用服務器端已經(jīng)注冊好的服務.說白了,還是網(wǎng)絡(luò)通信的那一套機制.既然還是網(wǎng)絡(luò)通信,那么為什么需要使用RPC而不是自己去完成這樣的一套工作呢?假如是自己做這樣的事情,需要考慮編解碼,網(wǎng)絡(luò)層,尤其很多細節(jié)需要去關(guān)注:協(xié)議有哪些?如何定義格式?涉及到整數(shù)的還要考慮網(wǎng)絡(luò)和主機字節(jié)序等,如果邏輯程序員還需要關(guān)注這些細節(jié),顯然太繁瑣了.還有就是,國內(nèi)的公司開發(fā)很少有文檔,假如查找問題時還需要通過讀代碼才能知道協(xié)議中各個字段的含義,這樣對項目的可維護性會有很大的影響.假如使用了RPC,通過RPC工具定義的格式來定義協(xié)議,可以一目了然.而且,網(wǎng)絡(luò)層就應該只關(guān)注網(wǎng)絡(luò)層的工作,邏輯層架構(gòu)在網(wǎng)絡(luò)層之上再完成邏輯的操作.把網(wǎng)絡(luò)和邏輯分開,也是清晰的架構(gòu)設(shè)計.

google protobuf 是google公開的一套用于網(wǎng)絡(luò)通信時用于協(xié)議編解碼的工具庫,使用它定義的格式,你可以定義協(xié)議的字段,由它自帶的編譯器生成出負責編解碼的代碼文件(可生成許多不同的語言文件).同時,它還包括了基本的RPC接口定義.但是,這個工具用在RPC上比較大的問題是它只負責生成代碼文件,而如果要真正使用起來做為一個RPC框架,還需要對它進行網(wǎng)絡(luò)層上的封裝,但是在它自己的官方文檔上并沒有給出一個demo告訴讀者如何一步一步的來完成這樣一個工作.thrift是與google protobuf同樣定位的一個工具庫,除了具備google protobuf相同的功能外,如支持多語言,跨平臺,高效的編解碼,還集成了網(wǎng)絡(luò)通信層,可以使用它完成所有RPC所需要完成的工作.在這個頁面中,google protobuf給出了一些已知的使用不同語言對它進行封裝的項目.

chenshuo的evproto同樣也是集成libevent與google protobuf的RPC框架,不過在對libevent的使用上,這里的做法與他不盡相同:
1) 他使用了libevent自帶的RPC功能, 而這里只使用到libevent對網(wǎng)絡(luò)I/O進行的封裝的最基本的功能.
2) 之所以有1)的考慮,是因為我認為一個工具最好應該是"do one thing, do it better"的(也許從這點可以解釋為什么google protobuf沒有像thrift那樣自帶網(wǎng)絡(luò)層,而是把這個工作留給了用戶),libevent已經(jīng)越來越大,除了對I/O,信號,定時器等的封裝之外,現(xiàn)在還有RPC,異步DNS,http協(xié)議的支持等等,說真的,如果只是關(guān)注到網(wǎng)絡(luò)I/O的多路復用機制,那么幾乎任何一個熟練的程序員都可以很快的自己做出這樣的一套東西來,使用libevent無非就是為今后可能的跨平臺做準備罷了.隨著我對libevent發(fā)展方向的不認同,還曾經(jīng)想過使用libev替代libevent,不過現(xiàn)在暫時不想折騰這個事情了.

eventrpc項目目前是avidya下的一個子項目,avidya項目的定位是實現(xiàn)一些分布式的玩具系統(tǒng)(比如google已經(jīng)公開論文的chubby,mapreduce,GFS等),也許以后不一定能被用上,但是也要實踐做一把.由于有一個好用的RPC框架是做分布式的必需品,所有首先實現(xiàn)eventrpc這個子項目了,以后也許還會實現(xiàn)其他語言的版本,如python,java.

eventrpc的網(wǎng)絡(luò)模型上,使用以前提到的memcached的網(wǎng)絡(luò)模型, 主線程負責接收新的連接, 再將這些新的連接交由副線程處理,每個副線程自帶I/O dispatcher.在samples目錄下,有一個實現(xiàn)了echo服務的客戶端和服務器端示例.

在使用之前,請確保libevent和google protobuf已經(jīng)安裝成功,當前只在linux下可用.