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

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

作者：成曉旭

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

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

1. 引言

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

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

2. 系統背景簡介

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

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

<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. 問題

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

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

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

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

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

5. 系統代碼幾乎沒有可復用性了。

4. 新問題

針對上述問題，總結、分析以往經驗和教訓，以“代碼復用”為出發點重新設計了通信采集系統體系架構，并較好地解決這些突出問題，并梳理出大量可復用的功能代碼。詳細說明請參考《一個典型的采集服務器體系結構設計》一文： 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 。

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

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

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

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

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

5. IoC 重構設計

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

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

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

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

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

6. 技術基礎與規約

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

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

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

7. 采集服務器設計

通信采集服務器是常常是實時監控、數據采集類系統的核心，實現與底層的軟件子系統、硬件終端、遠程設備的通信、下行命令的執行、上行數據的接收、協議解析，并且完成業務數據的分析以及顯示驅動。它既是系統的通信樞紐，也是業務核心。

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

<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. 業務數據接口

以統一的方式，輸出本框架按配置的“通信模塊”、“通信協議”、“采集業務類”所采集到的數據。框架使用者實現此接口的方法可以繼續分析、處理、存儲、展現業務數據。

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