• <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>
            我要啦免费统计

                                                           一種采用消息框架切分?jǐn)U展的設(shè)計方法

                                                                                                                   Lastupdate201246 蔡東赟

            http://www.LomoX.hk社區(qū)發(fā)布。

            ps:blog貼不了圖啊,可以再附件下載:一種采用消息框架切分?jǐn)U展的設(shè)計方法

             

            傳統(tǒng)的界面uiuilogic隔離方式采用的是接口的方式,為了解耦合,為了使隔離層之間業(yè)務(wù)統(tǒng)一。如圖,ui層你就負責(zé)界面的,你想用什么語言都可以; uilogic層你就只做ui傳下來的io,鍵盤鼠標(biāo)等的操作行為解析; applogic你就負責(zé)業(yè)務(wù),計算執(zhí)行的任務(wù)。這樣子,一個需求就可以同時三個人開發(fā)了。 

                    

             

             

             


            大型基礎(chǔ)軟件為了解耦而做的隔離,導(dǎo)致接口聲明膨脹。可以看到applogic層和uilogic的接口會無限膨脹,與其帶來的就是維護成本,如果是內(nèi)部定義的接口,書寫的時候你要每個層都提供一份聲明。

                     最近在想提供一個東西做為隔離層,先看圖。

             


                  Applogic uilogic就只有數(shù)據(jù)間的通訊了。采用異步的消息方式,不管你是多線程還是單線程。模塊之間耦合徹底消失。有人會問你這個service用啥。

            Zeromq吧,這是我機器上面測試的速度

            http://m.shnenglu.com/cdy20/archive/2012/04/01/169791.html  單線程一百w120s,那個快啊,如果作為本地的派發(fā)器的服務(wù)端足夠了。

                  通信數(shù)據(jù)如何處理呢?zeromq采用的是字符串發(fā)送,我們可以配合googleprotobuf定義解析協(xié)議數(shù)據(jù)。這個東西可以壓縮,解壓縮協(xié)議非常方便,配上這個高速度的mq,那簡直棒極了。

             

            Zeromq作為一個可以內(nèi)核間、跨進程、跨機器通信的消息隊列,不免又為我們提供了更多的設(shè)計的想象力。這么一個中間的消息的服務(wù)器,我們又可以把applogic切割,分成多個獨立模塊,如圖。

             

             


            如上圖,我們可以不斷拓展
            applogic的模塊,我們可以認(rèn)為這些模塊是獨立的 動態(tài)鏈接庫,獨立的進程都可以,或者是獨立線程,一切通信 進出都是通過發(fā)送send,接收recv

            這個東西我現(xiàn)在遇到的工程項目組就有這個需求,他們要求是能夠并發(fā)開發(fā),甚至兩個人統(tǒng)一個模塊不四個分支同時進行。一個強大的消息框架,讓我的模塊可以成為任何一種定義。

            畫個圈圈,歸納一下:



             上圖紅色圈圈代表bus。


                   上圖抽象的圖如下。

             

             

             

            這樣程序就可以任意擴展了。任意切分了。

             

                     有錯誤和改進方法,請發(fā)到caidongyun19@qq.com.謝謝閱讀。

            共享促進技術(shù)發(fā)展。蔡東赟。www.lomox.hk


            附上提醒:

            對待本框架,個人:建議團隊自由度不要太高,需要根據(jù)團隊項目的特點做一定的規(guī)范約束。否則將面臨質(zhì)量和維護成本遞增。

             from lomox  li:

             如果僅僅是做進程間通信,那是大材小用了
            如果是進程內(nèi)的線程間通信,就不合適
            客戶端面臨的問題是消息中心在進程間和線程間的通信 

             

             

             

            posted on 2012-04-06 11:13 閱讀(1935) 評論(4)  編輯 收藏 引用 所屬分類: 個人框架設(shè)計

            評論:
            # re: 一種采用消息框架切分?jǐn)U展的設(shè)計方法 2012-04-06 12:22 | 飯中淹
            感覺就是MVC。  回復(fù)  更多評論
              
            # re: 一種采用消息框架切分?jǐn)U展的設(shè)計方法 2012-04-06 13:07 | WXX
            Chrome源碼:
            進程間IPC
            進程內(nèi)線程間MsgQueue
            同一線程對象間注冊消息,接受Notification

            封裝的足夠好了,可以借鑒。  回復(fù)  更多評論
              
            # re: 一種采用消息框架切分?jǐn)U展的設(shè)計方法 2012-04-06 13:23 | 蔡東赟
            @WXX
            chrome 看來還是得看看源碼的  回復(fù)  更多評論
              
            # re: 一種采用消息框架切分?jǐn)U展的設(shè)計方法 2012-04-06 15:04 | 蔡東赟
            @WXX
            zeromq估計超越這個了,你只要bind你制定的 ipc impro tcp 就可以了
            這種封裝 也很變態(tài)。  回復(fù)  更多評論
              
            日批日出水久久亚洲精品tv| 久久99精品国产自在现线小黄鸭| 狠狠色丁香婷婷综合久久来来去| 久久午夜无码鲁丝片午夜精品| 亚洲国产日韩欧美综合久久| 久久久久亚洲AV无码网站| 26uuu久久五月天| 综合久久国产九一剧情麻豆| 国产精品九九久久精品女同亚洲欧美日韩综合区 | 99精品国产综合久久久久五月天| 成人久久久观看免费毛片| 久久亚洲精品无码观看不卡| 99久久精品毛片免费播放| 久久夜色精品国产亚洲| 久久久WWW免费人成精品| 久久99精品久久久久久hb无码| 久久综合五月丁香久久激情| 伊人久久大香线蕉精品| 久久精品中文闷骚内射| 精品国产乱码久久久久久呢| 国内精品久久久久久久久| 国内精品久久久久久野外| 久久久久久国产精品免费无码| 久久精品国产亚洲αv忘忧草| 久久露脸国产精品| 久久国产乱子伦精品免费午夜| 久久久91精品国产一区二区三区 | 91精品国产91久久久久福利| 亚洲AV无码久久精品色欲| 久久这里只有精品首页| 久久亚洲精品国产亚洲老地址| 一级a性色生活片久久无少妇一级婬片免费放 | 无码国内精品久久综合88| 伊人久久大香线蕉综合热线| 久久综合伊人77777| 亚洲欧洲精品成人久久奇米网| 欧美久久一级内射wwwwww.| 人人狠狠综合88综合久久| 97视频久久久| 久久久久AV综合网成人| 99久久99久久精品国产片果冻|