最近公司準備開發一個新產品，需要重新設計一套新的框架，但是就這框架中各模塊的通信方式，大家產生了爭論，主要集中在各模塊的交互方式是消息耦合還是接口耦合。
需求大概這樣，我們需要封裝一套客戶端SDK, 暴露一系列API給外部用，而這套SDK內部會有很多模塊組成，這些模塊之間相互會有交互。
第一種設計是基于接口耦合，框架如下:
這種接口方式的設計要點是:
a. 各模塊以類似COM組件的方式封裝和暴露接口，也就是說模塊會以接口的形式暴露接口，并且以Sink的方式通知外部事件。比如模塊A的接口如下
c. 各模塊間的交互全都通過直接調用其他模塊的接口或是訂閱該模塊的Sink來實現。
第二種設計是基于消息耦合，框架如下:
這種消息方式的設計要點是:
a. 各個模塊只有一個消息處理接口。
c. 需要調用某個模塊接口 或是 觸發某個事件時，都是通過向消息總線發送消息的方式, 然后由訂閱消息的模塊執行。
上面2種架構的設計方式各有優劣，下面我們來簡單比較一下:
(1)耦合性: 盡管基于接口的耦合已經降低了耦合性，但是相比消息來說，顯然是消息方式耦合性更弱。
(2)可擴展性: 某個模塊新增加一個接口， 接口方式需要新加接口函數，而消息方式只需要新加一個消息類型。即使新增加一個模塊，消息方式只是新增加幾個消息處理類型，非常方便。所以可擴展性來說，顯然也是消息方式占優。
(3)性能: 接口方式是直接調用，可是消息方式需要經過消息總線過濾分發， 顯然性能上接口方式更高。
(4)編碼安全性，接口方式是強類型，接口一修改，編譯時就能很快發現問題；消息方式卻是弱類型，消息修改后，有可能要到運行時才能發現問題， 另外很多消息內容要做強制了類型轉換才能使用。
(5)文檔要求: 顯然接口方式相對比較清晰，消息的話每個消息都要詳細定義，并且嚴格按照該定義執行。
(6)可調試性: 顯然接口方式要方便些，消息很可能不小心就會引起混亂。
(7)監控過濾方便性：消息方式走同一總線，可以很方便的增加過濾和監控功能， 接口方式則因為各個模塊interface和Sink各不相同，增加這些功能沒那么方便。
(8)跨線程或是跨進程，甚至跨機器調用：顯然接口方式基本做不到，消息方式的話只要修改總線就可以做到。
(9)異步支持: 消息方式可以很方便的支持異步，接口方式則做不到。
需求大概這樣，我們需要封裝一套客戶端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. 有一個統一的模塊管理平臺來管理所有模塊，可以通過該平臺查詢和加載需要的模塊，然后后得到相應的接口指針進行操作。{
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;
.}
c. 各模塊間的交互全都通過直接調用其他模塊的接口或是訂閱該模塊的Sink來實現。
第二種設計是基于消息耦合，框架如下:
這種消息方式的設計要點是:
a. 各個模塊只有一個消息處理接口。
class IMessageHandler
{
public:
virtual void ProcessMessage(Message& msg) = 0;
};
b. 中間的消息總線提供消息的訂閱和分發，各個模塊會向消息總線注冊自己感興趣的消息。{
public:
virtual void ProcessMessage(Message& msg) = 0;
};
c. 需要調用某個模塊接口 或是 觸發某個事件時，都是通過向消息總線發送消息的方式, 然后由訂閱消息的模塊執行。
上面2種架構的設計方式各有優劣，下面我們來簡單比較一下:
(1)耦合性: 盡管基于接口的耦合已經降低了耦合性，但是相比消息來說，顯然是消息方式耦合性更弱。
(2)可擴展性: 某個模塊新增加一個接口， 接口方式需要新加接口函數，而消息方式只需要新加一個消息類型。即使新增加一個模塊，消息方式只是新增加幾個消息處理類型，非常方便。所以可擴展性來說，顯然也是消息方式占優。
(3)性能: 接口方式是直接調用，可是消息方式需要經過消息總線過濾分發， 顯然性能上接口方式更高。
(4)編碼安全性，接口方式是強類型，接口一修改，編譯時就能很快發現問題；消息方式卻是弱類型，消息修改后，有可能要到運行時才能發現問題， 另外很多消息內容要做強制了類型轉換才能使用。
(5)文檔要求: 顯然接口方式相對比較清晰，消息的話每個消息都要詳細定義，并且嚴格按照該定義執行。
(6)可調試性: 顯然接口方式要方便些，消息很可能不小心就會引起混亂。
(7)監控過濾方便性：消息方式走同一總線，可以很方便的增加過濾和監控功能， 接口方式則因為各個模塊interface和Sink各不相同，增加這些功能沒那么方便。
(8)跨線程或是跨進程，甚至跨機器調用：顯然接口方式基本做不到，消息方式的話只要修改總線就可以做到。
(9)異步支持: 消息方式可以很方便的支持異步，接口方式則做不到。
經過上面的比較， 我們可以得出一些結論：
消息方式的強項是耦合性和擴展性，以及監控的方便性，個人感覺比較適合于Server端的大規模應用。
接口方式的強項是性能高效以及開發的方便性， 比較適用于同一進程內客戶端的小規模應用。
但是大部分時候， 對于架構師或是公司領導，他們會更關注可耦合性和可擴展性，所以他們會傾向于選擇消息方式，盡管有時可能不是那么適用。
另外，個人覺得編譯時靜態類型檢測是C++的優勢，能讓我們高效而可靠的開發程序，我們不應該放棄這些優勢而去把C++當作弱類型的動態語言來使用，我在 軟命令接口的適用場合 一文也有相關描述。
最后，對于該框架的設計，其實我個人傾向于上面2種方式的結合， 即各個模塊的入接口（調用接口）走接口方式，而各模塊內部觸發的事件走消息總線的方式，雖然沒人采用這種方式，還是在這里記錄一下。
一個多月了，消息還是接口，領導們老大們關于走何種架構還在爭論中， 我等小兵就默默等待吧 ...
呵呵，不知道各位看客會作何選擇？
浙公網安備 33010602011771號