• <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>

             

             

            最近給自己換了個(gè)老板,忙了一段時(shí)間,所以有幾個(gè)月沒寫博客,今后還是要爭取多寫啊,呵呵。

             

            換來新地方,第一件大的事情就是修改后端架構(gòu)和通信協(xié)議,架構(gòu)也設(shè)計(jì)得很普通,因?yàn)檫@邊的業(yè)務(wù)不需要太過復(fù)雜的后端,所以就簡單設(shè)計(jì)了一下,基本是參照web的模型,符合我一貫的向web學(xué)習(xí)的思想,弄了個(gè)gate管理入口,相當(dāng)于web下的webserver,后端其他服務(wù)器掛在該gate下,相當(dāng)于web模型下的appserver,或者fastcgi模型的fastcgi進(jìn)程,gate上管理連接、合法性檢測、登錄、加密、壓縮、緩存。Gate和后端通信本來想?yún)⒄?/span>fastcgi協(xié)議,但看了之后覺得fastcgi協(xié)議還是復(fù)雜了,所以就設(shè)計(jì)了一個(gè)更簡單的協(xié)議,gate和后端server之間可傳遞key:value型數(shù)據(jù)對,value不局限于字符串,可以是任意數(shù)據(jù),這樣基本滿足了當(dāng)前的需求,第一版放上去之后也運(yùn)行良好,到今天也基本持續(xù)穩(wěn)定運(yùn)行快一個(gè)月了,沒出過什么事情。由于在gate這邊緩沖了job管理,所以后端server升級很方便,隨時(shí)可關(guān)閉更新,gate會在窗口時(shí)間內(nèi)將未執(zhí)行完成的任務(wù)重新提交,有此功能可放心大膽的升級后端,這個(gè)月這樣的工作做了幾次,在架構(gòu)修改之前這樣的事情幾乎是不敢做的,因?yàn)橐坏┥壦杏脩羧繑嚅_連接,而現(xiàn)在用戶則基本無感覺。Gate上的緩存層為后端減少了一些壓力,這個(gè)緩存是按照請求的md5key做的,并根據(jù)協(xié)議配置時(shí)效,有此cache后端大多數(shù)服務(wù)可不設(shè)計(jì)緩存或降低緩存設(shè)計(jì)的復(fù)雜度。Gate上針對敏感數(shù)據(jù)統(tǒng)一做了加密處理,主要是辛辛苦苦整理的數(shù)據(jù)不能輕易讓競爭對手竊去了,呵呵。Gate也做了壓縮,現(xiàn)在是針對>=128長度的包進(jìn)行壓縮,使用了qlz,壓縮效率還是很不錯的,速度很快。目前gate后端掛接的既有win上的server也有linux上的server,這是一開始就這么規(guī)劃的,現(xiàn)在看來當(dāng)初的目的達(dá)到了,混合發(fā)揮各自的優(yōu)勢,有的項(xiàng)目在原有系統(tǒng)上跑得好好的,沒必要重新開發(fā)嘛。

             

            協(xié)議設(shè)計(jì)上本來我是計(jì)劃二進(jìn)制混合json格式,以二進(jìn)制為主,但嘗試了一個(gè)協(xié)議之后發(fā)現(xiàn),這邊的小伙子們對直接操縱內(nèi)存普遍技術(shù)不過關(guān),他們大多是從java開始的,后來才學(xué)習(xí)c,對字符串用得很熟練,權(quán)衡之下采用了json為主,混合二進(jìn)制為輔的方案,這樣修改之后的協(xié)議和他們之前使用的xml類似,就是更小更緊湊一點(diǎn),使用方法上很類似,從現(xiàn)在的效果看還行,使用json格式為主的協(xié)議當(dāng)然不能跟使用pb之類的相比,解析效率上大約單線程每秒解析20來萬10個(gè)obj的對象,速度上不算太快但也不算太慢,對付一秒至多幾萬數(shù)據(jù)包的應(yīng)用來說還是夠的,因?yàn)楝F(xiàn)在cpu計(jì)算能力普遍過剩,使用json的另個(gè)好處就是增刪字段很方便,各個(gè)版本之間不需要太考慮版本的問題,要是全用二進(jìn)制格式就要麻煩很多了,在使用壓縮之后,目前的json格式協(xié)議比之前的xml協(xié)議減少了2/3的帶寬使用,總體效果還是可以的。使用json調(diào)試也很方便,我提供了一個(gè)工具,寫后端的就直接用該工具按照json格式收發(fā)數(shù)據(jù),無需等client開發(fā)好了再去做后端,之后做client也很方便,請求發(fā)過去之后返回來的就是標(biāo)準(zhǔn)的json格式數(shù)據(jù),同樣的解析方法,每個(gè)不同的應(yīng)用就按照不同的格式處理下即可,和web等模塊交互也很方便,這可算是額外的好處了。

             

            總之,雖然json格式存儲效率和解析效率跟二進(jìn)制方式還差半個(gè)量級到一個(gè)量級,但合理使用還是可以的,特別是跟xml相比優(yōu)勢很明顯,權(quán)衡使用吧,當(dāng)然追求極致效率可能還是用pb之類的更合適一些,或者自己設(shè)計(jì)tlv格式。

             

            Posted on 2011-01-11 13:33 袁斌 閱讀(2539) 評論(3)  編輯 收藏 引用 所屬分類: c++

            Feedback

            # re: 最近項(xiàng)目架構(gòu)及協(xié)議決策  回復(fù)  更多評論   

            2011-01-11 18:11 by true
            經(jīng)驗(yàn)之談,我之前有個(gè)服務(wù)器內(nèi)部的交互接口,就是傳的std::map<string,string>,文本協(xié)議的動態(tài)性方面有優(yōu)勢

            # re: 最近項(xiàng)目架構(gòu)及協(xié)議決策  回復(fù)  更多評論   

            2011-01-14 13:03 by ouyang
            怎么做到更新時(shí)用戶不斷線的?架構(gòu)上是怎么安排的?最好有點(diǎn)圖片輔助一下,這塊沒看太懂。謝謝!

            # re: 最近項(xiàng)目架構(gòu)及協(xié)議決策  回復(fù)  更多評論   

            2011-01-14 13:09 by 袁斌
            @ouyang
            gate升級還是會斷線啊,后端服務(wù)器升級用戶不斷線,因?yàn)間ate維護(hù)和客戶端的連接,gate做了job的管理,在后端服務(wù)器升級好之后又重新分派job,這樣給用戶的感覺就是執(zhí)行稍慢了一點(diǎn)。
            久久99精品久久久久久噜噜| 久久精品天天中文字幕人妻 | 久久久久久国产精品无码下载| 国产激情久久久久影院小草| 少妇被又大又粗又爽毛片久久黑人| 久久香综合精品久久伊人| 国内精品伊人久久久久影院对白| 久久精品亚洲精品国产欧美| 人妻无码αv中文字幕久久琪琪布| 无码人妻久久一区二区三区| 狠狠色伊人久久精品综合网| 超级碰碰碰碰97久久久久| 狠狠狠色丁香婷婷综合久久五月| 久久综合色区| 国产一区二区精品久久凹凸| 四虎影视久久久免费观看| 99re久久精品国产首页2020| 亚洲色大成网站www久久九| 欧美与黑人午夜性猛交久久久| 亚洲va久久久噜噜噜久久天堂| 国产免费福利体检区久久| 久久精品国产亚洲AV无码娇色| 伊色综合久久之综合久久| 久久er国产精品免费观看2| 7777久久久国产精品消防器材| 久久99精品久久久久久噜噜| 国产精品久久久久久| 久久亚洲欧美国产精品| 久久久精品久久久久影院| 久久强奷乱码老熟女| 99热成人精品免费久久| 久久本道伊人久久| 精品久久久久久综合日本| 久久香综合精品久久伊人| 国色天香久久久久久久小说| 久久这里只有精品首页| 国色天香久久久久久久小说 | 久久久久久久久久久久久久| 2021久久精品免费观看| 亚洲国产高清精品线久久 | 久久久久成人精品无码|