不知不覺項目接近尾聲，期間畫了不少設計圖，把能用上的設計模式都用上了。
今天來盤點一下。
主心骨：中介者模式
這次項目呢，我的想法是將各服務器分佈與不同的主機上，所以採用TCP流進行進程間通信，但是呢，實現的時候我就發現，如果要將需要通信的服務器兩兩相連，且不說繁瑣，怎麼拓展？
於是我絞盡腦汁，想起來了中介者模式，於是有了下面這張圖：
工程運行的時候，先啓動中控服務器，中控服務器會用accept的方式接收來自各邊緣服務器的連接。
邊緣服務器連上中控服務器之後，會發一個自認身份的包給中控服務器，完成註冊。
此後，通過註冊的服務器向中控服務器發送的包，只需要在包頭中註明包是給哪個服務器的即可由中控服務器轉交。
往後，如果需要再添置服務器，也只需將新服務器連入中控服務器，自認身份即可。
撥雲見日：責任鏈模式
負責和客戶端建立連接的前置服務器，以及中控服務器，以及將來需要面對大量四面八方消息的服務器，肯定要用到文件描述符監聽模型，我用epoll。
秉着“單一職責原則”，我認爲epoll只需要且只能監聽文件描述符，但是它不應該知道消息內容，更不應該對消息進行處理。
這個問題確實也困擾了我，我想了好久，因爲我以前的做法都是epoll收到消息後，判斷是哪個地方來的消息，如果是監聽套接字，則判定是有新連接上來，處理連接（這裏就需要將網絡連接模塊和epoll模塊放在一起，這是其一）；如果是通信套接字（客戶端）來的消息，那麼就是客戶端有消息上來，還要判斷是否空包（空包爲客戶端掉線，需要處理），若不是空包，則對包進行一個基本的判斷（這裏就需要解壓包模塊的介入，這是其二），之後將包發往中控服務器（這裏就需要進程間通信模塊的介入，這是其三）；對包的處理與轉發還使用了小型線程池（這就需要線程池模塊的參與，這是其四），此外，還有日誌模塊和心跳檢測模塊，這麼多東西，如今一鍋燉在epoll模型中，成何體統？
但是又有什麼辦法呢？請求來了，自然是要回應的啊，要回應，就需要各個模塊之間的配合了，我思來想去，想到了責任鏈模式。
我以前一直覺得這個模式簡直是雞肋，但是這次之後我改觀了，沒有雞肋的設計模式，只有雞肋的設計師。設計模式的優勢是什麼？
- 將請求和處理分開。
- 請求者可以不知道是誰處理了，處理者也不用知道請求者的全貌。
- 兩者解耦，提高系統的靈活性。
於是便有了以下這張圖，也正是這張圖吸引了聽我講這個項目設計的朋友：
圖我是不會再解釋的，代碼也不會放出來，因爲我在我的日報博客中已經講得清楚了。
四面開花：模板方法模式
解壓包模塊和數據庫模塊可是兩個最不穩定的模塊了，因爲這兩個模塊會經常需要進行拓展，它們不像epoll、進程間通信、文件管理等模塊，定下來就基本定下來了，只要要拓展新業務，肯定要加協議，再加數據庫功能，如果將模塊寫死，便無法自由拓展。我問過不少朋他們如何處理這種情況，他們的回答基本都是一致的：寫完就完了，拓什麼展？非要拓展，拆開重寫。
這個問題並沒有困擾我，這個問題很簡單的：依賴倒置原則，這是我很喜歡的一個原則，面向接口編程，只要我將接口定下來了，後面的拓展只要繼承父類，拓展新接口便可。
於是，圖是這樣的：
數據庫還插了單例模式，那小玩意兒就不說了。
其他小圖
再隨便放幾張叫不出模式的圖吧，不過，面向接口編程是真的利於拓展，伸縮自如哦。
潤滑油：服務器間連接
只給你看接口：線程池模塊
整體流程圖
太長了，就分左右兩塊咯。