清算系统架构：全球化时代的银行信息系统建设

全球的支付清算系统需要满足如下特点：

1）支持全球集中部署，为业务集中化处理提供保障。

2）支持集群部署，保证系统运行稳定。

3）支持产品灵活定制。

4）符合SOA设计理念。

5）具有强壮的、可定制的、完整的数据模型，该数据模型具有先进性、稳定性、可扩展性。

6）支持业务需求的快速开发实现。

7）支持7×24h不间断运行。

8）支持多银行、多语言、多时区处理。

9）支持多渠道接入。

1.系统架构

支付清算系统与银行内部相关系统保持松耦合关系，同时与这些系统无缝集成，以便充分利用银行内部系统现有功能实现支付业务处理。图4-32展示了支付清算系统与银行内部相关系统的关系。

图4-32 支付清算系统架构

图4-32所示主要由账务系统、渠道系统、业务系统等部分组成。

1）账务系统。包括联机账务、CIF客户信息、晚间总账等系统，该类系统提供账务处理以及信息查询等基本功能。

2）渠道系统。包括网银、批量支付、手机银行等系统。相对于支付清算系统而言，该类系统是业务发起渠道，支付清算系统需要接收该类系统发起的支付请求并进行相应的处理。

3）业务系统。包括反洗钱、查询查复、流动性管理等系统。该类系统配合支付清算系统完成相关业务流程处理。例如与查询查复系统配合，完成查询查复相关业务处理等。

4）后线支持系统。如汇率发布、影像平台等系统。该类系统，为支付清算系统提供基础信息支持，供其完成支付业务处理。例如提供汇率信息，供支付清算系统进行汇率换算等。

5）批量报表系统。如报表展示、数据存储平台等系统。该类系统接收支付清算系统相关交易数据和基础数据，供业务或其他系统使用。

6）各国清算系统接口。如美国FEDWIRE、CHIPS等。支付清算系统从该类系统或向该类系统发送和接收报文，并进行处理。

支付清算系统与上述各类系统交互时，有如下几类交互方式：

1）单向推送交互方式。与批量报表系统的交互方式即属于此类。

2）单向接收交互方式。与渠道系统的交互方式即属于此类。

3）双向交互方式。与账务系统的交互方式即属于此类。

支付清算系统采用“单向推送交互方式”与外围系统交互时，需要按照外围系统的要求推送出合适的数据。

支付清算系统采用“单向接收交互方式”与外围系统交互时，需要外围系统按照自己的数据格式送入数据。

支付清算系统采用“双向交互方式”与外围系统交互时，需要按照外围系统的要求推送出合适的数据，同时要求外围系统按照自己的数据格式送入数据。

在上面的各种交互方式中，数据格式纷繁复杂，同时对于数据的处理方式也不尽相同，因此在后续支付清算系统应用架构和逻辑架构设计时，对于使用不同交互方式的银行内部各类系统，需要采用不同的集成和设计策略。

2.应用架构

支付清算系统内部根据应用功能划分，可以分为支付处理、支付管理、基础功能三部分。支付处理功能包括：借方账号获取、贷方账号获取、支付路径选择、账务处理等。支付管理包括：账户管理、权限管理、工作流管理、汇率管理等。基础功能包括：协议转换、格式转换、流量控制、高可用性等。

两层系统架构（核心层+总线层）是一种可供支付清算系统使用的应用架构设计方法。核心层负责实现支付处理、支付管理功能，总线层负责实现基础功能。图4-33展示了采用两层系统架构设计的支付清算系统应用架构模型。

支付清算系统核心层专注在一个强大的数据模型上根据相关配置属性进行业务处理，不用考虑或尽量少地考虑其他与之关联的系统由于新建接口或接口变更而对核心层造成的代码修改冲击，从而保证核心层的稳定性。

支付清算系统总线层屏蔽与之关联系统的内容形式的多样性，通过一种通用的接口数据模型，把关联系统形式多样的内容以一种核心层无须修改代码就可使用的方式送入核心层，供核心层仅通过配置的方式实现与这些内容相关的业务需求。

图4-33 支付清算系统架构

当支付清算系统通过上述方式设计后，可以达到核心层和总线层的解耦，有效保证核心层业务处理功能的稳定和健壮性，并同时通过总线层的灵活使用保证系统的可扩充性和兼容性。

下面简述各层的设计思路：

（1）核心层设计

为了达到及时响应市场需求、快速推出业务产品的目标，需要核心功能足够灵活。核心层设计的宗旨是：功能原子化、服务化和动态参数化，业务组合流程化、动态参数化和可配置化，最终达到核心层的高度稳定。为此，核心层的设计需要满足如下两个基本要求：

1）业务数据模型需足够强壮，且易于扩充和存储。

①该模型要充分参考支付行业内的业务规范和标准，如ISO20022报文和SWIFT FIN报文。这样可以最大限度地覆盖支付业务的各种属性，做到对支付领域的深度支持。(www.xing528.com)

②该模型要达到对系统逻辑实现的全面覆盖，即把系统逻辑处理过程中涉及的主要数据项都放到业务数据模型中，以便展示给用户，供用户通过配置，来影响系统的逻辑运行。

③该模型要做到数据的灵活存取和映射。例如以XML方式存储数据，以XPATH方式根据配置的路径支持灵活读取。

④该模型还要实现对未知数据的动态扩展支持，以满足未来业务和报文属性不断变化的需求。

2）业务处理流程需足够灵活，且业务处理流程上的各种功能可以在上述健壮的业务数据模型上进行灵活的变化。一个复杂系统的业务处理流程设计，需要考虑以下两点：

①业务处理流程工作流化、动态化和可配置化。

②业务功能的原子化、服务化和动态参数化。

针对上述两个方面，下面进行详细描述。

a.在业务处理流程上采用三层设计，即最高层采用工作流、中间层采用Web Serv-ice（一种面向服务的架构技术，通过标准的Web协议提供服务，目的是保证不同平台的应用服务可以操作），最底层采用规则引擎。

最高层采用工作流，可以基于中间层的Web Service来构建不同的业务流，来处理支付清算中的大额清算、小额清算等不同的业务流程。如图4-34所示，通过复用不同的Web Service，实现大额清算工作流和小额清算工作流。

中间层采用Web Service，可以实现业务功能的最大化复用，例如大额清算和小额清算业务流中都存在计算费用，可以作为Web Service来实现最大化的复用。

最底层采用规则引擎，可以实现在单个Web Service中，通过参数配置的方式，来决定Web Service的运行效果。

图4-34演示了工作流、Web Service、规则引擎的协同工作。其中，报文拆分、报文解析等都是Web Service。基于各个Web Service的组合形成了大额清算工作流和小额清算工作流（图中，浅色的为大额清算工作流、深色的为小额清算工作流）。在计费功能中，通过设置不同的规则，并运行规则引擎，达到不同的费用计算效果。

图4-34 清算系统业务流程

b.在业务处理功能上采用三种实现方式，即运算逻辑、修改逻辑和选择逻辑。

运算逻辑指实现某个业务功能的运算，可以通过数据库表进行设置（例如费用）或程序固化。

修改逻辑指通过规则引擎来修改运算逻辑中涉及的各变量的属性值。

选择逻辑指通过规则引擎基于客户的不同要求来选择运算逻辑的实现方式。

图4-35演示了三种实现方式协同工作实现“根据客户VIP等级计算优惠费用”的功能。运算逻辑提供计算借方外币转汇手续费和人民币转汇手续费的计算功能。选择逻辑提供根据不同的客户要求选择不同的费用运算逻辑的能力。修改逻辑提供设置运算逻辑中费用折扣率属性值的能力。

图4-35 清算系统业务处理功能示意

通过前述的数据模型和业务处理流程的设计，核心层功能已经非常灵活和健壮。对于新的业务需求，只要没有超越运算逻辑的范围，都可以通过规则引擎基于数据模型中各个数据属性，实现运算逻辑的灵活选择、组合和跳跃。

此时的核心层已经不再关注各类清算系统的报文格式，因为各类报文格式都被转化和映射到核心层的数据模型上。同样，核心层也不关心银行内部各对接系统的通信和交互方式。因为对于核心层而言，任何银行内部各对接系统仅仅意味着核心层的业务流程是否执行或终止，而银行内部各系统返回的其他信息对于业务的自动化处理是没有决定性作用的。

（2）总线层设计

基于前面介绍的核心层设计方式，核心层功能已经非常灵活和健壮。在此基础上，通过设计合适的接口数据模型，总线层可以把关联系统形式多样的内容以一种核心层无须修改代码就可使用的方式送入核心层，供核心层仅通过配置的方式实现与这些内容相关的业务需求。

基于上述分析，总线层的主要目标如下：

1）制订统一的接口数据模型，可以满足各种清算系统和银行内部系统与核心层的数据交互要求。该接口数据模型与核心层的业务数据模型原则上应该是高度一致的，只有这样，才能保证核心层的数据模型与接口数据模型的自由转换。

2）把各种清算系统的报文格式转化和映射到上述接口数据模型中。

3）把各种银行内部系统与核心层的交互数据转化和映射到上述接口数据模型中。

4）同时实现相关的通信协议转换、流量控制等辅助功能。

3.逻辑架构

支付清算系统采用SOA面向服务的设计理念和J2EE的分层设计方式进行设计。图4-36介绍了支付清算系统的逻辑架构。

图4-36 支付清算系统逻辑架构

支付清算系统由客户端、展现层、业务逻辑层、数据访问层和总线层组成了逻辑架构，并通过分布式缓存技术实现数据缓存，以增强性能。

根据SOA面向服务的设计原则，在展示层上，通过展现服务突出服务消费原则。在业务逻辑层，通过服务组件库实现服务生产原则。

根据J2EE分层设计原则，客户端负责采用诸如Web2.0、Ajax、Jason、Https等技术，通过与展示层交互，实现信息的浏览和阅读。

展示层由Web页面和展现服务组成。Web页面采用诸如JSP2.1、Servlets技术，实现与客户端的信息接收、解析、返回信息的组装和推送等功能。展现层采用诸如Soap1.1/1.2技术，实现Web Service调用相关功能。

业务逻辑层由服务组件库、规则引擎和业务流程编排组成。规则引擎实现了业务功能的灵活性、多样性；业务流程编排实现了把相同的业务功能组合成不同业务工作流的功能；服务组件库则把各种业务功能以Web Service的形式展示给外部使用。

数据访问层采用诸如EJB3、JPA、JDBC4.0技术实现访问外部数据库的功能。对业务逻辑层而言，屏蔽了数据库的实现差别。

总线层采用诸如EJB、SCA等技术，实现了报文格式转换、通信协议转换和流量控制等功能。对业务逻辑层、展现层而言，屏蔽了与其他系统交互的复杂性和多样性。