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

             

             

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

             

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

             

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

             

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

             

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

            Feedback

            # re: 最近項目架構及協議決策  回復  更多評論   

            2011-01-11 18:11 by true
            經驗之談,我之前有個服務器內部的交互接口,就是傳的std::map<string,string>,文本協議的動態性方面有優勢

            # re: 最近項目架構及協議決策  回復  更多評論   

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

            # re: 最近項目架構及協議決策  回復  更多評論   

            2011-01-14 13:09 by 袁斌
            @ouyang
            gate升級還是會斷線啊,后端服務器升級用戶不斷線,因為gate維護和客戶端的連接,gate做了job的管理,在后端服務器升級好之后又重新分派job,這樣給用戶的感覺就是執行稍慢了一點。
            国内精品久久久人妻中文字幕| 久久久久久久国产免费看| 久久人人爽人人爽人人爽| 亚洲中文久久精品无码ww16| 久久精品国产亚洲av麻豆蜜芽| 久久久无码人妻精品无码| 欧美777精品久久久久网| 免费一级欧美大片久久网| 伊人久久大香线蕉av不卡| 久久夜色精品国产亚洲| 伊人久久大香线蕉综合热线| 亚洲精品乱码久久久久久按摩| 精品国产综合区久久久久久| 色偷偷偷久久伊人大杳蕉| 很黄很污的网站久久mimi色| 久久99精品久久久久子伦| 伊人精品久久久久7777| 久久青草国产手机看片福利盒子| 精品国产日韩久久亚洲| 国内精品久久久久久久影视麻豆 | 久久久久久亚洲精品不卡| 亚洲AV无码一区东京热久久 | 国内精品伊人久久久影院| 嫩草影院久久国产精品| 精品久久久无码人妻中文字幕豆芽| 日本精品一区二区久久久| 国产福利电影一区二区三区久久久久成人精品综合 | 99久久精品国产一区二区| 久久99精品国产麻豆蜜芽| 国产精品一久久香蕉产线看| 伊人久久大香线蕉亚洲| 中文字幕无码久久久| 久久久国产视频| 久久人人爽人人爽人人片AV高清| 欧美大战日韩91综合一区婷婷久久青草| 久久国产乱子伦精品免费强| 99国产欧美精品久久久蜜芽| 久久久久亚洲av无码专区| 国产精品久久久久jk制服| 久久午夜羞羞影院免费观看| 亚洲午夜无码久久久久|