一個開源的 IoC 采集服務(wù)器體系結(jié)構(gòu)設(shè)計

基于 IoC 思想設(shè)計的系統(tǒng)架構(gòu)

作者：成曉旭

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

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

1. 引言

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

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

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

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

本設(shè)計是針對常見的實時監(jiān)控、數(shù)據(jù)采集系統(tǒng)。下面以一個典型的通信采集服務(wù)器應(yīng)有為例：系統(tǒng)的底層是硬件采集設(shè)備，硬件設(shè)備完成整個系統(tǒng)與外界環(huán)境或者設(shè)備的交互；上層的軟件系統(tǒng)完成與自己硬件設(shè)備的交互，并且對采集的數(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. 問題

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

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

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

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

4. 對于需求變化的適應(yīng)性非常差；

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

4. 新問題

針對上述問題，總結(jié)、分析以往經(jīng)驗和教訓(xùn)，以“代碼復(fù)用”為出發(fā)點重新設(shè)計了通信采集系統(tǒng)體系架構(gòu)，并較好地解決這些突出問題，并梳理出大量可復(fù)用的功能代碼。詳細說明請參考《一個典型的采集服務(wù)器體系結(jié)構(gòu)設(shè)計》一文： 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ā)通信采集服務(wù)器，以應(yīng)有于不同的業(yè)務(wù)需求時，發(fā)現(xiàn)原來的架構(gòu)存在如下的典型問題：

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

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

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

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

5. IoC 重構(gòu)設(shè)計

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

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

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

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

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

6. 技術(shù)基礎(chǔ)與規(guī)約

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

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

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

7. 采集服務(wù)器設(shè)計

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

下圖是基于 IoC 理念重新設(shè)計的通用的開源采集服務(wù)器子系統(tǒng)體系結(jié)構(gòu)：

<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. 核心組件設(shè)計簡介

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

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

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

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

3. 業(yè)務(wù)調(diào)度核心類

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

4. 任務(wù)隊列管理類

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

5. 采集調(diào)度控制類

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

6. 采集業(yè)務(wù)類

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

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

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

8. 采集方式類

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

9. 通信協(xié)議類

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

9. 設(shè)計模式與原理

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

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

3) “采集調(diào)度控制器”采用“微內(nèi)核”的實時設(shè)計模式。

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

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

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

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

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

10. 應(yīng)有實例

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

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