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

    
            

            




            







												


        


            

            
	
	



	

            

            


            
	
		
            
			
            
	

            


            
	
					


            
	
	
            最近公司準(zhǔn)備開發(fā)一個(gè)新產(chǎn)品，需要重新設(shè)計(jì)一套新的框架，但是就這框架中各模塊的通信方式，大家產(chǎn)生了爭(zhēng)論，主要集中在各模塊的交互方式是消息耦合還是接口耦合。

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

            第一種設(shè)計(jì)是基于接口耦合，框架如下:


            這種接口方式的設(shè)計(jì)要點(diǎn)是:
            a. 各模塊以類似COM組件的方式封裝和暴露接口，也就是說模塊會(huì)以接口的形式暴露接口，并且以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. 有一個(gè)統(tǒng)一的模塊管理平臺(tái)來管理所有模塊，可以通過該平臺(tái)查詢和加載需要的模塊，然后后得到相應(yīng)的接口指針進(jìn)行操作。
            c. 各模塊間的交互全都通過直接調(diào)用其他模塊的接口或是訂閱該模塊的Sink來實(shí)現(xiàn)。

            第二種設(shè)計(jì)是基于消息耦合，框架如下:

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

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

            經(jīng)過上面的比較， 我們可以得出一些結(jié)論：
            消息方式的強(qiáng)項(xiàng)是耦合性和擴(kuò)展性，以及監(jiān)控的方便性，個(gè)人感覺比較適合于Server端的大規(guī)模應(yīng)用。
            接口方式的強(qiáng)項(xiàng)是性能高效以及開發(fā)的方便性， 比較適用于同一進(jìn)程內(nèi)客戶端的小規(guī)模應(yīng)用。

            但是大部分時(shí)候， 對(duì)于架構(gòu)師或是公司領(lǐng)導(dǎo)，他們會(huì)更關(guān)注可耦合性和可擴(kuò)展性，所以他們會(huì)傾向于選擇消息方式，盡管有時(shí)可能不是那么適用。

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

            最后，對(duì)于該框架的設(shè)計(jì)，其實(shí)我個(gè)人傾向于上面2種方式的結(jié)合， 即各個(gè)模塊的入接口（調(diào)用接口）走接口方式，而各模塊內(nèi)部觸發(fā)的事件走消息總線的方式，雖然沒人采用這種方式，還是在這里記錄一下。

            一個(gè)多月了，消息還是接口，領(lǐng)導(dǎo)們老大們關(guān)于走何種架構(gòu)還在爭(zhēng)論中...

            呵呵，不知道各位看客會(huì)作何選擇？
             
	
            posted on 2012-10-12 22:50 Richard Wei 閱讀(4620) 評(píng)論(5)  編輯 收藏 引用  所屬分類: 架構(gòu)體系 
            

            







            
	    
    


            
FeedBack:

            
	

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

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

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

            接口每個(gè)方法都有各自不同的明確的參數(shù)定義， 消息的話因?yàn)橐笏邢?shù)一致，所以會(huì)導(dǎo)致參數(shù)含義不明確，內(nèi)部保存的指針需要強(qiáng)制轉(zhuǎn)換才能使用。

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

            

            基于接口的設(shè)計(jì)中有一個(gè)要注意的問題：接口指針的生命周期管理。如是使用智能指針，是否能避免循環(huán)引用的問題？

            

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

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

            第一種高效，第二種相對(duì)安全  回復(fù)  更多評(píng)論
              
            
			
            
			
			
		
            
	








            






            

				

            


    
    







            
	   
	



国产精品久久久久国产A级|
欧美激情精品久久久久久久|
久久久av波多野一区二区|
久久综合丁香激情久久|
日韩亚洲国产综合久久久|
久久久无码精品亚洲日韩蜜臀浪潮|
国内精品伊人久久久久|
人妻少妇精品久久|
99久久精品国内|
久久99热这里只有精品国产|
老司机国内精品久久久久|
久久久SS麻豆欧美国产日韩|
segui久久国产精品|
久久99精品久久久久婷婷|
亚洲精品tv久久久久|
久久青青草原综合伊人|
久久久久人妻精品一区二区三区|
久久久无码精品午夜|
一级做a爱片久久毛片|
熟妇人妻久久中文字幕|
亚洲国产天堂久久久久久|
国产成人99久久亚洲综合精品|
国产成人久久精品一区二区三区|
久久精品国产72国产精福利|
久久夜色精品国产亚洲|
久久精品99久久香蕉国产色戒|
人妻无码精品久久亚瑟影视|
色偷偷88欧美精品久久久|
国产精品99久久精品爆乳|
久久青青草原国产精品免费|
国产V综合V亚洲欧美久久|
久久久久AV综合网成人|
无码日韩人妻精品久久蜜桃|
伊人久久精品无码二区麻豆|
久久精品国产亚洲αv忘忧草
|
久久精品国产影库免费看
|
久久精品www人人爽人人|
亚洲国产精品久久电影欧美|
久久久久亚洲av综合波多野结衣
|
中文精品99久久国产|
久久久无码精品午夜|