作者：CppExplore 網址：http://m.shnenglu.com/CppExplore/
《技術系列綜述（一）》介紹了網絡層部分。網絡層基本都是多路復用函數(shù)作為運行的主線程，使用管道或者sockpair與之通訊，這是網絡層線程的固有特點，和業(yè)務線程的呈現(xiàn)方式完全不同。經過網絡層以后，數(shù)據(jù)開始流向業(yè)務線程，現(xiàn)在就順著數(shù)據(jù)流向往上看。
一 業(yè)務線程
《技術系列之 線程（一）》有對線程的一個入門描述，里面的消息隊列只是示例，真實可用的可以看《技術系列之 線程（二）》。
（1）業(yè)務線程的劃分
在業(yè)務層面，數(shù)據(jù)結構仍然是服務器程序的核心。整理出業(yè)務需要的數(shù)據(jù)結構，據(jù)此劃分線程，保證每個數(shù)據(jù)結構都在它所屬的線程中被修改。如果其它線程想修改該結構，則需要向本線程發(fā)送消息，由本線程修改。當然這只是理想情況，有時候處于性能的需要或者和網絡層的交互，需要跨線程訪問其它線程的數(shù)據(jù)，此時則需要加鎖，這也是線程間交互陷入混亂的一個開端，這種情況要限制在一個很小可控的范圍內。
（2）帶消息隊列的線程實現(xiàn)
OA/CRM/WorkFlow的系統(tǒng)的關鍵在于業(yè)務的整理、面向對象的設計。而網絡服務器不同，服務器的業(yè)務相對清晰，相關性強，它設計的關鍵在于數(shù)據(jù)模型的整理、線程的劃分。可以說線程是服務器的骨架。這里引入幾乎每個服務器都會有的一個基礎模塊：帶消息隊列的線程類。《技術系列之 線程（二）》實現(xiàn)了一個簡單的線程消息隊列。在該消息隊列基礎之上進一步封裝，實現(xiàn)帶消息隊列的線程類。該類的靜態(tài)類圖如下：

ThreadQueue參見《技術系列之 線程（二）》。
start方法中參數(shù)默認為1，大于1則是線程池的實現(xiàn)，里面以線程的方式啟動run函數(shù)，線程號存入vector，供停止時用。putq方法在其它線程中調用，向該線程發(fā)送消息，run方法中循環(huán)調用getq獲取消息，調用deal_msg處理。實際的業(yè)務線程只需要繼承該類即可成為帶消息隊列的線程。
（3）監(jiān)控線程
基于上面這個基礎模塊，可以進一步開發(fā)監(jiān)控線程，監(jiān)控線程定時向各個線程發(fā)送心跳消息，各普通線程收到心跳信息后向監(jiān)控線程回復，如果某個線程在一定時間內沒有回復心跳，則可以采取進一步的修復處理。該方案可以作為系統(tǒng)安全的一個備選方案。
以上思想同樣適用于嵌入式平臺，很多嵌入式平臺使用多進程協(xié)同處理消息，進程之間使用共享內存或者系統(tǒng)消息隊列通訊，思想大同小異，并且同樣可以設計監(jiān)控進程。
二 消息映射
（1）消息定義以及處理示例
有了線程消息隊列，也有就有消息傳遞，接下來就是業(yè)務線程獲取到消息處理消息。一個業(yè)務線程可能要處理多種消息，為區(qū)分不同的消息，引入消息類型。如下：

enum MsgType
{
    MSG_TYPE_1＝65,//64一下預留，用于統(tǒng)一的管理控制
    MSG_TYPE_2,
    ..
    MSG_TYPE_MAX
};
struct Msg
{
    MsgType type;
    MsgData data;
};

switch(msg->type)
{
    case MSG_TYPE_1:
         do_msg_type_1_();
         break;
    case MSG_TYPE_2:
         do_msg_type_2_();
         break;
    ..
    default:
             do_default_msg_();
             break;
}

（2）從代碼熵引入查表法
這里引入“代碼熵”的概念，用于描述代碼的混亂程度。每千行代碼中，出現(xiàn)一個“else”，代碼熵加1，出現(xiàn)一個“case”，代碼熵也加1。如果1k行代碼的熵大于7，我們就認為這個代碼已經開始變的混亂了。
因此當消息類型不多的時候，使用case是個不錯的選擇，當處理的消息大于7個并且有擴充趨勢的時候，我們就要想另外的辦法來代替這種switch...case...的寫法。
消除else和case最直接的想法是查表法，使用數(shù)組下標標記消息類型，數(shù)組保存消息處理方法指針。這里不使用map，查詢需要o(lgn)不如數(shù)組來的直接，另外設計期間就已明確知道消息的類型以及對應的處理函數(shù)，不需要動態(tài)增減，也不需要使用vector，直接簡單的方法就是定義一個static的數(shù)組表。
（3）消息映射
直接的數(shù)組展現(xiàn)方式不攜帶語義，展現(xiàn)方式不直觀，維護和擴充都讓人頭大。這里可用借助宏包裹數(shù)組，提供可讀的展現(xiàn)方式，如下：

BEGIN_MESSAGE_MAP(SessionManager,SessionMsg)
    ON_MESSAGE(MSG_TYPE_1, SessionManager::do_msg_type_1_)
    ON_MESSAGE(MSG_TYPE_2, SessionManager::do_msg_type_2_)
    
END_MESSAGE_MAP()

如果你熟悉MFC，一定很熟悉這種消息映射的定義方式。這種消息映射的定義方式，從可維護、可讀方面比直接的數(shù)組更進了一步。宏BEGIN_MESSAGE_MAP、ON_MESSAGE的實現(xiàn)方式不再詳寫，如果讀者實在想象不出來，可以參見《技術系列之 狀態(tài)機（一）》中的狀態(tài)機映射宏的定義方式。使用的時候在deal_msg中直接根據(jù)消息類型找到數(shù)組中的消息處理函數(shù)進行處理，如果你認為這樣暴露了消息映射背后的數(shù)組結構，可以把這個尋找消息處理函數(shù)的工作也封裝到基類IMsgThread中。
（4）成員函數(shù)委托
上面的消息映射宏展開后實際是一個靜態(tài)數(shù)組，而方法do_msg_type_1_/do_msg_type_2_也必須是類的靜態(tài)成員函數(shù)（普通類成員函數(shù)指針不能轉化為普通函數(shù)指針）。通過類的靜態(tài)成員函數(shù)訪問類的非靜態(tài)屬性或者方法如下：在消息中攜帶該類指針handler，處理方法中取到handler指針轉換類型，通過指針操作。
當代碼中充斥大量通過靜態(tài)成員函數(shù)訪問對象私有屬性的時候，這無疑是一種丑陋的寫法（事實并沒有這么嚴重）。
這里就該boost::function，boost::bind出場了。如果你喜歡，也可以直接寫模版實現(xiàn)。也可以參見csdn文章《成員函數(shù)指針與高性能的C++委托》
（5）題外話
1、統(tǒng)一的展現(xiàn)方式。
不僅變量的命名需要統(tǒng)一規(guī)范，方法的調用邏輯同樣需要統(tǒng)一，這可以幫助你明確程序中數(shù)據(jù)的流向以及保證程序持續(xù)的擴充、維護。相對于簡單的命名規(guī)范，方法調用邏輯的統(tǒng)一更為重要。
以線程類舉例說2點（1)其它線程類不能直接調用其它線程的putq方法向對應線程發(fā)送消息。正確的做法是調用對應線程類的方法，由該方法負責向本線程發(fā)送消息。
(2）發(fā)送消息的方法/處理消息的方法職責要明確、命名要統(tǒng)一。
發(fā)送消息的方法負責把方法參數(shù)轉化為消息內容，調用putq發(fā)送消息，該方法不得操作本類的任何私有屬性。
處理消息的方法負責對消息做出處理、響應。
命名方面，比如發(fā)送消息的方法可以以ON_開頭，處理消息的方法可以以DO_開頭。
這些規(guī)范不應該只是規(guī)范，而應該是發(fā)自內心的需要。當然沒有什么規(guī)范是必須的，你仍然可以使用你喜歡的或者認為可行的方式，如果你的方法在程序1w行、10w行、50w行的時候，仍能清晰表現(xiàn)程序的數(shù)據(jù)流向，仍有很好的可維護性、可擴充性。
2、開發(fā)領域的烙印。
不多說了。一句話:重要的是思想，不是平臺和語言。