• <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ù)群:26678700     
            交流QQ: 704839634
            合作: 1) 可兼職遠(yuǎn)程辦公開發(fā); 2) 有一套Go+Python開發(fā)的行業(yè)短信云平臺(tái)可合作;3)目前正在開發(fā)物聯(lián)網(wǎng)、大數(shù)據(jù)平臺(tái)。

            網(wǎng)絡(luò)通訊服務(wù)器的架構(gòu)選擇

            一個(gè)網(wǎng)友問(wèn)我:他有幾百個(gè)客戶端并發(fā)訪問(wèn)的請(qǐng)求,想選擇boost::asio的現(xiàn)成異步通訊框架,感覺怎么樣。

            對(duì)C++開發(fā)人員來(lái)說(shuō),很多人應(yīng)該不止一次面對(duì)這個(gè)問(wèn)題,甚至是工作了七八年的人。

            我發(fā)現(xiàn)一個(gè)現(xiàn)象:當(dāng)一個(gè)C++開發(fā)人員,面對(duì)一個(gè)服務(wù)器開發(fā)需求時(shí),常常不自覺去想尋找一個(gè)高效的網(wǎng)絡(luò)通訊庫(kù),而且考慮的比其它方面更早。

            效率,是C/C++開發(fā)人員引以自傲的一個(gè)方面,即便嘴里不說(shuō),潛意識(shí)里會(huì)有這個(gè)想法。

            這一潛意識(shí)讓他們?cè)诿鎸?duì)服務(wù)器開發(fā)時(shí),會(huì)不自覺去想要得到一個(gè)最好的網(wǎng)絡(luò)通訊框架,不管是否存在,是否有必要。

            你現(xiàn)在面對(duì)的這個(gè)實(shí)際需求,是否真的需要一個(gè)你心里想要的那個(gè)高效的網(wǎng)絡(luò)通訊框架?

            你的業(yè)務(wù)流程是什么?動(dòng)手在紙上畫一畫,再?gòu)?fù)雜用UML圖設(shè)計(jì)一下,難道除了網(wǎng)絡(luò)通訊,就沒有其它方面更耗時(shí)?更值得關(guān)注?

            真正的平均客戶端連接并發(fā)是多少?頻率有多高?

            你準(zhǔn)備投入多少臺(tái)服務(wù)器,每臺(tái)服務(wù)器的CPU速度、內(nèi)存大小、磁盤轉(zhuǎn)速和采用什么陣列、網(wǎng)卡是100M還是真1000M、網(wǎng)絡(luò)上交換機(jī)和路由器是怎么部署的,客戶端和服務(wù)器之間通訊的距離是有什么特點(diǎn),等等?

            你們有多少開發(fā)人員和測(cè)試人員,這個(gè)項(xiàng)目客戶給你多長(zhǎng)時(shí)間完成,你準(zhǔn)備什么質(zhì)量程度給他交貨?

            我們把思路收回來(lái),就考慮網(wǎng)絡(luò)通訊框架:

            業(yè)務(wù)模型到底適合采用TCP還是UDP?采用長(zhǎng)連接還是短連接?采用異步還是同步?采用阻塞還是非阻塞?

            是手工寫個(gè)簡(jiǎn)單的好,還是采用現(xiàn)成的網(wǎng)絡(luò)通訊框架?

            采用現(xiàn)成的網(wǎng)絡(luò)通訊框架: 選擇boost::asio?選擇ACE?選擇MFC自帶的異步類?。。。。。。

            你熟悉這些框架嗎?他們有多大?你是不是這次只用到那1/1000之一的部分?為了這個(gè)小功能,你到底愿意搞那么一個(gè)龐然大物嗎?

            最后,你這個(gè)子系統(tǒng),一定要用C/C++來(lái)實(shí)現(xiàn)最合適嗎?你還會(huì)其它開發(fā)語(yǔ)言嗎?

            從各個(gè)方面多問(wèn)問(wèn)自己,然后自己試著回答,說(shuō)不定我們先前的疑問(wèn)就不存在了。

            posted on 2012-04-17 20:52 冰果 閱讀(2764) 評(píng)論(2)  編輯 收藏 引用

            評(píng)論

            # re: 網(wǎng)絡(luò)通訊服務(wù)器的架構(gòu)選擇 2012-04-18 12:46 LOGOS

            這說(shuō)明兩個(gè)問(wèn)題:
            1.有個(gè)已知的網(wǎng)絡(luò)庫(kù),方便做接下來(lái)的設(shè)計(jì)。巧婦難為無(wú)米之炊,手中有糧心中不慌。
            2.當(dāng)前并沒有一個(gè)輕量簡(jiǎn)潔高效的跨平臺(tái)網(wǎng)絡(luò)庫(kù),所以才會(huì)挑來(lái)挑去。  回復(fù)  更多評(píng)論   

            # re: 網(wǎng)絡(luò)通訊服務(wù)器的架構(gòu)選擇 2012-04-18 15:12 shaker(太子)

            @LOGOS
            當(dāng)前并沒有一個(gè)輕量簡(jiǎn)潔高效的跨平臺(tái)并且有一定權(quán)威的網(wǎng)絡(luò)庫(kù)
            這個(gè)是問(wèn)題的關(guān)鍵,asio是一個(gè)好選擇  回復(fù)  更多評(píng)論   

            # re: 網(wǎng)絡(luò)通訊服務(wù)器的架構(gòu)選擇 2012-04-19 12:17 朱峰 - everettjf

            c++考慮的就是如此多  回復(fù)  更多評(píng)論   


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


                                                        
            一本色道久久88综合日韩精品| 久久婷婷人人澡人人爽人人爱| 亚洲精品乱码久久久久久按摩 | 久久这里只有精品久久| 久久久精品免费国产四虎| 久久无码国产| 久久精品aⅴ无码中文字字幕重口 久久精品a亚洲国产v高清不卡 | 四虎久久影院| 久久精品国产亚洲欧美| 婷婷国产天堂久久综合五月| 久久久无码一区二区三区| 久久99精品久久久久久齐齐| 99久久夜色精品国产网站| 一级做a爱片久久毛片| 无码人妻精品一区二区三区久久久| 精品久久久久久国产| 一本久久a久久精品亚洲| 久久精品亚洲男人的天堂| 久久精品九九亚洲精品天堂| 中文字幕日本人妻久久久免费| 99精品伊人久久久大香线蕉| 亚洲精品久久久www| 久久久久久久久久久免费精品| 久久久亚洲欧洲日产国码aⅴ| 久久久午夜精品福利内容| 久久精品18| 国产成人久久777777| 久久婷婷久久一区二区三区| 久久精品中文闷骚内射| 99久久精品免费看国产一区二区三区| 久久久99精品成人片中文字幕 | 久久精品一区二区影院| 精品久久一区二区三区| 久久精品视频网| 久久久久久久99精品免费观看| 久久99精品久久久久久动态图 | 日韩欧美亚洲综合久久影院Ds| 久久久精品视频免费观看| 久久亚洲精品无码观看不卡| 久久九九免费高清视频| 18禁黄久久久AAA片|