一個典型的採集伺服器體系結構設計

gudesheng發表於2008-01-03

伺服器

一個典型的採集伺服器體系結構設計

一個基於大量可複用模組的系統架構

作者：成曉旭

http://blog.csdn.net/cxxsoft

(宣告：版權保留，歡迎轉載、請保證文章完整性)

1、 整個系統簡介

假設系統是一個常見的監控、資料採集系統的例項縮影：系統的最底層是硬體採集裝置，硬體裝置完成整個系統與外界環境或者裝置的互動；上層的軟體系統完成與自己硬體裝置的互動，並且對採集的資料進行分析、處理、儲存、展現。

2、問題

在我工作的軟體專案中，類似的應用存在於多個軟體系統中，雖然這些系統在子系統設計及職責劃分方面也如上圖一般進行了明確的分層及模組化，但在核心的“通訊採集子系統”的設計及實現上存在諸多通病，導致整個子系統的可理解性、可維護性、可測試性、對需求變動的適應性極差。集中表現在：

A、整個系統被設計成一個“非常龐大”的“業務排程控制類”：此類中包括幾乎所有的通訊業務管理、通訊中轉、介面顯示驅動、顯示資料生成等。

B、在通訊方式實現類（比如：串列埠通訊類、語音卡控制類、TCP/IP通訊類）中完成所有業務處理功能：通訊任務管理、下行命令佇列管理、通訊資料的收發、通訊協議的解析、業務資料的分析甚至儲存，甚至有些系統中還包括顯示資料的生成及介面顯示驅動。

C、對於多工併發，多個裝置上、下行同時通訊的管理非常複雜：在通訊處理類中引入非常、非常多的陣列來處理多工併發，增加非常多的控制標誌來標識記錄具體某個裝置當前所處的通訊狀態。由於沒有進行單獨的業務抽象，當系統測試或上線執行之後，系統中實際的執行狀態管理和執行標誌判斷，對除錯人員或者系統維護人員來說，簡單是一場噩夢！“整個系統就跟森林似的！”，已經是很多同事不約而同的感慨。

D、對於需求變化的適應性非常差：如果通訊方式變了，對不起，你必須重新實現通訊處理類；當然，所有的通訊控制邏輯、協議解析、資料分析及儲存、並行控制及管理、佇列管理等功能你也必須重新開發了。如果通訊協議變了、資料分析邏輯變了，你必須小心翼翼、如履薄冰地在“通訊處理類”的那成千上萬行程式碼裡找尋找你關心的蛛絲馬跡。

E、幾乎沒有可複用性了：那個傢伙熬更守夜花兩週研究的語音卡控制程式碼，你想尊重一下那位大俠的勞動成果，直接拿過來用幾乎是不可能的，因為那稀少的語音卡程式碼，早已淹沒在茫茫的業務處理程式碼中了。如果新簽訂的合同需要更換新的通訊採集方式，那成千上萬行業務控制程式碼你想將就用用也是難上加難的。

3、 採集伺服器設計

採集伺服器是整個系統的核心，實現與硬體終端的通訊、下行命令的執行、上行資料的接收、協議解析，並且完成業務資料的分析、儲存以及顯示驅動。它既是系統的通訊樞紐，也是業務核心。

下圖是本人2004年設計的一個採集子系統體系結構的縮影。

A、 通訊採集子系統設計簡介

本系統設計主要參考了大量的實時系統設計模式，並分析、總結了以前多個系統的設計與實現的經驗與教訓。

採集子系統的“外部系統介面類”，設計成Façade模式：在整個系統中，其它子系統需要執行什麼控制命令、或者需要得到什麼資料，只需通過“外部系統介面類”向採集子系統發出簡單的命令請求，具體的實現細節不用操心，採集子系統完成命令之後，將結果再通過“外部系統介面類”反饋給命令發起者。甚至命令的處理邏輯已經完全不同了，發起者仍然可以一如既往地執行相同的命令，得到其期望的反饋資訊。

採集子系統借鑑“微核心”的實時設計模式：核心的通訊、控制處理邏輯被嚴格封裝在“採集控制器”中，“採集控制器”設計為一個抽象的“採集業務狀態機”，也是一個自管理的可執行單元（比如：實現為一個執行緒、或者獨立的服務程式），對外界實現一個通用的類似於計算機CPU一樣的通訊處理器，通過對其外圍增加“命令佇列”、“採集業務類”、“通訊介面卡”等“外圍器件”實現一個針對具體功能應用的“主機板”。

建立整個子系統的業務物件關聯的是一個Mediator模式：用以最大可能地解耦各個功能元件，徹底解決各個功能元件之間直接相互引用（因為這些元件之間存在必然的邏輯關聯）的問題。每個功能元件都只需引用Mediator，也只需與Mediator類互動。比如：外界介面類通過Mediator與命令佇列互動，採集控制器的資料只能通過Mediator來儲存到資料庫中，從此不再引用複雜的資料庫相關類及程式碼，採集到的資料也通過Mediator與顯示控制器互動，不再與介面元件緊密耦合。Mediator是採集子系統的業務排程中心和請求中轉站，但是它從不自己具體實現任何功能。

在資料處理方面，引入“命令佇列”作為資料快取機制：“命令佇列”是子系統“任務資訊”的分界點，其上是任務的請求者，其下是任務的執行者，是典型的Command模式應用。除了快取下行命令之外，“命令佇列”主要目的是降低“業務排程中心”與“採集控制器”的耦合度，並且解決“採集控制器”與“業務排程中心”之間“非同步執行”的問題。

B、 基本出發點就是可複用性：

a) 通訊採集方式（如：串列埠通訊類、語音卡控制類、TCP/IP通訊類）程式碼可複用

b) 命令佇列管理程式碼可複用

c) 標準介面通用元件庫

d) 通訊協議程式碼可複用（本系統內通用）

e) 通訊採集業務程式碼可複用（本系統內通用）

f) 業務DAO類程式碼可複用（本系統內通用）

g) 外部系統介面類（本系統內通用）

C、 應用的設計模式或者沿用的設計模式原理：

a) 整個系統採用MVC的設計模式：業務資料、顯示控制及介面顯示嚴格分層，單獨實現。業務資料通過下層模組產生，通用“業務排程核心”這個中介與“介面介面定製類”這個控制器互動；控制器“介面介面定製類”可以根據不同的顯示需要進行定製，與不同的介面元件互動，可滿足不同的顯示需求；在介面顯示層，引用了其它專案中實現的“標準介面通用元件庫”中的部分原始碼。

b) 業務排程中心採用Mediator模式。

c) 採集控制器採用“微核心”的實時設計模式。

d) 命令佇列採用Command模式：以強制分離命令的發起者與命令的執行者。

e) 多通訊方式、多通訊協議的支援方面都採用Adapter模式：解耦“採集控制器”與“通訊方式”，“採集控制器”與“通訊協議”，並方便更換或者增加的通訊方式、通訊協議。

f) “採集控制器”採用State模式：通過抽象業務狀態機，可以靈活地實現不同採集控制需求。並且，如果採集方式類是語音卡之類的裝置時，採集類裡面也往往採集“狀態機”模式來管理這類自身以狀態方式驅動的通訊裝置。

g) “採集控制器”內部，對多協議的自動處理採用Chain Of Responsibility：將多個協議元件組織成一條“職責鏈”，實現對當前通訊協議的自動識別、自動解析功能。（當時的系統沒有實現）

h) “採集控制器”內部，考慮併發和效能，採用“通道”的實時設計模式：以儘可能地提升系統併發能力、提高系統吞吐能力（當時的系統沒有實現）。

i) “採集控制器”內部，採用“輪巡”和“中斷”的實時設計模式：為檢測通訊鏈路是否可用，在通訊空閒時，系統要求與硬體終端進行定期“通訊握手”，當“採集控制器”檢測以“命令佇列”或者“硬體終端”的任務請求時採用“中斷”方式立即響應上、下行命令。

D、 主要模組簡介

a) DB訪問引擎：通用的資料庫訪問引擎程式碼，實現對各類不同的資料庫訪問程式碼；

b) 業務DAO類庫：本系統的資料庫業務邏輯程式碼庫；

c) 業務排程核心類：是採集子系統的業務排程中心和業務請求中轉站。外部系統的命令請求通過“介面子系統”轉入到“業務排程核心類”，“業務排程核心類”將命令請求存入命令佇列中；“採集控制器”採集到資料之後，回撥到“業務排程核心類”，之後，“業務排程核心類”呼叫“業務DAO類庫”相關方法完成資料儲存，並通過“介面介面類”完成資料顯示；再通過“外部介面類”向其它系統反饋實時執行資訊。

d) 外部系統介面類：採集子系統與外部系統的資訊介面模組，通過定製的協議和通訊介面與外部系統提供資訊互動；比如：接收外部系統的命令請求、向外部系統反饋命令執行結果。

e) 命令佇列：下行任務資訊快取類。“業務排程核心類”向其中增加命令請求；“採集控制器”自動檢測是否有新命令請求，當檢測到後立即“中斷”通訊握手，執行請求，執行成功之後，從佇列中刪除該命令。

f) 採集控制類：檢測命令佇列，管理、協調其下的“採集業務”、“通訊方式”、“通訊協議”等模組，完成所有的通訊及資料採集功能。

g) 採集業務類：封裝當前系統的具體採集業務物件，為通用的“採集控制類”定製具體的採集任務。

h) 通訊介面卡：採集方式的Adapter。

i) 協議適配類：通訊協議的Adapter。

j) 採集方式類：封裝具體的串列埠、TCP/IP、語音卡等通訊採集類，實現具體的通訊方式控制及通用的資料收發介面。

k) 通訊協議類：封裝系統中軟體與硬體的通訊協議。

4、 需求變化的易適應性例項

採用此體系結構的軟體在2005年現場試點中，果真遇到為其它廠商提供軟體介面的需求變更，並要求快速實現，最終，需求的變更三次，此結構基本上都能較快滿足。具體的示例如下（分割後實際用到的模組包圍在紅線以內）：

A、只提供包括通訊方式控制和硬體協議的介面模組（以DLL方式提供）：