一個開源的 IoC 采集服務器體系結構設計

基于 IoC 思想設計的系統(tǒng)架構

作者：成曉旭

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

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

1. 引言

Java 領域的開發(fā)人員，可以采用 spring 開源框架，快速構建自己的業(yè)務應有系統(tǒng)，本人羨慕不已。但是在我采用的傳統(tǒng)開發(fā)語言、專業(yè)應用領域，都沒有這樣的好框架可以沿用。于是早有自己設計一個 IoC 框架，適用于本人涉及的實時監(jiān)控、通信采集領域。

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

2. 系統(tǒng)背景簡介

在實時監(jiān)控、數(shù)據(jù)采集等通信類系統(tǒng)中，通常的設計都是：將數(shù)據(jù)采集或者與底層邏輯單元（比如：底層的軟件子系統(tǒng)、硬件終端、遠程設備）通信的邏輯功能獨立封裝在一個子系統(tǒng)中，實現(xiàn)基礎通信收發(fā)、通信方式分化、通信流程控制、底層協(xié)議規(guī)整、基礎數(shù)據(jù)整合等網(wǎng)絡通信、數(shù)據(jù)采集職責。

本設計是針對常見的實時監(jiān)控、數(shù)據(jù)采集系統(tǒng)。下面以一個典型的通信采集服務器應有為例：系統(tǒng)的底層是硬件采集設備，硬件設備完成整個系統(tǒng)與外界環(huán)境或者設備的交互；上層的軟件系統(tǒng)完成與自己硬件設備的交互，并且對采集的數(shù)據(jù)進行分析、處理、存儲、與外部系統(tǒng)接口。

<shapetype id="_x0000_t75" stroked="f" filled="f" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t" o:spt="75" coordsize="21600,21600"><stroke joinstyle="miter"></stroke><formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f></formulas><path o:connecttype="rect" gradientshapeok="t" o:extrusionok="f"></path><lock aspectratio="t" v:ext="edit"></lock></shapetype><shape id="_x0000_i1025" style="WIDTH: 414.75pt; HEIGHT: 232.5pt" type="#_x0000_t75"><imagedata o:title="新框架" src="file:///C:%5CTemp%5Cmsohtml1%5C01%5Cclip_image001.png"></imagedata></shape>

3. 問題

在我工作的軟件項目中，類似的應用存在于多個軟件系統(tǒng)中，雖然這些系統(tǒng)在子系統(tǒng)設計及職責劃分方面也如上圖一般進行了明確的分層及模塊化，但在核心的“通信采集子系統(tǒng)”的設計及實現(xiàn)上存在諸多通病，導致整個子系統(tǒng)的可理解性、可維護性、可測試性、對需求變動的適應性極差。集中表現(xiàn)在：

1. 整個系統(tǒng)被設計成一個“非常龐大”的“業(yè)務調度控制類”，沒有進行職責的拆分和封裝；

2. 在通信方式實現(xiàn)類（比如：串口通信類、語音卡控制類、 TCP/IP 通信類）中完成所有業(yè)務處理功能；（絕大多數(shù)板卡廠商 Demo 程序就是這樣演示的，有意無意間誤導了很多剛剛接觸 CTI 、 IVR 系統(tǒng)開發(fā)的入門者）

3. 對于多任務并發(fā)，多個設備上、下行同時通信的管理非常復雜；

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

5. 系統(tǒng)代碼幾乎沒有可復用性了。

4. 新問題

針對上述問題，總結、分析以往經(jīng)驗和教訓，以“代碼復用”為出發(fā)點重新設計了通信采集系統(tǒng)體系架構，并較好地解決這些突出問題，并梳理出大量可復用的功能代碼。詳細說明請參考《一個典型的采集服務器體系結構設計》一文： http://blog.csdn.net/cxxsoft/archive/<chsdate isrocdate="False" islunardate="False" day="18" month="9" year="2006" w:st="on">2006/09/18</chsdate>/1236331.aspx 。

但是，后來再次開發(fā)通信采集服務器，以應有于不同的業(yè)務需求時，發(fā)現(xiàn)原來的架構存在如下的典型問題：

1 、“采集控制器”幾乎不能重用、但與新開發(fā)的采集控制模式非常相識。但是，每次新開發(fā)的“采集控制器”邏輯都非常相識，但必須修改業(yè)務采集類的類名和方法名，修改狀態(tài)機的轉換關系，修改協(xié)議調用的類名和方法名。

2 、“業(yè)務采集類”的變化，會直接影響到“采集控制器”。

3 、“通信協(xié)議類”的變化，會直接影響到“采集控制器”。

4 、通信控制流程、時序的變化，會直接影響到“采集控制器”。并且要正確實現(xiàn)這些變化，必須在與此無關的“采集控制器”中，小心翼翼地扣代碼出來改。

5. IoC 重構設計

開源的通用采集服務器，是在原有系統(tǒng)架構的基礎上，增加業(yè)務抽象接口，引用 IoC 的設計理念，倒置交互類之間的依賴關系，采用 DI 來實現(xiàn)類之間的依賴關聯(lián)的動態(tài)關聯(lián)。

1、 抽象“業(yè)務調度核心類”的核心邏輯流程，將所有類方法的調用設計成對接口方法的調用。

2、 抽象“采集控制類”的核心邏輯流程，將所有類方法的調用設計成對接口方法的調用。“采集控制器”類被設計成一個通用的“工控機主板”，只要遵循“主板”約定的接口，換插不同的“業(yè)務采集類”、“通信協(xié)議類”，就可以實現(xiàn)完全不同的采集業(yè)務需求、按照完全不同的通信協(xié)議與底層模塊通信。

3、 將“采集控制類”中的狀態(tài)機管理邏輯剝離出來，將狀態(tài)機檢測和控制代碼設計成對接口方法的調用。只要遵循狀態(tài)機接口，就可以靈活實現(xiàn)不要業(yè)務需求的狀態(tài)轉換控制，在運行期動態(tài)創(chuàng)建狀態(tài)機實例，并注入到“采集控制類”，完全接觸“采集控制器”與“業(yè)務狀態(tài)機類”靜態(tài)依賴。

4、 去掉“通信適配器”、“協(xié)議適配器”，增加“通信接口”、“協(xié)議接口”和“業(yè)務接口”，按照接口要求重構通信類、協(xié)議類、采集業(yè)務類，解決原來系統(tǒng)架構中：新增一種通信方式、通信協(xié)議時，還必須在相關的適配器中增加新類型識別代碼的設計弊端。

6. 技術基礎與規(guī)約

本設計的核心的設計原理： IOC 容器根據(jù)反射機制動態(tài)創(chuàng)建實現(xiàn)約定接口的業(yè)務對象，動態(tài)注入到采集調度控制器中。采集調度控制器是一個高層次抽象的 Active Class ，自動不斷地調用狀態(tài)機接口方法來執(zhí)行“業(yè)務采集類”要求的業(yè)務通信指令。

本設計的核心的重要設計約定：采集調度控制器只調用抽象的接口方法，那么具體的上層業(yè)務任務，如何動態(tài)的翻譯成具體的通信協(xié)議？又如何知道當前的任務如何開始，何時結束？本設計要求：業(yè)務采集類必須管理好自己的業(yè)務步驟與通信協(xié)議之間的對應關系（確實非常難以在抽象，用動態(tài)配置的方法使用起來反而更復雜），采集調度控制器只負責動態(tài)建立兩者之間的運行期對象關系。業(yè)務采集類必須實現(xiàn)采集調度控制器要求的指定接口方法，用以實現(xiàn)采集任務的發(fā)起、執(zhí)行下一條指令、結束、異常重發(fā)、異常中止、故障處理等采集流程控制功能。這正好是采集調度控制器高層抽象的價值和通用性的設計基礎。

框架使用者只需按照接口約定，編碼實現(xiàn)具體業(yè)務需求的相關采集、狀態(tài)機、協(xié)議業(yè)務類；在配置這些類的運行期參數(shù)，采集服務器就大功告成。采集服務器在允許時，會自動加載配置參數(shù)，動態(tài)創(chuàng)建相關的業(yè)務邏輯對象，并完成依賴注入，整個系統(tǒng)就能按具體的業(yè)務要求完成通信、采集任務。

7. 采集服務器設計

通信采集服務器是常常是實時監(jiān)控、數(shù)據(jù)采集類系統(tǒng)的核心，實現(xiàn)與底層的軟件子系統(tǒng)、硬件終端、遠程設備的通信、下行命令的執(zhí)行、上行數(shù)據(jù)的接收、協(xié)議解析，并且完成業(yè)務數(shù)據(jù)的分析以及顯示驅動。它既是系統(tǒng)的通信樞紐，也是業(yè)務核心。

下圖是基于 IoC 理念重新設計的通用的開源采集服務器子系統(tǒng)體系結構：

<shape id="_x0000_i1026" style="WIDTH: 414.75pt; HEIGHT: 345.75pt" type="#_x0000_t75"><imagedata o:title="IoC框架圖" src="file:///C:%5CTemp%5Cmsohtml1%5C01%5Cclip_image003.png"></imagedata></shape>

8. 核心組件設計簡介

1. 業(yè)務數(shù)據(jù)接口

以統(tǒng)一的方式，輸出本框架按配置的“通信模塊”、“通信協(xié)議”、“采集業(yè)務類”所采集到的數(shù)據(jù)。框架使用者實現(xiàn)此接口的方法可以繼續(xù)分析、處理、存儲、展現(xiàn)業(yè)務數(shù)據(jù)。

2. 外部系統(tǒng)接口

本系統(tǒng)對外部系統(tǒng)的接口，目前沒有定義具體方法，屬于框架設計預留接口。框架使用者可以實現(xiàn)此接口，定制通信協(xié)議、通信方式實現(xiàn)與外部系統(tǒng)信息交互。外圍系統(tǒng)通過此接口向“業(yè)務調度核心類”發(fā)起通信命令、操控底層設備、實時提取設備狀態(tài)等業(yè)務請求。

3. 業(yè)務調度核心類

是采集子系統(tǒng)的業(yè)務調度核心類和業(yè)務請求中轉站。外部系統(tǒng)的命令請求通過“外部系統(tǒng)接口”轉入到“業(yè)務調度核心類”，“業(yè)務調度核心類”將命令請求存入命令隊列中共“”執(zhí)行；“”采集到數(shù)據(jù)之后，調用“數(shù)據(jù)接口”的方法將數(shù)據(jù)返回到“業(yè)務調度核心類”，之后，“業(yè)務調度核心類”調用“業(yè)務數(shù)據(jù)接口”或者“外部系統(tǒng)接口”將業(yè)務數(shù)據(jù)反饋到更上層模塊。

4. 任務隊列管理類

下行任務信息緩存類。“業(yè)務調度核心類”向其中增加命令請求；“采集調度控制器”自動檢測是否有新命令請求，當檢測到后立即“中斷”通信握手，執(zhí)行請求，執(zhí)行成功之后，從隊列中刪除該命令。

5. 采集調度控制類

管理、協(xié)調其下的“采集業(yè)務類”、“通信實現(xiàn)類”、“業(yè)務狀態(tài)機類”、“通信協(xié)議類”等模塊，完成所有的通信控制及數(shù)據(jù)采集功能。通過調用任務接口獲取采集指令；之后，調用業(yè)務接口（業(yè)務接口由“采集業(yè)務類”實現(xiàn)，在具體使用中由框架使用者根據(jù)自己的業(yè)務采集需求開發(fā)），獲取具體的通信指令；根據(jù)通信指令調用正確的協(xié)議接口（協(xié)議接口由“通信協(xié)議類”實現(xiàn)，在具體使用中由框架使用者根據(jù)自己的通信協(xié)議需求開發(fā)）獲得通信幀；最后，啟動狀態(tài)機開始本次采集任務的執(zhí)行。采集調度控制器

6. 采集業(yè)務類

封裝當前系統(tǒng)的具體采集業(yè)務對象，為通用的“采集調度控制類”定制具體的采集任務。本質就是：把上層的“抽象任務”細化成具體的“通信幀”和“通信控制步驟”、是一個簡單的“工作流定制器”。

7. 業(yè)務狀態(tài)機類

實現(xiàn)狀態(tài)機接口，根據(jù)采集業(yè)務狀態(tài)的控制、轉換需求，框架使用者定制開發(fā)。主要用于通信鏈路的通斷控制、數(shù)據(jù)收發(fā)、忙閑標識及轉換等業(yè)務狀態(tài)機邏輯。

8. 采集方式類

封裝具體的串口、 TCP/IP 、語音卡等通信采集類，實現(xiàn)具體的通信方式控制及通用的數(shù)據(jù)收發(fā)接口。

9. 通信協(xié)議類

封裝系統(tǒng)中軟件與底層軟件子系統(tǒng)、硬件設備、遠程終端的通信協(xié)議。

9. 設計模式與原理

1) 整個系統(tǒng)采用 MVC 的設計模式 ：業(yè)務數(shù)據(jù)、顯示控制及界面顯示嚴格分層，單獨實現(xiàn)。業(yè)務數(shù)據(jù)通過下層模塊產(chǎn)生，通用“業(yè)務調度核心”這個中介與“界面接口定制類”這個控制器交互；控制器“界面接口定制類”可以根據(jù)不同的顯示需要進行定制，與不同的界面組件交互，可滿足不同的顯示需求；在界面顯示層，引用了其它項目中實現(xiàn)的“標準界面通用組件庫”中的部分源碼。

2) “業(yè)務調度核心類”采用 Mediator 模式。

3) “采集調度控制器”采用“微內核”的實時設計模式。

4) 命令隊列采用 Command 模式： 以強制分離命令的發(fā)起者與命令的執(zhí)行者。

5) “業(yè)務狀態(tài)機”采用 State 模式： 通過抽象業(yè)務狀態(tài)機，可以靈活地實現(xiàn)不同采集控制需求。并且，如果采集方式類是語音卡之類的設備時，采集類里面也往往采集“狀態(tài)機”模式來管理這類自身以狀態(tài)方式驅動的通信設備。

6) “業(yè)務采集類”，對多協(xié)議的自動處理采用 Chain Of Responsibility ： 將多個協(xié)議組件組織成一條“職責鏈”，實現(xiàn)對當前通信協(xié)議的自動識別、自動解析功能。

7) “采集調度控制器”，考慮并發(fā)和性能，采用“通道”的實時設計模式： 以盡可能地提升系統(tǒng)并發(fā)能力、提高系統(tǒng)吞吐能力。

8) “采集調度控制器”，采用“輪巡”和“中斷”的實時設計模式： 為檢測通信鏈路是否可用，在通信空閑時，系統(tǒng)要求與硬件終端進行定期“通信握手”，當“采集調度控制器”檢測到“命令隊列”或者“硬件終端”的任務請求時采用“中斷”方式立即響應上、下行命令。

10. 應有實例

采用此框架的體系架構，框架使用者只需按“任務接口”實現(xiàn)自己特定的“任務隊列管理類”，按“業(yè)務接口”實現(xiàn)自己特定的“采集業(yè)務類”，按“狀態(tài)機接口”實現(xiàn)自己特定的通信業(yè)務控制“業(yè)務狀態(tài)機類”，再按“協(xié)議接口”實現(xiàn)自己特定的“通信協(xié)議類”，就能夠非常快速地開發(fā)一個功能完備、運行穩(wěn)定的通信采集服務器。目前，應有此框架已成功構建“指紋采集系統(tǒng)”、“糧情測控系統(tǒng)”的通信采集服務器。

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