一個開源的IoC採集伺服器體系結構設計

基於IoC思想設計的系統架構

作者：成曉旭

http://blog.csdn.net/CXXSoft/

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

1.         引言

Java領域的開發人員，可以採用spring開源框架，快速構建自己的業務應有系統，本人羨慕不已。但是在我採用的傳統開發語言、專業應用領域，都沒有這樣的好框架可以沿用。於是早有自己設計一個IoC框架，適用於本人涉及的實時監控、通訊採集領域。

“他山之石、可以攻玉”。其實IoC、DI等優秀的分析、設計理論未必非要用來構架通用的基礎開發框架，在具體的應有系統開發中借用，同樣能構建靈活的系統體系架構，尤其是對於企業戰略性的長期的產品、系統的構建，更是事半功倍。

2.         系統背景簡介

在實時監控、資料採集等通訊類系統中，通常的設計都是：將資料採集或者與底層邏輯單元（比如：底層的軟體子系統、硬體終端、遠端裝置）通訊的邏輯功能獨立封裝在一個子系統中，實現基礎通訊收發、通訊方式分化、通訊流程控制、底層協議規整、基礎資料整合等網路通訊、資料採集職責。

本設計是針對常見的實時監控、資料採集系統。下面以一個典型的通訊採集伺服器應有為例：系統的底層是硬體採集裝置，硬體裝置完成整個系統與外界環境或者裝置的互動；上層的軟體系統完成與自己硬體裝置的互動，並且對採集的資料進行分析、處理、儲存、與外部系統介面。

3.         問題

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

1.      整個系統被設計成一個“非常龐大”的“業務排程控制類”，沒有進行職責的拆分和封裝；

2.      在通訊方式實現類（比如：串列埠通訊類、語音卡控制類、TCP/IP通訊類）中完成所有業務處理功能；（絕大多數板卡廠商Demo程式就是這樣演示的，有意無意間誤導了很多剛剛接觸CTI、IVR系統開發的入門者）

3.      對於多工併發，多個裝置上、下行同時通訊的管理非常複雜；

4.      對於需求變化的適應性非常差；

5.      系統程式碼幾乎沒有可複用性了。

4.         新問題

針對上述問題，總結、分析以往經驗和教訓，以“程式碼複用”為出發點重新設計了通訊採集系統體系架構，並較好地解決這些突出問題，並梳理出大量可複用的功能程式碼。詳細說明請參考《一個典型的採集伺服器體系結構設計》一文：http://blog.csdn.net/cxxsoft/archive/2006/09/18/1236331.aspx。

但是，後來再次開發通訊採集伺服器，以應有於不同的業務需求時，發現原來的架構存在如下的典型問題：

1、“採集控制器”幾乎不能重用、但與新開發的採集控制模式非常相識。但是，每次新開發的“採集控制器”邏輯都非常相識，但必須修改業務採集類的類名和方法名，修改狀態機的轉換關係，修改協議呼叫的類名和方法名。

2、“業務採集類”的變化，會直接影響到“採集控制器”。

3、“通訊協議類”的變化，會直接影響到“採集控制器”。

4、通訊控制流程、時序的變化，會直接影響到“採集控制器”。並且要正確實現這些變化，必須在與此無關的“採集控制器”中，小心翼翼地扣程式碼出來改。

5.         IoC重構設計

         開源的通用採集伺服器，是在原有系統架構的基礎上，增加業務抽象介面，引用IoC的設計理念，倒置互動類之間的依賴關係，採用DI來實現類之間的依賴關聯的動態關聯。

1、   抽象“業務排程核心類”的核心邏輯流程，將所有類方法的呼叫設計成對介面方法的呼叫。

2、   抽象“採集控制類”的核心邏輯流程，將所有類方法的呼叫設計成對介面方法的呼叫。“採集控制器”類被設計成一個通用的“工控機主機板”，只要遵循“主機板”約定的介面，換插不同的“業務採集類”、“通訊協議類”，就可以實現完全不同的採集業務需求、按照完全不同的通訊協議與底層模組通訊。

3、   將“採集控制類”中的狀態機管理邏輯剝離出來，將狀態機檢測和控制程式碼設計成對介面方法的呼叫。只要遵循狀態機介面，就可以靈活實現不要業務需求的狀態轉換控制，在執行期動態建立狀態機例項，並注入到“採集控制類”，完全接觸“採集控制器”與“業務狀態機類”靜態依賴。

4、   去掉“通訊介面卡”、“協議介面卡”，增加“通訊介面”、“協議介面”和“業務介面”，按照介面要求重構通訊類、協議類、採集業務類，解決原來系統架構中：新增一種通訊方式、通訊協議時，還必須在相關的介面卡中增加新型別識別程式碼的設計弊端。

6.         技術基礎與規約

本設計的核心的設計原理：IOC容器根據反射機制動態建立實現約定介面的業務物件，動態注入到採集排程控制器中。採集排程控制器是一個高層次抽象的Active Class，自動不斷地呼叫狀態機介面方法來執行“業務採集類”要求的業務通訊指令。

本設計的核心的重要設計約定：採集排程控制器只呼叫抽象的介面方法，那麼具體的上層業務任務，如何動態的翻譯成具體的通訊協議？又如何知道當前的任務如何開始，何時結束？本設計要求：業務採集類必須管理好自己的業務步驟與通訊協議之間的對應關係（確實非常難以在抽象，用動態配置的方法使用起來反而更復雜），採集排程控制器只負責動態建立兩者之間的執行期物件關係。業務採集類必須實現採集排程控制器要求的指定介面方法，用以實現採集任務的發起、執行下一條指令、結束、異常重發、異常中止、故障處理等採集流程控制功能。這正好是採集排程控制器高層抽象的價值和通用性的設計基礎。

框架使用者只需按照介面約定，編碼實現具體業務需求的相關採集、狀態機、協議業務類；在配置這些類的執行期引數，採集伺服器就大功告成。採集伺服器在允許時，會自動載入配置引數，動態建立相關的業務邏輯物件，並完成依賴注入，整個系統就能按具體的業務要求完成通訊、採集任務。

7.         採集伺服器設計

           通訊採集伺服器是常常是實時監控、資料採集類系統的核心，實現與底層的軟體子系統、硬體終端、遠端裝置的通訊、下行命令的執行、上行資料的接收、協議解析，並且完成業務資料的分析以及顯示驅動。它既是系統的通訊樞紐，也是業務核心。

           下圖是基於IoC理念重新設計的通用的開源採集伺服器子系統體系結構：

8.         核心元件設計簡介

1.  業務資料介面

以統一的方式，輸出本框架按配置的“通訊模組”、“通訊協議”、“採集業務類”所採集到的資料。框架使用者實現此介面的方法可以繼續分析、處理、儲存、展現業務資料。

2.  外部系統介面

本系統對外部系統的介面，目前沒有定義具體方法，屬於框架設計預留介面。框架使用者可以實現此介面，定製通訊協議、通訊方式實現與外部系統資訊互動。外圍系統通過此介面向“業務排程核心類”發起通訊命令、操控底層裝置、實時提取裝置狀態等業務請求。

3.  業務排程核心類

是採集子系統的業務排程核心類和業務請求中轉站。外部系統的命令請求通過“外部系統介面”轉入到“業務排程核心類”，“業務排程核心類”將命令請求存入命令佇列中共“”執行；“”採集到資料之後，呼叫“資料介面”的方法將資料返回到“業務排程核心類”，之後，“業務排程核心類”呼叫“業務資料介面”或者“外部系統介面”將業務資料反饋到更上層模組。

4.  任務佇列管理類

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

5.  採集排程控制類

管理、協調其下的“採集業務類”、“通訊實現類”、“業務狀態機類”、“通訊協議類”等模組，完成所有的通訊控制及資料採集功能。通過呼叫任務介面獲取採集指令；之後，呼叫業務介面（業務介面由“採集業務類”實現，在具體使用中由框架使用者根據自己的業務採集需求開發），獲取具體的通訊指令；根據通訊指令呼叫正確的協議介面（協議介面由“通訊協議類”實現，在具體使用中由框架使用者根據自己的通訊協議需求開發）獲得通訊幀；最後，啟動狀態機開始本次採集任務的執行。採集排程控制器

6.  採集業務類

封裝當前系統的具體採集業務物件，為通用的“採集排程控制類”定製具體的採集任務。本質就是：把上層的“抽象任務”細化成具體的“通訊幀”和“通訊控制步驟”、是一個簡單的“工作流定製器”。

7.  業務狀態機類

實現狀態機介面，根據採集業務狀態的控制、轉換需求，框架使用者定製開發。主要用於通訊鏈路的通斷控制、資料收發、忙閒標識及轉換等業務狀態機邏輯。

8.  採集方式類

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

9.  通訊協議類

封裝系統中軟體與底層軟體子系統、硬體裝置、遠端終端的通訊協議。

9.         設計模式與原理

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

2)           “業務排程核心類”採用Mediator模式。

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

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

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

6)           “業務採集類”，對多協議的自動處理採用Chain Of Responsibility：將多個協議元件組織成一條“職責鏈”，實現對當前通訊協議的自動識別、自動解析功能。

7)           “採集排程控制器”，考慮併發和效能，採用“通道”的實時設計模式：以儘可能地提升系統併發能力、提高系統吞吐能力。

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

10.     應有例項

    採用此框架的體系架構，框架使用者只需按“任務介面”實現自己特定的“任務佇列管理類”，按“業務介面”實現自己特定的“採集業務類”，按“狀態機介面”實現自己特定的通訊業務控制“業務狀態機類”，再按“協議介面”實現自己特定的“通訊協議類”，就能夠非常快速地開發一個功能完備、執行穩定的通訊採集伺服器。目前，應有此框架已成功構建“指紋採集系統”、“糧情測控系統”的通訊採集伺服器。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1775341