• <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>
            最近公司準備開發(fā)一個新產品,需要重新設計一套新的框架,但是就這框架中各模塊的通信方式,大家產生了爭論,主要集中在各模塊的交互方式是消息耦合還是接口耦合。

            需求大概這樣,我們需要封裝一套客戶端SDK, 暴露一系列API給外部用,而這套SDK內部會有很多模塊組成,這些模塊之間相互會有交互。

            第一種設計是基于接口耦合,框架如下:


            這種接口方式的設計要點是:
            a. 各模塊以類似COM組件的方式封裝和暴露接口,也就是說模塊會以接口的形式暴露接口,并且以Sink的方式通知外部事件。比如模塊A的接口如下
            class IA
            {
            public:
                virtual void fun1() = 0;
                virtual void fun2() = 0;
                .
                virtual void int AdviseSink(IASink* pSink) = 0;
                virtual void bool UnAdviseSink(int nCooki) = 0;
            }

            class IASink
            {
            public:
                virtual void Event1() = 0;
                virtual void Event2() = 0;
                .
            }
            b. 有一個統(tǒng)一的模塊管理平臺來管理所有模塊,可以通過該平臺查詢和加載需要的模塊,然后后得到相應的接口指針進行操作。
            c. 各模塊間的交互全都通過直接調用其他模塊的接口或是訂閱該模塊的Sink來實現(xiàn)。

            第二種設計是基于消息耦合,框架如下:

            這種消息方式的設計要點是:
            a. 各個模塊只有一個消息處理接口。 
                class IMessageHandler
                {
                public:
                    virtual void ProcessMessage(Message& msg) = 0;
                };
            b. 中間的消息總線提供消息的訂閱和分發(fā),各個模塊會向消息總線注冊自己感興趣的消息。
            c. 需要調用某個模塊接口 或是 觸發(fā)某個事件時,都是通過向消息總線發(fā)送消息的方式, 然后由訂閱消息的模塊執(zhí)行。

            上面2種架構的設計方式各有優(yōu)劣,下面我們來簡單比較一下:
            (1)耦合性: 盡管基于接口的耦合已經降低了耦合性,但是相比消息來說,顯然是消息方式耦合性更弱。
            (2)可擴展性: 某個模塊新增加一個接口, 接口方式需要新加接口函數(shù),而消息方式只需要新加一個消息類型。即使新增加一個模塊,消息方式只是新增加幾個消息處理類型,非常方便。所以可擴展性來說,顯然也是消息方式占優(yōu)。
            (3)性能: 接口方式是直接調用,可是消息方式需要經過消息總線過濾分發(fā), 顯然性能上接口方式更高。 
            (4)編碼安全性,接口方式是強類型,接口一修改,編譯時就能很快發(fā)現(xiàn)問題;消息方式卻是弱類型,消息修改后,有可能要到運行時才能發(fā)現(xiàn)問題, 另外很多消息內容要做強制了類型轉換才能使用。
            (5)文檔要求: 顯然接口方式相對比較清晰,消息的話每個消息都要詳細定義,并且嚴格按照該定義執(zhí)行。
            (6)可調試性: 顯然接口方式要方便些,消息很可能不小心就會引起混亂。
            (7)監(jiān)控過濾方便性:消息方式走同一總線,可以很方便的增加過濾和監(jiān)控功能, 接口方式則因為各個模塊interface和Sink各不相同,增加這些功能沒那么方便。
            (8)跨線程或是跨進程,甚至跨機器調用:顯然接口方式基本做不到,消息方式的話只要修改總線就可以做到。
            (9)異步支持: 消息方式可以很方便的支持異步,接口方式則做不到。

            經過上面的比較, 我們可以得出一些結論:
            消息方式的強項是耦合性和擴展性,以及監(jiān)控的方便性,個人感覺比較適合于Server端的大規(guī)模應用。
            接口方式的強項是性能高效以及開發(fā)的方便性, 比較適用于同一進程內客戶端的小規(guī)模應用。

            但是大部分時候, 對于架構師或是公司領導,他們會更關注可耦合性和可擴展性,所以他們會傾向于選擇消息方式,盡管有時可能不是那么適用。

            另外,個人覺得編譯時靜態(tài)類型檢測是C++的優(yōu)勢,能讓我們高效而可靠的開發(fā)程序,我們不應該放棄這些優(yōu)勢而去把C++當作弱類型的動態(tài)語言來使用,我在 軟命令接口的適用場合 一文也有相關描述。

            最后,對于該框架的設計,其實我個人傾向于上面2種方式的結合, 即各個模塊的入接口(調用接口)走接口方式,而各模塊內部觸發(fā)的事件走消息總線的方式,雖然沒人采用這種方式,還是在這里記錄一下。

            一個多月了,消息還是接口,領導們老大們關于走何種架構還在爭論中...

            呵呵,不知道各位看客會作何選擇?
            posted on 2012-10-12 22:50 Richard Wei 閱讀(4619) 評論(5)  編輯 收藏 引用 所屬分類: 架構體系

            FeedBack:
            # re: 消息耦合還是接口耦合[未登錄]
            2012-10-13 21:58 | 123
            反駁下:

            多核技術發(fā)展到現(xiàn)在,接口比消息性能好顯然是說不通的。畢竟消息的方式更有利于并行。
            另外,個人覺得接口方式虛函數(shù)一大堆,各種繼承,也不明白開發(fā)能有多方便。

            最后關于接口方式的結論,出發(fā)點也不明確,既然是“同一進程內客戶端的小規(guī)模應用”,接口方式也顯得太大了,難道是為了模式而模式?  回復  更多評論
              
            # re: 消息耦合還是接口耦合
            2012-10-13 22:28 | Richard Wei
            @123
            我們是客戶端應用,各模塊內部卻確實會有多線程,但是各模塊間的調用及事件觸發(fā)都是跑在主線程里,所以這種情況下,如果走消息,基本上要給每個消息維護一個數(shù)組,內部保存哪些人訂閱了該消息,當該消息到達時進行依次分發(fā),所以這里無論是內存大小還是性能都會比接口直接調用消耗更多。

            接口每個方法都有各自不同的明確的參數(shù)定義, 消息的話因為要求所有消息參數(shù)一致,所以會導致參數(shù)含義不明確,內部保存的指針需要強制轉換才能使用。

            "客戶端小規(guī)模應用";是相對“大規(guī)模Server集群”, 其實我們要做的東西本身也挺大挺復雜,好幾十人同時開發(fā)。  回復  更多評論
              
            # re: 消息耦合還是接口耦合
            2012-10-14 15:56 | irons
            我覺得接口更作為一個模塊內的設計,而模塊間還是用消息更好。
            而多大的“模塊”算是一個“模塊”呢?還得自己把握。  回復  更多評論
              
            # re: 消息耦合還是接口耦合
            2012-10-15 09:44 | zaccheo
            和樓主的情況差不多,同樣有一個新項目的設計。采用的思路類似于樓主的第三種思路:各個模塊對外提供接口(模塊實現(xiàn)的業(yè)務接口);模塊內部狀態(tài)變化,向訂閱者發(fā)消息。消息使用 googlebuffer 這樣很容易從二進制的消息體中反序列化出來消息的結構體。

            基于接口的設計中有一個要注意的問題:接口指針的生命周期管理。如是使用智能指針,是否能避免循環(huán)引用的問題?

            看了樓主的分析,我現(xiàn)在倒覺得第二種更好。各個模塊間完全被隔離開了。  回復  更多評論
              
            # re: 消息耦合還是接口耦合
            2012-10-15 10:25 | Richard Wei
            @zaccheo

            接口的管理,我感覺有2種方式: 一種是基于COM的引用計數(shù),大家都可以保存接口指針,這里要避免循環(huán)引用;還有一種是讓Module Manger統(tǒng)一管理,也就是只有Module Manager保存有接口指針,其他模塊不保存接口指針,要使用時統(tǒng)一向Module Manger要。

            第一種高效,第二種相對安全  回復  更多評論
              
            99久久国产综合精品五月天喷水| 久久综合给合综合久久| 成人国内精品久久久久一区| 国产成人综合久久综合| 久久综合九色综合精品| 四虎亚洲国产成人久久精品| 久久精品中文字幕无码绿巨人| 夜夜亚洲天天久久| 久久国产精品无| 精品国产VA久久久久久久冰| 久久性精品| 99久久精品国内| 久久人人爽人人爽人人爽| 久久精品人人做人人爽97| 开心久久婷婷综合中文字幕| 国产亚洲综合久久系列| 久久久久噜噜噜亚洲熟女综合| 久久精品亚洲日本波多野结衣 | 亚洲香蕉网久久综合影视| 日本一区精品久久久久影院| 精品久久久无码21p发布| 成人午夜精品久久久久久久小说| 色综合久久久久久久久五月| 91久久福利国产成人精品| 色欲综合久久中文字幕网| 一级a性色生活片久久无| 国产午夜精品久久久久九九电影| 国产精品国色综合久久| 精品久久久久久久久免费影院| 亚洲嫩草影院久久精品| 青草国产精品久久久久久| 亚洲国产视频久久| 国产精品免费久久久久电影网| AV无码久久久久不卡网站下载| 亚洲va久久久噜噜噜久久| 精品一二三区久久aaa片| 国内精品久久久久影院老司| 久久中文字幕无码专区| 久久er国产精品免费观看8| 久久精品成人影院| 久久精品国产第一区二区|