管理信息系統的整合實現

張偉

（中國石化工程建設有限公司，北京100101）

目前很多公司應用著各種管理信息系統MIS（Management Information System），大到企業級的ERP，小到部門級的出/考勤記錄程序。這些系統是隨著公司的信息化建設逐步建立和應用起來的。MIS在辦公自動化等方面為使用者提供了極大的便利，有些系統甚至成為管理工作中不可或缺的關鍵手段。因此，MIS的穩定與高效已經逐步成為各個崗位工作中至關重要的因素。

這些經過多年開發與積累的應用系統，由于各自獨立，自成一套的零散性制約著性能的發揮，同時增加了管理復雜度。系統過于分散也是安全風險增大的主要原因。將這些分散的應用系統通過集群或是冗余的手段進行集中，一方面可以發揮現有硬件的高性能，另一方面也可以集中管理系統，增加系統的穩定性和安全性。因此，將分散的系統進行整合是大勢所趨，也是提升整個公司或企業應用水平的必然要求。

1 整合的目的與途徑

1.1 整合的目的

MIS的特點是緊隨公司或部門的管理模式與發展而進行開發的，因而這些系統的開發與應用是逐步積累起來的，同時隨著新部門和新業務的增加還會有新的系統逐漸上線。這種經過多年積累開發的系統均比較獨立和分散，且系統的規模都不大，投入之初分配的硬件服務器都是性能較低的型號，隨著系統數量的逐步增加會出現大量的低端服務器塞滿機房的現象，這種現狀的出現會導致如下問題：硬件雖然占用數量多，但都配置落后，利用率低；系統分散，導致管理復雜度高，故障點多；管理賬號分散，安全風險大；沒有冗余設置，一旦系統出現問題，對工作的影響范圍較大。

為了保證每個系統的穩定運行，將上述問題引起的后果盡量降低，IT人員需要對這些系統進行大量的軟硬件日常維護，盡管如此，依然會導致隨工作量在增加但應用效率卻降低的現象出現。

1.2 整合的途徑

系統整合有兩種主要途徑：

1）完全由系統供應商提供一攬子的解決方案，這些解決方案大都比較適合新開發的系統，而且主要針對銀行、電信等關鍵應用部門。該種方案的特點：一次性資金投入量巨大，整合后的系統配置對管理人員的素質和要求都極高，不符合大多數以管理系統為主的企業或公司的需求現狀。

2）各公司獨自利用已知的成熟技術和相關產品，在系統層面進行應用系統的整理和集中，實現初步的系統整合。該種整合方案雖然在技術層面不如系統集成商提供的方案全面，但非常貼近公司的實際，在應用集成和業務集成的角度上更符合公司的目前需求。整合后的綜合性價比要遠高于前者。

文中所描述的是第二種方案下的一種實現方法。

2 整合的范圍

2.1 整合范圍的選擇

系統整合范圍的選擇需要考慮的因素：

1）整合的目的。目的決定范圍的選擇方向。文中系統整合的主要任務是對上面提到的問題進行解決，將零散的系統進行合并，充分利用最新硬件資源，統一進行系統管理，使用新技術提高系統的整體穩定性。具體措施：

a）合并、優化使用系統硬件，提高硬件的使用效率。

b）應用服務器集群加Oracle的Data Guard實現整體提高系統可靠性。

c）平臺整合、集中管理，增強系統的可管理性。

2）需整合系統的特點。系統的特點決定著整合產品的技術方案和產品選擇。為了盡量將風險降低到最小，整合的范圍從滿足如下幾個條件中選擇：

a）需整合的系統采用的是同一或近似架構開發的系統。

b）系統由同一家供貨商或開發商實現。

c）與其他系統的界面關系簡單。

d）進行整合所采用的技術和產品成熟。

e）綜合考慮需整合系統的硬件利用現狀。

結合上述因素，有針對性地從已有的系統中選擇出整合的對象，見表1所列。

表1 需整合系統條件調查

從硬件利用狀態方面考慮范圍時的應用示例（DB數據庫服務器，AS應用服務器）見表2所列。

表2 需整合系統硬件條件調查

對通過綜合考慮選定的系統進行整合可以保證系統的兼容性強，并且彼此之間的影響可以降到最低，整合實現的過程也會相對順利。

2.2 整合的內容

目前大多數的MIS采用的都是B/S結構，也就是服務器端由應用服務器和數據庫服務器組成，用戶只需要通過瀏覽器就能使用系統。該種架構下的MIS要實現整體的整合，需要考慮應用服務器和數據庫服務器兩大部分。其內容涉及如下三個方面：

1）將應用服務器和數據庫服務器從單一物理服務器分離。

2）整合數據庫服務，提高數據庫的安全性和穩定性。

3）整合應用服務，使資源利用高效。

3 整合的技術方案

3.1 數據庫服務器采用的方案

3.1.1 技術方案

需整合系統的數據庫都是采用Oracle，對Oracle進行整合可以有三個選擇：雙機熱備、Data Guard方式以及RAC集群。表3是這三種方案的一個對比。

表3 數據庫整合方案對比

在已有軟、硬件條件下，結合MIS的使用特點，文中涉及系統的重點是可靠性（主要是容災）和易管理程度，因而Data Guard方式是最適合的技術方案。

Data Guard是一款基于Oracle數據庫的熱備容災產品，通過設置多臺后備數據庫服務器實現數據冗余來提供數據保護，并通過日志同步機制保證冗余數據和主數據之間的同步。如果是可預見因素需關閉Primary Database，比如軟硬件升級，可以把Standby Database切換為Primary Database繼續對外服務，這樣減少了服務停止時間，并且數據不會丟失。如果異常原因導致Primary Database不可用，也可以把Standby Database強制切換為Primary Database繼續對外服務，從而實現業務高可用性，主要采用以下技術要點：

1）Data Guard采用物理Standby數據庫形式。

2）主庫日志發送采用LGWR進程的ASYNC方式。

3）備庫啟用Standby Redo Log。

4）備庫日志應用采用實時應用（Real-time Apply）。

5）數據保護模式采用缺省：最高性能（Maximum Performance）。

6）數據庫備份采用RMAN。

主庫每天進行全庫備份（數據、控制文件、SPFILE和歸檔日志），同時刪除歸檔日志。

3.1.2 系統拓撲結構

系統實施整合后的拓撲結構如圖1所示。

3.2 應用服務器采用的方案

3.2.1 技術方案

1）整合軟件和版本的選擇。需整合的三個系統都是J2EE框架，應用服務器平臺產品采用的都是Web Logic，結合現有的硬件情況，應用服務器的整合方案采用Web Logic集群是最佳選擇。

圖1 實施整合后的Oracle數據庫Data Guard拓撲結構示意

Web Logic的集群技術可以讓一組Server指向同一域名一起工作從而提供一個更強大、更可靠的應用平臺。對于客戶端而言，無論集群中有幾個Server在工作，看上去都是一個。Web Logic集群提供的如下兩個主要性能非常適合MIS架構的整合實現。

a）可伸縮性。集群對加入其中的Server在性能上沒有限制（如普通的PC機），為了提高性能，當客戶端的請求大幅增加時，可以動態地向集群中添加Server。并且集群支持當一臺機器的資源沒有被完全利用時，可以在同一機器上啟動多個Server。

b）高可用性。由于在集群中同一應用在多個Server上同時存放或放在一個共享文件系統中，因而相同的請求可以有多個Server提供，并且Server間還可以復制狀態信息。這樣，當其中某一Server宕機或無法響應請求時，其他的Server會立即接管它的任務，用戶的應用不受任何影響，從而把應用和客戶端完全隔離開來。

2）服務器個數的確定主要是依據應用系統的數量和物理服務器內存的數量。此處的服務器是指Web Logic下的邏輯服務器，包括管理服務器、代理服務器以及被管服務器，以下所有出現“服務器”的地方均指這三類。硬件服務器本身將用“物理服務器”。

文中涉及的系統整合后將需要建立如下功能的Web Logic邏輯服務器：1臺管理服務器（Admin Server）；1臺代理服務器（Proxy Server）；4套應用系統對應Web Logic被管服務器。以每臺物理服務器的內存為24 G，共有2臺為例：每臺物理服務器固定需要為操作系統預留2 G以上內存，還需要創建Web Logic集群的管理服務器和用于集群分發的Proxy服務器，具體見表4所列。

表4 集群服務器內存分配

表4中，每臺物理服務器為Web Logic保留可用的內存數量約為20 G。

該方案符合WebLogic的官方要求，同時也滿足了系統配置靈活的要求。具體內容：將每個被管服務器的內存調整到2 G，根據每臺物理服務器可用的內存數量（20 G），每臺物理服務器分別可以建立10個被管，兩臺共計20個被管服務器，考慮到預留，最終確定每臺物理服務器上創建8個Web Logic被管服務器用于系統發布，兩臺共計可創建16個，根據應用的訪問特點分配給5個應用系統。

3）應用系統在服務器上的分配原則，見表5所列。

表5 應用與被管服務器對應關系

a）每個應用分配2個以上被管服務器。

b）每套應用系統中2個物理服務器各有副本。

c）Web Logic被管服務器按照應用分別建立集群，之間不互相影響。

4）被管服務器命名與分配規則應符合下列要求：

a）根據每個被管服務器分配的端口號規則。

b）所有奇數服務器分配到WEB-PRIM-SRV物理服務器上，偶數服務器分配到WEB-STANSRV物理服務器上。

5）代理服務器。整合后的系統是集群方式，用戶需要通過代理（Proxy）方式才能進行訪問。代理服務器是整個網站系統的總入口，它第一時間接受用戶的請求，通過應用的別名轉給集群中的某個被管服務器。Proxy Server對集群的所有請求進行負載均衡，并且當請求失敗時會進行恢復處理。為了系統穩定，避免代理成為故障點，在設置Proxy時也要考慮冗余。

a）主Proxy Server。其是訪問集群應用中的唯一入口，建議通過單獨的物理服務器實現。Proxy可以有硬件和軟件兩種實現。文中是通過安裝代理軟件，采用的是業界非常流行的配置Apache＋WLS的Apache Plugin。后期升級可以考慮通過購置專門代理硬件代替。

b）備用Proxy Server。通過在WEB-STANSRV上再單獨安裝1套Apache＋WLS-Plugin的方式作為主代理的備份，平時不需要啟動。

3.2.2 系統拓撲結構

系統實施整合后的拓撲結構如圖2所示。

圖2 實施整合后的Web Logic集群系統拓撲結構示意

4 系統實現

技術方案確定后，在實現過程中有三個方面需重點關注：硬件的準備；實施的順序；移植系統的調整。

4.1 硬件的準備

硬件準備需要結合待整合的系統進行考慮：一種方法是根據軟件需求有針對性的進行硬件配置；另一種是根據已有硬件性能盡可能多地整合已有零散系統。這兩種方法的目的都是為了更好地利用硬件性能，使系統的效率提高。文中的環境是先確定了需整合的系統數目，然后有針對地進行硬件配置。

4.2 實施的順序

實施順序由簡單到復雜，由風險小到風險大的方式逐步進行。原則上每一步都必須在上一步成功實施后才能開始。建議的整體實施順序如下：

1）數據庫系統整合。Data Guard實質上是對已有數據庫系統進行冗余配置，可以在不動原有系統的情況下實現整合，在實施過程中對上線的業務幾乎沒有影響。在系統實現后，通過調整應用服務器配置的數據庫連接池的參數，就可以直接使用，對用戶是完全透明的。

2）整合應用服務器。主要工作是根據設計方案完成Web Logic集群系統的搭建。Web Logic集群軟件是一套非常成熟和應用廣泛的系統。文中所采用的版本有一個相當容易使用的配置向導，通過配置向導可以快速地完成基本集群的配置。在建立集群過程中需注意以下幾點：

a）集群中的所有物理服務器必須位于同一網段，并且必須是IP廣播（UDP）可到達的。

b）集群中的所有成員必須使用相同的版本，包括Service Pack。

c）集群中的物理服務器必須使用靜態IP地址。

d）集群配置后需要設置較多的代理服務器統一訪問。

3）依次遷移應用系統。遷移應用系統到集群應該最先從框架近似、開發較晚的系統入手。在完成一個的基礎上再進行下一個，這樣可以將問題簡單化，同時逐步積累經驗，避免走彎路。系統在遷移時需要注意以下幾點：

a）在集群上部署的方式。建議通過目錄的形式部署，而不是War包的形式。由于系統初步遷移，需要修改的地方很多，通過目錄方式可以簡化頻繁的修改和重新部署系統的步驟。但要注意的是，這種情況下需要手工保持不同物理主機上的目錄及其內容的一致。

b）部署后的應用訪問方式。單機系統的部署，多數情況下是直接通過根進行訪問，但在集群下，多個系統通過代理服務器分發，必須通過別名。有些程序在編寫時比較嚴謹，代碼中都是通過規范的方式進行引用，因而部署后通過修改配置文件可以順利通過別名進行訪問。但有些系統在代碼中用到的都是絕對路徑，必須檢查源程序進行修正以適應集群環境下的訪問。

c）部署后的掃尾工作。系統遷移后需要保留一段過渡期，目的是為了系統測試和調整時有參照。在此期間，用戶已經開始使用遷移后的系統，老系統主要用于IT和開發人員。系統過渡期內應在原系統的地址和端口上設置通知頁面（或進行自動跳轉），用戶可以逐步過渡到新系統上。

4.3 移植系統的調整

系統在整合前都是單服務器環境，整合后是多服務器的集群機制。這對于部署配置和程序的編寫有一定的特殊要求。在系統部署配置方面，由于采用的Web Logic集群的技術成熟，因而調整相對容易實現，主要是設置好Session的復制即可。但程序編寫中的調整比較耗時，需要注意以下幾個方面：

1）在單機環境中正常的功能在集群后出現了數據漂移，這是由程序編寫過程中出現的不嚴謹造成的，比如兩步提交就會造成數據的二義性。

2）Session復制失敗。Session復制失敗通常是由于網絡組播問題引起的，因而在配置組播的時候盡量避免與其他集群沖突。

3）在程序的編寫中確保Session中的數據必須是可序列化的，否則復制可能會失敗。比如不使用Http會話的Put Value和Remove Value方法，由于它們不受集群支持，并且在應用程序中使用這些方法時，可能會出現會話數據復制問題，因而一致性的全部使用Http Session的Set Attribute和Remove Attribute方法。

4）靜態變量的使用以及緩存同步，EJB，Servlet，JSP同步等，在單機環境下不會發生變化的值在集群環境下有可能會發生變化。

以上對程序的調整與修改會經歷比較長的時間，會對用戶的使用造成一定的影響。

5 結束語

系統整合是一項龐大的系統工程，涉及的方面遠大于文中涉及的內容。文中只是基于成熟的平臺軟件進行系統集成的一種設計方案，該方案已經在某大型工程公司的系統整合中使用，通過實際測試達到了預期目的，并取得了很好的效果。

［1］ GOPALAKRISHNAN K.Oracle Database 11g RAC手冊［M］.2版.賈洪峰，譯.北京：清華大學出版社，2012.

［2］ ARTIGES M.BEA Web Logic Server 8.1大全［M］.袁毅，談莉婭，宋燕紅，譯.北京：機械工業出版社，2005.

［3］ 胡利軍.Web集群服務器的負載均衡和性能優化［D］.北京：北京郵電大學，2010.

［4］ 谷平反，趙軍.雙機環境下并行數據庫實現方式研究 ［J］.無線電工程，2003（09）：3-5.

［5］ 吳家祺.Web服務器集群系統的設計與實現［D］.南京：南京航空航天大學，2005.

［6］ 石開強.集群Web代理服務器的設計［D］.成都：成都電子科技大學，2008.

［7］ 李俊青，周恩，符天.服務器集群及負載均衡的研究 ［J］.電腦知識與技術，2009，5（26）：4.

［8］ 碩珺.PC集群負載均衡調度策略研究［D］.北京：中國石油大學，2010.

［9］ 李長志.集群服務器系統負載均衡原理的分析與實現［J］.重慶郵電學院學報（自然科學版），2004（06）：10-11.

［10］ 朱晴.基于Oracle9i數據庫系統性能優化［J］.電腦知識與技術，2007（12）：10-11.