郵政儲蓄銀行信息系統應用軟件架構的研究

王 剛 朱歷超 魯曉蕾

（陜西省漢中市郵政局，陜西 漢中 723000）

郵政儲蓄銀行的信息化建設經歷了市縣接入點、 統一版本、物理集中和邏輯集中四個階段，其中邏輯集中有大型機和小型機集群方式。 在邏輯集中采用小型機集群方式下，按照信息系統生命周期的原理， 必須對系統應用軟件的設計原則、物理架構、邏輯架構進行分析研究，確保代碼編寫、測試、推廣等工作的順利實施，這是系統具有一致性、高可靠性、安全性、完整性的基礎[1]。

1 系統架構原則

（1）一致性原則：架構設計應遵循IT 規劃目標架構的總體要求。 （2）高效性原則：系統架構和應用軟件架構設計，充分保證基于數據邏輯大集中的系統投產后高效平穩運行。 （3）安全性原則：應充分保證數據的安全性、完整性和一致性。 （4）完整性原則：滿足業務需求，覆蓋業務需求的廣度，達到業務需求的深度。 （5）前瞻性和靈活性：系統架構設計能夠適應為了新業務、新流程、新崗位和新環節的變化，支持新產品和服務的快速開發[2]。

1.1 系統架構目標

在IT 規劃中系統的目標見圖1 所示。

圖1 應用系統架構的目標

為支持郵政儲蓄銀行新業務品種快速推出， 提高系統模塊復用性和靈活性，應用系統采用了層次化的建設模式，主要包括渠道層、渠道管理層、數據分析平臺等[3]，各層的主要功能說明如下：

渠道層：包括手機、電話、視頻、瀏覽器等自助電子渠道和高柜、低柜等銀行對外營業窗口。

渠道管理平臺： 該平臺負責所有電子渠道及網點柜面交易的統一接入，經過安全認證等邏輯處理后將交易轉發到后臺各業務系統。 這一層還包括外聯前置，該前置負責處理與第三方系統的信息交互，對第三方的接入，盡可能采用統一的建設。

數據分析平臺： 日終所有業務系統的交易流水和會計信息都要傳給數據分析平臺，進行數據的整合和分析。

1.2 系統邏輯架構

邏輯集中的系統邏輯架構如圖2 所示。

圖2 儲蓄系統邏輯集中架構

儲蓄系統邏輯集中包括三大部分：網點前置系統、柜面渠道前置系統和邏輯集中業務處理系統。 柜員錄入交易并提交后，網點前置系統發起交易請求到柜面渠道前置系統，并負責接收返回的應答報文進行后續處理[4]。

柜面渠道前置系統屬于渠道管理層， 實現統一機構、柜員、權限、尾箱的管理。

1.3 系統物理架構

1.3.1 各級應用部署。 儲蓄系統邏輯集中部署在全國中心，共有11 個子系統，如圖3 所示。

圖3 系統應用部署

1.3.2 系統網絡架構。 系統網絡架構如圖4 所示，其中包含全國中心、省中心與二級分行、支行及網點三個部分。

圖4 系統網絡架構

2 應用軟件架構

2.1 設計要求

應用軟件設計要求如下[5]：（1）系統按照層次化、模塊化、參數化進行設計。 （2）系統應具備擴展性能，具備承載大業務量的能力，以滿足手機銀行業務范圍不斷拓展、業務流程不斷改進、產品和功能不斷擴充、客戶數量和業務交易量不斷增加的需要。 （3）系統應滿足金融系統三個方面的安全要求，即認證、授權和審計。系統支持軟加密和硬加密兩種方式。（4）系統上線運行穩定后，各交易環節流量可控，相關指標為系統處理業務量TPS 值為12500 筆/秒、高峰期1.8 億筆；跨行交易成功率達到99.9%，賬務交易差錯率不高于0.005‰。 行內交易成功率達到99.9%，賬務交易差錯率不高于0.005‰；系統主機CPU 平均利用率不高于40%，內存平均利用率不高于60%，I/O 平均利用率不高于30%；系統故障引起服務中斷時間不超過4 小時/年；日終批處理時間不能中斷正常交易，必須當日完成當天日終批處理交易，日終批處理時間＜4 小時；結息時間應小于4 小時；結息日，日終時間應小于6 小時。 （5）系統運行監控保證7×24小時不間斷。

2.2 應用架構設計原則

（1）高處理性能：在充分保障高效、穩定的主機處理性能、存儲I/O 吞吐量、網絡I/O 流量的基礎上，以分離關注點的思想為中心，從架構層次考慮盡量提升處理性能。 （2）高可靠性：儲蓄系統邏輯集中承載了銀行最大客戶群體的日常交易，在系統總體設計方案中，要充分考慮應用軟件的因素，盡量采用有利于應用軟件架構設計中高可靠性的設計。 （3）可擴展性：儲蓄系統邏輯集中涉及眾多的業務處理功能，這些功能作為銀行的核心處理功能，是面向客戶服務的基礎，功能的可擴展性是需要考慮的問題。 （4）可維護性：儲蓄系統邏輯集中涉及的基礎設施有小型機、存儲、網絡，再加上應用軟件復雜的邏輯結構，容易對運行維護造成較大的壓力。 應關注應用監控、自動化部署管理、自動化升級管理。 （5）架構先進性：儲蓄系統邏輯集中以Unix 小型機集群為基礎，參考和借鑒云計算的先進架構思想進行建設[6]。

2.3 應用架構總體設計

（1）應用系統需要按照層次化的模式進行建設，如圖5 所示。 （2）根據業務需求的范圍劃定和原型測試確定的方案，系統邏輯架構如圖6 所示。 應用系統由網點前置系統、柜面渠道前置系統、邏輯集中業務處理系統三部分組成。 儲蓄邏輯集中業務處理系統由8 個子系統組成。

圖5 應用架構層次模型

圖6 儲蓄系統邏輯集中邏輯架構

2.4 應用架構設計思路

（1）統一柜面渠道管理。 在儲蓄系統邏輯集中總體架構中設計了獨立的柜面渠道前置系統， 實現柜面渠道的統一管理，主要圍繞5 個主題進行管理[7]，即機構權限管理、柜員權限管理、簽到和簽退管理、軋帳管理、交易系統路由等。

（2）統一接入管理：邏輯集中涉及眾多的關聯系統，所有關聯系統都通過統一的接入管理模式接入到邏輯集中系統。 每個關聯系統有不同的處理要求，隨著業務功能的發展這些處理需求也將發生變化。 為保障業務處理功能的穩定性，與關聯系統實現松耦合，通過統一的接入管理實現對關聯系統的隔離。

（3）業務處理子系統設計：邏輯集中系統的業務處理應進行歸類，基于歸類劃分不同的子系統進行建設。 歸類劃分主要依據有面向的主體對象、對系統造成的處理壓力、技術實現模式、系統部署及后續的應用容災、應用接管的可行性。

（4）統一管理的日終處理：邏輯集中面臨多種多樣的日終處理，這些日終處理應通過統一的日終調度、控制框架統一管理。 建設獨立的日終處理子系統，統一協調其他子系統配合完成每日的日終處理。

2.5 業務層邏輯架構

業務層應用軟件邏輯架構圖如7 所示。

圖7 應用軟件邏輯架構

從邏輯層次結構上看， 業務層應用軟件可以分為三個層級，即接入層、產品管理層、業務處理層[8]。 （1）接入層：接入層直接面向邏輯集中的各關聯系統，完成與關聯系統的交互。 接入層是邏輯集中與關聯系統構建松耦合的服務請求、服務響應關系的關鍵。 （2）產品管理層：產品管理層面向業務處理層的各個業務處理服務，進行業務產品定義及業務產品處理控制。 產品管理層面向接入層提供業務產品處理服務，屏蔽業務處理層對服務請求的響應、 處理細節， 降低接入層服務請求的復雜度。（3）業務處理層：業務處理層針對具體的業務需求，參照SOA的服務設計理念提供具體的業務處理功能服務。

2.6 渠道管理層邏輯架構

儲蓄系統邏輯集中需要通過柜面渠道前置系統完成柜面渠道的接入。 柜面渠道前置系統在總體架構中處于渠道管理層，屏蔽了業務層的實現細節。邏輯架構如圖8 所示。其中柜面渠道接入、業務層接入處理如圖9 所示。

圖8 柜面渠道前置系統邏輯架構

圖9 接入處理功能結構

2.7 渠道層邏輯架構

渠道層可以分為柜面渠道、電子渠道兩大類，如圖10 所示。

圖10 渠道層邏輯結構

儲蓄系統邏輯集中的渠道層建設原則：（1） 儲蓄業務、匯兌業務通過統一的前端界面交互。 （2）柜員通過統一的一次登錄即可訪問其權限內的所有功能。 （3）前端界面支持字符界面和圖形界面。 （4）針對具體業務功能，盡量保持原有界面風格的不變化，但需要兼顧系統的整體使用方便性、一致性。

2.8 架構性能設計

依照應用軟件架構設計原則， 必須注重應用處理的性能設計，以保障系統上線運行后足以支撐全行的業務量，同時也滿足今后業務持續發展的處理性能需求[9]。

2.8.1 分離處理功能。 為獲得高處理性能，可以將處理功能進行分離。 主要內容有：（1）通過獨立的會計處理平臺的同步建設，將本外幣儲蓄、匯兌業務涉及的會計相關處理分離；（2）通過獨立的集中清算系統同步建設，將本外幣儲蓄、匯兌業務涉及的清分、結算相關處理功能分離；（3）通過獨立的客戶信息系統同步建設，將客戶信息相關處理功能分離。

2.8.2 分散處理壓力。 對于復雜的應用軟件系統而言，較好的處理能力來源于應用處理壓力的分散。 應用架構設計中將主要通過如下兩個方面分散處理壓力：（1）業務功能分散部署，業務功能基于業務產品、功能處理特點進行歸類、整理，將業務功能按照不同的歸類以分散方式進行部署，充分利用小型機集群系統特點分散系統處理壓力。 （2）分散至多節點，應用軟件支持以功能服務為單位，將同一功能服務分散部署到不同的應用服務器節點，使多個節點可以同時接收不同的應用處理請求。

2.9 高可靠性設計

2.9.1 應用負載均衡。 應用軟件負載均衡通過多個層次上不同的負載均衡策略一起實現整體的負載均衡。 應用軟件負載均衡主要目的：（1）避免服務請求集中于單一節點導致擁塞。（2）提高服務響應速度。 （3）提高服務器及其他資源的利用效率。 如圖11 所示。

圖11 應用負載均衡框架

2.9.2 應用軟件失效備援。 應用軟件構建在面向服務的架構、設計思想上，應用軟件的失效備援體現為：在通用的應用服務管理框架下的應用服務的失效備援。 應用服務具有較高的可靈活部署性。 通過這種靈活性，結合系統基礎設施的規劃、部署可以實現應用軟件的失效備援。

2.9.3 故障隔離。 在應用軟件系統發生故障時，通過故障隔離把故障造成的危害限制在最小范圍內，提高系統提供對外服務的整體水平。 應用軟件設計必須支持多角度，多層次的故障隔離。

3 應用架構關鍵點

依據應用架構設計原則， 有必要對架構設計中的關鍵內容進行分析，并以此為基礎形成最終的應用軟件架構。

3.1 權限管理

各子系統實現統一的權限管理， 應用軟件提供多層次的權限管理和控制。 如圖12 所示。

圖12 權限管理功能組成結構

3.2 簽到/簽退、尾箱及軋帳管理

儲蓄系統邏輯集中通過柜面渠道前置系統實現對柜面渠道涉及的所有簽到操作、簽退操作、尾箱管理、軋帳管理進行統一的控制。

（1）簽到／簽退：統一簽到管理如圖13 所示。 統一的簽到、簽退處理由柜面渠道前置系統處理，包括儲蓄系統邏輯集中涉及的所有各類操作人員。 （2）尾箱管理如圖14 所示。 對儲蓄系統邏輯集中而言，涉及現金、憑證的操作都在普通柜員尾箱中進行，因此相關操作都在柜面渠道前置系統進行處理。 對會計處理平臺而言，涉及綜合柜員尾箱、機構間現金和憑證的調撥操作的，會計處理平臺需要參與到交易的處理流程中來。 （3）軋帳管理如圖15 所示。 柜員軋帳處理由柜面渠道前置系統完成。

圖13 統一簽到功能示意圖

圖14 統一尾箱管理示意圖

圖15 統一軋帳示意圖

3.3 接入管理

接入管理包括三方面的內容，電子渠道接入、行內其他系統接入及行外系統接入。 所有交易請求轉換為統一的服務請求格式，即通過接入管理屏蔽各接入系統的差異。 如圖16 所示。

圖16 接入管理功能結構

為支持各相關系統在具體服務申請上的差異， 更好的配合后繼具體業務的處理，接入管理需要根據后端業務產品的設置實現對服務請求的轉換， 以屏蔽兩系統間在具體技術細節、服務框架、服務范圍等方面的差異。

3.4 產品管理

產品管理的基礎是對系統服務的管理， 邏輯集中系統以應用服務為最小的管理單元，應用服務的組織和定義是具體的產品和產品服務。 如圖17 所示。

圖17 產品管理功能結構

應用服務管理框架： 邏輯集中采用面向服務架構的方法進行規劃、設計。 應用服務是整個系統運行的基礎，也是系統框架具備前述各項特性的基礎。 系統架構中的業務處理層包含所有各類業務處理功能，是主要的服務供應者。 產品管理層和接入層的處理功能也以服務方案提供，但相對于業務處理層的服務對服務粒度、服務契約等方面的具體考慮可以有所不同。

3.5 客戶服務參數體系

應用軟件中提供對客戶服務參數體系的支持， 用于應對特定客戶的差異化服務需求。 客戶服務參數體系邏輯結構如圖18 所示。

圖18 客戶服務參數體系邏輯結構

3.6 結息

儲蓄邏輯集中業務處理系統目前涉及的活期賬戶數平均大于8 億， 其中的大部分賬戶都需要進行定期的批量結息處理。結息屬于日終處理的一部分，在結息日自動執行。對于結息處理主要考慮如下幾個方面的問題，如圖19 所示。

圖19 結息需要考慮的問題

需要特別指出的是結息數據共享問題： 結息操作將產生大量的相關數據，這些數據屬于邏輯集中外其他系統所需的共享數據，共享應考慮結息數據與日常共享數據在數據量上的巨大差異。 獨立的結息子系統如圖20 所示。

圖20 結息功能實現原理

3.7 應用數據同步

應用軟件架構中，需要在各子系統間進行數據同步。 具體的同步操作將通過應用數據同步適配器實現，適配器針對每個具體的待同步數據進行同步操作。 同步適配器的結構如圖21所示。

圖21 應用數據同步適配器結構

4 結束語

根據系統開發生命周期的瀑布模型和螺旋模型， 系統設計是系統實現的重要基礎，主要內容包括總體結構、代碼、處理流程、模塊功能、安全控制等設計。 在分析了郵政儲蓄銀行信息系統邏輯架構和物理架構的前提下，研究了應用軟件架構的設計要求和原則，能確保系統邏輯集中物理實現的順利實施和推廣。

[1]肖丁，吳建林，周春燕.軟件工程模型與方法[M].第一版，北京:北京郵電大學出版社2008:110-133

[2]劉欣怡，周躍東，田秀麗.軟件工程[M].第一版，北京：清華大學出版社，2007:10-31

[3]羅積玉，李超.軟件工程的推進方法[M].第一版，成都:電子科技大學出版社，2004:12-29

[4]王愛平.實用軟件工程[M].第一版，北京：清華大學出版社，2009:23-36

[5]朱彬.企業級應用軟件架構模式的研究和應用[D].沈陽工業大學，2004:7-20

[6]陸平.住房公積金管理信息統軟件架構設計[D].南京大學，2008:21-30

[7] 張晰. 基于復雜事件處理的金融軟件系統實現及改進[D].浙江大學，2003:8-19

[9]吳春，劉平.關于企業級應用軟件體系結構的研究[J].貴州大學學報，2003，20(4):414-417