• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            那誰的技術(shù)博客

            感興趣領(lǐng)域:高性能服務(wù)器編程,存儲,算法,Linux內(nèi)核
            隨筆 - 210, 文章 - 0, 評論 - 1183, 引用 - 0
            數(shù)據(jù)加載中……

            集成libevent,google protobuf的RPC框架

            RPC(Remote Procedure Call),中文翻譯是遠程過程調(diào)用,其實從原理來說這并不是一個新的概念.我的理解是, 不同的機器之間定義了一些接口, 也有客戶端和服務(wù)器端,客戶端可以通過協(xié)商好的接口調(diào)用服務(wù)器端已經(jīng)注冊好的服務(wù).說白了,還是網(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ò)層就應(yīng)該只關(guān)注網(wǎng)絡(luò)層的工作,邏輯層架構(gòu)在網(wǎng)絡(luò)層之上再完成邏輯的操作.把網(wǎng)絡(luò)和邏輯分開,也是清晰的架構(gòu)設(shè)計.

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

            chenshuoevproto同樣也是集成libevent與google protobuf的RPC框架,不過在對libevent的使用上,這里的做法與他不盡相同:
            1) 他使用了libevent自帶的RPC功能, 而這里只使用到libevent對網(wǎng)絡(luò)I/O進行的封裝的最基本的功能.
            2) 之所以有1)的考慮,是因為我認為一個工具最好應(yīng)該是"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的多路復(fù)用機制,那么幾乎任何一個熟練的程序員都可以很快的自己做出這樣的一套東西來,使用libevent無非就是為今后可能的跨平臺做準(zhǔn)備罷了.隨著我對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ò)模型, 主線程負責(zé)接收新的連接, 再將這些新的連接交由副線程處理,每個副線程自帶I/O dispatcher.在samples目錄下,有一個實現(xiàn)了echo服務(wù)的客戶端和服務(wù)器端示例.

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

            posted on 2010-06-20 16:30 那誰 閱讀(27526) 評論(4)  編輯 收藏 引用 所屬分類: avidyaeventrpc

            評論

            # re: 集成libevent,google protobuf的RPC框架  回復(fù)  更多評論   

            可以考慮用asio代替libevent
            2010-06-20 17:31 | winshaui@gmail.com

            # re: 集成libevent,google protobuf的RPC框架  回復(fù)  更多評論   

            Rpc提升了架構(gòu)的靈活性,降低了業(yè)務(wù)模塊物理層面的耦合度
            2010-06-21 11:20 | Z羅

            # re: 集成libevent,google protobuf的RPC框架  回復(fù)  更多評論   

            樓主,有放出代碼下載嗎?
            2011-01-24 17:17 | zhanghuafeng

            # re: 集成libevent,google protobuf的RPC框架[未登錄]  回復(fù)  更多評論   

            @zhanghuafeng
            看這里: http://www.codedump.info/?p=169
            2011-01-24 21:19 | 那誰

            只有注冊用戶登錄后才能發(fā)表評論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            久久婷婷国产剧情内射白浆| 久久婷婷五月综合97色直播| 人人狠狠综合久久亚洲婷婷| 久久精品综合一区二区三区| 久久久久久国产精品美女| 97久久超碰国产精品旧版| 久久综合九色综合欧美就去吻| 欧美噜噜久久久XXX| 99国内精品久久久久久久| 亚洲国产一成久久精品国产成人综合| 久久精品国产亚洲精品2020| 美女久久久久久| 久久精品国产91久久麻豆自制| 欧美国产成人久久精品| 91精品国产高清久久久久久91| 久久精品中文无码资源站| 伊人久久成人成综合网222| 99久久99久久精品国产片| 麻豆AV一区二区三区久久| 中文字幕精品久久| 久久青青草原亚洲av无码| 精品久久久久久无码国产| 久久精品国产69国产精品亚洲| 日本久久久久亚洲中字幕| 午夜精品久久久久久久| 久久精品国产AV一区二区三区| 久久久久亚洲av成人无码电影| 激情五月综合综合久久69| 精品多毛少妇人妻AV免费久久| 色成年激情久久综合| 亚洲成色999久久网站| 狠狠色噜噜狠狠狠狠狠色综合久久| 精品国产VA久久久久久久冰 | 亚洲午夜久久影院| 精品国产VA久久久久久久冰| 久久99热只有频精品8| AV无码久久久久不卡蜜桃| 99久久无码一区人妻| 国产午夜精品久久久久九九电影| 精品久久久久久无码免费| 亚洲国产香蕉人人爽成AV片久久|