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

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

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

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