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