前面兩篇文章已經介紹了功能服務器FS與應用服務器AS拆開的原因和它們各自的職責。這篇文章我們主要來看看FS和AS的主體框架是怎樣的。首先要說明，無論FS或AS，它們都是一個復雜的系統，特別是AS，它有許多的管理、記錄功能，所以單憑這一篇文章是不可能將它們的每一個方面描述清楚的。相反，我在此文中僅僅給出它們的骨架結構，許多細節都將忽略，看過第一篇文章讀者可以根據主題目錄知道，這些細節會在后面的文章中逐漸補充進來。

FS和AS的最大特點就是采用了“框架＋插件”的結構模式。讓我們先來了解一下FS的骨架是什么樣子的。

一.功能服務器結構

各模塊主要作用

（ 1 ）網絡通訊插件管理模塊：用于加載、管理所有通信插件。通信插件的主要作用是接收客戶端來的消息，不作任何處理直接轉發給消息分派模塊。

（ 2 ）消息分派模塊：將從通訊插件來的字節流分裂為一個或多個請求消息，然后針對沒有請求消息，調用對應的功能插件來處理，并將處理點結果返回給通信插件，最后由通信插件發送給客戶端。

（ 3 ） UI 用戶界面：用于顯示當前的連接，和每個連接上正在請求的服務。并控制加載的各個功能插件和通信插件的相關信息。

（ 4 ）功能插件管理模塊：用于加載、管理所有的功能插件。

（ 5 ）日志記錄模塊：將一些重要的事件信息寫入到 Windows 的事件日志中或日志數據庫中。

DSCore 系統基本特點

（1） DSCore 框架不提供任何具體的功能服務，所有的功能服務封裝在各個插件中。

（2） DSCore 框架主要用于整合各個基礎模塊，并管理所有的插件。

（3） 插件機制可以解決動態加載 / 卸載服務（所謂“熱插拔”）的問題。

（4） DSCore 功能服務器將支持 TCP 、 UDP 、 WebService 、 .Net Remoting 這四種主流的通信協議。并且這四種通信協議也封裝在各自的插件中。當需要更換通信協議時，只需要加載對應的通信插件即可。

（5） DSCore 功能服務器采用“異步＋線程池”或完成端口來對大并發性提供支持。

（6） DSCore 功能服務器將采用對象池來管理連接信息對象。

（7） 功能服務器是一個可復用的框架，它可以適用于各種 C/S 模式應用的服務端框架，面對不同的應用，只需要替換與應用相關的功能插件即可。

二.應用服務器結構

應用服務器的結構相對相對功能服務器來說要復雜許多。

各主要模塊/插件的作用如下：

（1） 用戶管理模塊：用于管理所有在線用戶的狀態，并對用戶作定時掉線檢查。

（2） Basic 消息處理插件：用于處理非功能請求，如登錄請求、退出請求等。

（3） 消息分派模塊：根據消息的類別（基本請求、功能請求），將基本請求轉發給 Basic 消息處理插件處理，而將功能請求通過連接池管理者轉發給功能服務器進行處理。

（4） 回復截獲者插件：用于截獲每一個請求的回復數據，并對期望類型的回復進行跟蹤或其它處理。

（5） 用戶任務報告者插件：用于將需要永久存儲的信息記錄到數據庫或文件，甚至可以發送到專門用戶服務器的消息隊列。

為了更好的理解各個模塊/插件之間的互動關系，可以參見下面的AS消息關聯圖。

注意，由“小圓圈”引出的是事件，而一個箭頭指向小圓圈表示預定事件。上面的圖示是在AS以TCP方式發布服務時的消息關聯圖，如果是UDP方式，這個結構將會簡單許多。所以后面的討論我們將主要集中在TCP方式上，而對其它的通信方式，則可以類推之。

對于上圖，可能還有很多不清晰的地方，沒關系，在后面的介紹中，這些地方會逐漸的清晰起來。從下期開始我們將依照第一篇文章的主題目錄逐漸深入到各個方向的細節中去。下期再見！

企業級服務器設計與實現經驗之系統框架（二）－－功能/應用服務器主體框架