邮政储蓄银行信息系统应用软件架构的研究

王 刚 朱历超 鲁晓蕾

（陕西省汉中市邮政局，陕西 汉中 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