尹天明

(中國(guó)中煤能源集團(tuán)公司，北京 100120)

隨著信息化的快速發(fā)展和煤炭企業(yè)集團(tuán)運(yùn)營(yíng)管理方式的轉(zhuǎn)型升級(jí)，信息技術(shù)在支撐企業(yè)開(kāi)展日常經(jīng)營(yíng)管理起到了越來(lái)越重要的作用，同時(shí)也面臨新的挑戰(zhàn)和機(jī)遇，一是煤炭企業(yè)發(fā)展的規(guī)?；推髽I(yè)業(yè)態(tài)的多樣化，使得信息系統(tǒng)開(kāi)發(fā)規(guī)模和難度越來(lái)越大，業(yè)務(wù)需求越來(lái)越雜，系統(tǒng)運(yùn)行的風(fēng)險(xiǎn)系數(shù)也越來(lái)越高，管理和運(yùn)維信息系統(tǒng)的成本也越來(lái)越高，二是信息化技術(shù)發(fā)展快，系統(tǒng)間適配要求高，數(shù)據(jù)交互頻繁，隨系統(tǒng)需求變化而進(jìn)行的動(dòng)態(tài)開(kāi)發(fā)和運(yùn)維難度增大。因此，有必要對(duì)現(xiàn)有的應(yīng)用系統(tǒng)開(kāi)發(fā)架構(gòu)和流程[1]進(jìn)行改造和升級(jí)[2]，以適應(yīng)煤炭企業(yè)實(shí)際業(yè)務(wù)需要和開(kāi)發(fā)需要。基于先進(jìn)成熟的信息技術(shù)，運(yùn)用模塊化開(kāi)發(fā)理念，重新設(shè)計(jì)和調(diào)整應(yīng)用系統(tǒng)基礎(chǔ)開(kāi)發(fā)平臺(tái)，對(duì)應(yīng)用功能和架構(gòu)進(jìn)行重組整合，建立新的、實(shí)現(xiàn)敏捷開(kāi)發(fā)的企業(yè)級(jí)模塊化開(kāi)發(fā)平臺(tái)，實(shí)現(xiàn)快速精益實(shí)施和部署，降低開(kāi)發(fā)成本和實(shí)現(xiàn)復(fù)雜度，以更小的代價(jià)，快速響應(yīng)企業(yè)業(yè)務(wù)需求變化的需求。

J2EE是一套技術(shù)規(guī)范，它包含的組件、服務(wù)、工具都遵循共同的標(biāo)準(zhǔn)。而本文采用基于J2EE架構(gòu)進(jìn)行模塊化平臺(tái)設(shè)計(jì)，可以借助部分成熟套件，提高對(duì)異構(gòu)平臺(tái)的支撐，增強(qiáng)系統(tǒng)可伸縮性，同時(shí)利用遵循J2EE架構(gòu)所提供的通用的、封裝的服務(wù)器端功能，可以讓模塊化平臺(tái)設(shè)計(jì)和開(kāi)發(fā)人員更多的關(guān)注創(chuàng)建業(yè)務(wù)邏輯，縮短開(kāi)發(fā)時(shí)間。

1 平臺(tái)架構(gòu)

構(gòu)建一套基于J2EE架構(gòu)規(guī)范的模塊化部署和實(shí)施的業(yè)務(wù)開(kāi)發(fā)平臺(tái)[3-5]，實(shí)現(xiàn)煤炭生產(chǎn)業(yè)務(wù)需求的快速落地和迭代，解決企業(yè)信息化建設(shè)過(guò)程中存在的諸如開(kāi)發(fā)慢、維護(hù)難、標(biāo)準(zhǔn)不統(tǒng)一等一系列問(wèn)題?；谏鲜?，筆者提出的模塊化業(yè)務(wù)平臺(tái)總體架構(gòu)如圖1所示。

圖1 總體架構(gòu)圖

模塊化業(yè)務(wù)平臺(tái)總體架構(gòu)由三部分組成：基于Eclipse的插件開(kāi)發(fā)、框架工具、基礎(chǔ)模塊實(shí)現(xiàn)共計(jì)三個(gè)部分，各部分主要功能包括：

1.1 基于Eclipse的插件開(kāi)發(fā)

在Eclipse基礎(chǔ)上主要進(jìn)行功能插件的二次開(kāi)發(fā)，開(kāi)發(fā)的內(nèi)容主要包括可視化建模工具、代碼生成器、發(fā)布器、部署器、數(shù)據(jù)遷移器等，封裝成各類(lèi)”微服務(wù)”。整個(gè)Eclipse插件開(kāi)發(fā)不僅僅依賴(lài)于具體項(xiàng)目，而是貫穿了整個(gè)軟件研發(fā)生命周期。該平臺(tái)主要內(nèi)容包括：

1)可視化設(shè)計(jì)器：開(kāi)發(fā)人員利用可視化設(shè)計(jì)器來(lái)將通用和專(zhuān)有業(yè)務(wù)封裝成實(shí)體，實(shí)體負(fù)責(zé)與數(shù)據(jù)庫(kù)表的對(duì)應(yīng)和從頁(yè)面到數(shù)據(jù)庫(kù)表的邏輯實(shí)現(xiàn)，同時(shí)也包括操作的功能單元、權(quán)限等功能封裝。

2)代碼生成：開(kāi)發(fā)人員生成代碼時(shí)，各代碼目錄同步生成，目錄中的包和子包按照代碼規(guī)范也會(huì)同步生成。代碼生成時(shí)候，為避免因需求變動(dòng)反復(fù)修改實(shí)體，設(shè)計(jì)中將抽象類(lèi)和具體類(lèi)進(jìn)行了分離。

1.2 框架工具

此部分內(nèi)容融合了市場(chǎng)上主流的、基于Java EE技術(shù)的開(kāi)源框架內(nèi)容，包括數(shù)據(jù)遷移器、輔助開(kāi)發(fā)工具等主流開(kāi)發(fā)技術(shù)工具，使任何一個(gè)開(kāi)發(fā)團(tuán)隊(duì)可利用成熟的技術(shù)體系和工具實(shí)現(xiàn)代碼的快速開(kāi)發(fā)和應(yīng)用，同時(shí)，在這一部分引入開(kāi)發(fā)規(guī)范、代碼規(guī)則、版本管理等內(nèi)容，通過(guò)平臺(tái)保障團(tuán)隊(duì)所交付產(chǎn)品的代碼質(zhì)量。此外，還提供了多參數(shù)數(shù)據(jù)源、頁(yè)面校驗(yàn)、單元測(cè)試、通用API、緩存等多種輔助開(kāi)發(fā)手段，省去研發(fā)工程師大量的開(kāi)發(fā)時(shí)間，避免重復(fù)設(shè)計(jì)和開(kāi)發(fā)。

1.3 基礎(chǔ)模塊

此部分內(nèi)容實(shí)現(xiàn)了通用基礎(chǔ)模塊內(nèi)容，包括用戶(hù)管理、組織機(jī)構(gòu)管理、權(quán)限管理、菜單管理、日志管理等內(nèi)容，滿(mǎn)足通用情況下項(xiàng)目建設(shè)的基本需求；平臺(tái)設(shè)計(jì)了具備鏈?zhǔn)绞跈?quán)功能的PrivilegeProcessor接口和方法，開(kāi)發(fā)者可結(jié)合煤礦企業(yè)特點(diǎn)、甚至于其他行業(yè)特點(diǎn)來(lái)自定義用戶(hù)權(quán)限范圍。

整個(gè)業(yè)務(wù)平臺(tái)采用面向?qū)ο蟮脑O(shè)計(jì)方法和MVC模式，通過(guò)可視化建模工具對(duì)各個(gè)模塊進(jìn)行業(yè)務(wù)建模，每個(gè)模塊都將是一個(gè)獨(dú)立可運(yùn)行的B/S架構(gòu)應(yīng)用程序(Web工程)，可以獨(dú)立部署到Java Web容器中，技術(shù)架構(gòu)如圖2所示。

圖2 技術(shù)架構(gòu)

模塊化業(yè)務(wù)平臺(tái)采用的技術(shù)框架是遵循J2EE架構(gòu)的，組合方案為：Spring+Papilio UI+MyBatis3。其中，MyBatis3：在本平臺(tái)上主要實(shí)現(xiàn)數(shù)據(jù)的持久化。它支持定制化的 SQL語(yǔ)句、支持存儲(chǔ)過(guò)程等對(duì)數(shù)據(jù)庫(kù)的基本操作，從而避免了大多數(shù)的JDBC 代碼開(kāi)發(fā)和手動(dòng)設(shè)置數(shù)據(jù)庫(kù)參數(shù)過(guò)程。該平臺(tái)數(shù)據(jù)持久層主要包括三個(gè)方面內(nèi)容：一是數(shù)據(jù)庫(kù)腳本文件，針對(duì)不同的數(shù)據(jù)庫(kù)配置不同的腳本文件，二是數(shù)據(jù)庫(kù)類(lèi)文件，三是ORM配置文件，實(shí)現(xiàn)不同類(lèi)型系統(tǒng)之間的數(shù)據(jù)轉(zhuǎn)換。

從總的路線上看，平臺(tái)充分發(fā)揮了Spring IOC與AOP功能，實(shí)現(xiàn)業(yè)務(wù)層兩端的無(wú)縫集成，同時(shí)針對(duì)煤礦具體業(yè)務(wù)提供一套結(jié)合煤礦實(shí)際、調(diào)用友好的抽象層，抽象出班組管理、巷道、開(kāi)拓等煤礦具體業(yè)務(wù)并進(jìn)行封裝，除封裝和集成外，還提供了一套客戶(hù)可配置的通用性強(qiáng)的API，供上層開(kāi)發(fā)者調(diào)用，使平臺(tái)具備針對(duì)其他行業(yè)實(shí)現(xiàn)業(yè)務(wù)的封裝和集成的功能。

綜上所述，平臺(tái)技術(shù)架構(gòu)從縱向和橫向看，業(yè)務(wù)模塊之間都是松耦合關(guān)系，各模塊和層級(jí)之間通過(guò)對(duì)應(yīng)的訪問(wèn)方式建立異步通信機(jī)制，單個(gè)模塊的調(diào)整和修改不會(huì)影響其他模塊的正常使用和通信，這種松耦合關(guān)系也是保證模塊化可拔插特性的關(guān)鍵。

業(yè)務(wù)模塊與基礎(chǔ)模塊之間采用直接的接口依賴(lài)關(guān)系(在Java架構(gòu)中，這種依賴(lài)關(guān)系主要表現(xiàn)為Jar包依賴(lài)以及接口調(diào)用)，即：基礎(chǔ)通用模塊提供業(yè)務(wù)通用模塊所需的接口方法API并供其調(diào)用，而且，業(yè)務(wù)模塊不能直接調(diào)用基礎(chǔ)模塊的service方法，只能通過(guò)基礎(chǔ)模塊提供的接口類(lèi)來(lái)訪問(wèn)其中的數(shù)據(jù)，這樣就保證了基礎(chǔ)模塊的相對(duì)獨(dú)立性。

2 關(guān)鍵技術(shù)

2.1 模塊化

在大中型信息化項(xiàng)目中，由于涉及到多組織、多業(yè)務(wù)、多平臺(tái)等一系列涉及團(tuán)隊(duì)協(xié)作的問(wèn)題以及需求復(fù)雜度和適應(yīng)性的要求，需要在前期就要對(duì)系統(tǒng)模塊進(jìn)行詳細(xì)梳理和劃分，對(duì)應(yīng)用系統(tǒng)和業(yè)務(wù)需求進(jìn)行模塊化設(shè)計(jì)。軟件模塊化的主要目的是為了建立能復(fù)用且具備事務(wù)特性的軟件組件和服務(wù)，可以在幾乎不需要修改的情況下，通過(guò)模塊的配置、部署和調(diào)用再次用來(lái)組建新的應(yīng)用系統(tǒng)，提高軟件的開(kāi)發(fā)周期和可靠性，降低開(kāi)發(fā)成本和運(yùn)維成本。模塊化是本平臺(tái)設(shè)計(jì)核心，其特性主要包括模塊的可插拔、模塊之間的異步通信、模塊顆粒度劃分、模塊間引用關(guān)系等[7-9]。

2.1.1 可插拔模塊

模塊的可插拔主要解決兩個(gè)問(wèn)題：

1)模塊的發(fā)布。在開(kāi)發(fā)平臺(tái)中發(fā)布應(yīng)用要包含兩個(gè)部分信息：應(yīng)用基礎(chǔ)信息和配置應(yīng)用信息，應(yīng)用基礎(chǔ)信息主要包括項(xiàng)目版本、名稱(chēng)及簡(jiǎn)介等，配置應(yīng)用要告知平臺(tái)模塊的部署方式，主要包括數(shù)據(jù)庫(kù)腳本、工程配置XML文件，編譯好的JAR包，工程包等內(nèi)容，以上內(nèi)容準(zhǔn)備好后，即可通過(guò)平臺(tái)生成項(xiàng)目發(fā)布文件。

2)模塊部署。將項(xiàng)目發(fā)布文件導(dǎo)入平臺(tái)部署，系統(tǒng)首先會(huì)對(duì)發(fā)布文件進(jìn)行驗(yàn)證，驗(yàn)證通過(guò)則可部署到項(xiàng)目文件，否則報(bào)錯(cuò)直至修改通過(guò)。

2.1.2 模塊之間的異步通信

模塊與模塊之間要有建立良好的異步通信功能。例如，設(shè)備業(yè)務(wù)系統(tǒng)應(yīng)該在“設(shè)備管理”模塊中，但“生產(chǎn)管理”應(yīng)該可以調(diào)用“設(shè)備管理”中的設(shè)備信息，從而控制設(shè)備的啟停與運(yùn)轉(zhuǎn)情況。如果一個(gè)項(xiàng)目只要求有“生產(chǎn)管理”不要‘設(shè)備管理’，“生產(chǎn)管理”中就不能體現(xiàn)出所“設(shè)備”相關(guān)的所有信息，基本實(shí)現(xiàn)原理如圖3所示。

圖3 模塊間異步通信

在本業(yè)務(wù)平臺(tái)上實(shí)現(xiàn)了從如下幾個(gè)方面進(jìn)行控制：

1)在頁(yè)面管理上，生產(chǎn)管理中不顯示與設(shè)備相關(guān)的鏈接、按鈕或菜單。

2)在代碼設(shè)計(jì)上，當(dāng)點(diǎn)擊生產(chǎn)管理中的某個(gè)按鈕或鏈接時(shí)，如果這事件需調(diào)用相關(guān)設(shè)備信息，那么要確保發(fā)出調(diào)用申請(qǐng)并保證程序正常向后執(zhí)行。

3)在數(shù)據(jù)庫(kù)表結(jié)構(gòu)上，理論上一個(gè)業(yè)務(wù)系統(tǒng)沒(méi)有指定的模塊，那么就不應(yīng)該提供這個(gè)模塊下的頁(yè)面、代碼、數(shù)據(jù)庫(kù)表，而一些表是一定是有跨模塊之間的外引用(即數(shù)據(jù)庫(kù)外鍵，一個(gè)表中的字段是另一個(gè)表的主鍵)的。因此要盡力降低數(shù)據(jù)庫(kù)表外引用的同時(shí)，確保有這種外引用也能正常運(yùn)行。

4)在用戶(hù)權(quán)限上，基礎(chǔ)通用模塊內(nèi)借鑒微服務(wù)的思想，細(xì)化權(quán)限粒度，保證模塊內(nèi)權(quán)限的分配，更要保證模塊間權(quán)限的管理和分配。

2.1.3 模塊顆粒度適度

所謂模塊顆粒度就是一個(gè)模塊所提供的功能點(diǎn)的多寡[5]。例如，是否“生產(chǎn)管理”作為一個(gè)模塊還是把生產(chǎn)管理下的“生產(chǎn)成本”作為一個(gè)模塊。模塊的粒度越小，系統(tǒng)就越靈活而開(kāi)發(fā)工作量，技術(shù)難度與部署難度就越大，反之系統(tǒng)就越僵硬(不利于擴(kuò)展與維護(hù))而開(kāi)發(fā)工作量，技術(shù)難度與部署難度就越小。本平臺(tái)在模塊顆粒度劃分的基本原則為：

1)基于業(yè)務(wù)的層層梳理和功能分解，模塊的顆粒度是由業(yè)務(wù)本身行為所決定的，是原子型的不可分割的業(yè)務(wù)行為。

2)綜合平衡業(yè)務(wù)、軟硬件資源、異構(gòu)系統(tǒng)交互等條件，確定最后模塊顆粒度。

由于模塊顆粒度問(wèn)題的復(fù)雜性，考慮設(shè)計(jì)可量化的模塊顆粒度優(yōu)化模型，期望能在模塊顆粒度設(shè)計(jì)層面實(shí)現(xiàn)資源分配的總體平衡。

2.2 代碼覆蓋

經(jīng)初步測(cè)算，利用本平臺(tái)開(kāi)發(fā)項(xiàng)目中近80%的代碼是自動(dòng)生成的，為保持邏輯一致性，代碼生成器會(huì)反復(fù)生成并覆蓋部分類(lèi)和文件，造成開(kāi)發(fā)者手動(dòng)改寫(xiě)或添加的代碼被覆蓋掉，經(jīng)分析，生成器生成的文件從類(lèi)型上看主要有兩大類(lèi)：①與實(shí)體屬性密切相關(guān)的類(lèi)或者配置文件，因?yàn)橹灰獙?shí)體中的屬性名稱(chēng)或量發(fā)生變化，生成器就要適應(yīng)實(shí)體屬性的變化；②與整個(gè)服務(wù)相關(guān)的配置文件，因?yàn)橐粋€(gè)服務(wù)下會(huì)有多個(gè)實(shí)體，生成器的目的是要適應(yīng)服務(wù)下實(shí)體數(shù)據(jù)庫(kù)的增減。

總體而言，涉及工程整體性配置的內(nèi)容原則上不能修改，如ORM框架配置，分頁(yè)信息配置，安全信息配置，緩存容器配置，部署配置等，這些要求會(huì)在代碼規(guī)范中說(shuō)明.涉及代碼修改的，為避免代碼覆蓋，筆者提出的解決方案包括：

1)修改模型。如果要對(duì)模型類(lèi)實(shí)現(xiàn)某個(gè)接口或方法，可改寫(xiě)模型包下的具體類(lèi)，該類(lèi)只會(huì)生成一次，不能修改模型包下抽象中的內(nèi)容，因?yàn)槌橄箢?lèi)會(huì)被重新生成。

2)按照調(diào)整內(nèi)容，可分別修改表現(xiàn)層、業(yè)務(wù)層、權(quán)限配置文件?；具^(guò)程是在新建一個(gè)配置文件，在配置文件中修改或增加action，然后再對(duì)應(yīng)的XML文件中引入該配置文件，使得該action會(huì)被優(yōu)先調(diào)用。以修改表現(xiàn)層xwork-test.xml配置文件為例，操作應(yīng)該是：①新建一個(gè)xwork-test-customer.xml配置文件；②將要修改或要增加的actoin寫(xiě)在該文件中(即使action名與xwork-test.xml只的action名重復(fù)也沒(méi)有關(guān)系，系統(tǒng)會(huì)以action為最高優(yōu)先級(jí))；③在xwork.xml文件中引入該配置文件注意一定要放在xwork-customer.xml引用的下面。

2.3 模塊初始化部署

由于運(yùn)行每個(gè)業(yè)務(wù)模塊的容器(如Tomcat)的運(yùn)行要占用相應(yīng)的硬件資源(內(nèi)存、硬盤(pán)空間，CPU時(shí)間等等)，所以一臺(tái)物理 Server 能運(yùn)行的 Tomcat 是有限的。如果模塊過(guò)多，則建議相應(yīng)增加 Server來(lái)緩解應(yīng)用程序運(yùn)行壓力。以部署A模塊為例，并且假設(shè)A模塊在 Eclipse項(xiàng)目的web路徑為：C：/workspace/cmim-A /web，整個(gè)部署過(guò)程[6]關(guān)鍵環(huán)節(jié)有：

2.3.1 配置容器目錄

部署方式如下：

1)配置XML文件。在${CATALINA_HOME}/conf/server.xml 中進(jìn)行配置[10]，在該XML文件的標(biāo)簽部分加入如下代碼：

2)修改XML參數(shù)。修改 ${CATALINA_HOME}/conf/web.xml中的對(duì)應(yīng)代碼段，如果listings 參數(shù)的值為 false，則改為 true，目的是要啟用虛擬路徑。

2.3.2 容器群集配置

1)配置XML文件。在 ${CATALINA_HOME}/conf/server.xml 中找到如下代碼：

，添加集群代碼信息。

2)修改XML文件。修改 ${CATALINA_HOME}/conf/server.xml 中除了上述 ① 中的 port，以保證每個(gè) Tomcat 的端口號(hào)不重復(fù)。

3)修改批處理文件。修改 ${CATALINA_HOME}/bin/ 下的 startup.bat 和 catalina.bat，在內(nèi)容的最開(kāi)始加入如下代碼：

CATALINA_HOME=C：/tomcat-cluster/tomcat-A

JAVA_HOME=C：/opt/jdk

JAVA_OPTS=“-Xms256M -Xmx512M -XX：PermSize=256m -XX：MaxPermSize=512m”

每個(gè)模塊的Tomcat 也應(yīng)放在 tomcat-cluster 目錄中。

4)在每個(gè)模塊的部署描述符文件(web.xml)中添加： 標(biāo)記。

3 結(jié) 語(yǔ)

項(xiàng)目組利用該平臺(tái)對(duì)中煤集團(tuán)某特大型煤礦企業(yè)的生產(chǎn)管理系統(tǒng)進(jìn)行了應(yīng)用、開(kāi)發(fā)和部署，共實(shí)施和部署了包括調(diào)度管理、設(shè)備管理、一通三防、班組管理等在內(nèi)的十余個(gè)模塊，并對(duì)項(xiàng)目實(shí)施情況進(jìn)行了2年的跟蹤和效果分析：

1)從經(jīng)濟(jì)效益層面看，一是極大的加強(qiáng)了煤炭企業(yè)對(duì)生產(chǎn)的閉環(huán)管控，降低噸煤成本；輔助實(shí)現(xiàn)科學(xué)采掘接替，提高對(duì)生產(chǎn)設(shè)備點(diǎn)檢水平，月平均故障時(shí)間減少5h，按平均生產(chǎn)能力約1萬(wàn)t/d，每噸煤300元計(jì)算，每年能夠增加營(yíng)收750萬(wàn)元，二是實(shí)現(xiàn)生產(chǎn)各類(lèi)數(shù)據(jù)的多維度統(tǒng)計(jì)、分析和匯總，同時(shí)大幅減少用人崗位和人員工作強(qiáng)度，企業(yè)員工崗位比三定減少28人，每年直接人力成本節(jié)約300萬(wàn)元，三是系統(tǒng)配置靈活、擴(kuò)展性強(qiáng)，上線后，通過(guò)模塊化的業(yè)務(wù)配置模式，后期的業(yè)務(wù)增加和功能變更僅需單獨(dú)維護(hù)單個(gè)模塊即可實(shí)現(xiàn)，保證了系統(tǒng)其它模塊的穩(wěn)定運(yùn)行，系統(tǒng)運(yùn)維成本平均降低20%，企業(yè)每年可節(jié)省運(yùn)維費(fèi)用近100萬(wàn)元。

2)從社會(huì)效益層面看，該平臺(tái)除了應(yīng)用于煤礦企業(yè)，還可以在電信、金融、醫(yī)療等各領(lǐng)域推廣使用，應(yīng)用前景廣闊。業(yè)務(wù)基礎(chǔ)平臺(tái)采用模塊化結(jié)構(gòu)，對(duì)業(yè)務(wù)流程進(jìn)行重組，實(shí)現(xiàn)資源的集成和整合，可大幅提高工作效率，以適應(yīng)不斷變化的需求，對(duì)企業(yè)信息化水平提高具有良好的推進(jìn)作用。

后期，筆者將在復(fù)雜業(yè)務(wù)邏輯代碼生成、模塊顆粒度模型優(yōu)化、軟硬件資源性能比等方面開(kāi)展進(jìn)一步的研究。