银行信息系统架构：合作互联业务的核心与应用平台

随着我国国民经济的不断发展，计算机网络技术的不断普及，商业银行与社会各行业金融服务往来日益频繁。在此大背景下，国内商业银行纷纷开展了跨行业机构间的业务合作，共同为客户提供方便、快捷、安全、品种丰富的各类金融服务。为此，各商业银行构建了种类繁多的合作互联应用系统。

1.合作方应用通用解决方案

与银行之间存在合作关系的通常是银行大客户，或者政府机构、监管机构、各种行业组织，例如中国人民银行、外管局、海关、银行卡国际组织、各类交易所等。不同行业机构的产品、服务和流程存在较多差异，而其合作业务往往又要求商业银行能够快速实现信息系统的支持，合作互联产品和服务能够快速上线使用。因此，合作互联应用架构设计需要重点关注系统的灵活性、复用性，要兼顾系统的行业通用性和可扩展性。

合作互联业务的核心是合作互联双方提供的产品协作与服务整合。合作方与银行产品之间是多对多的关系，同一合作方使用商业银行单一产品的情况较少；当同一银行产品被多个合作方使用时，由于合作方特性不同，所提供的产品服务也不尽相同，见表3-7。因此，构建一个通用的、灵活性高的合作互联系统，首先需要从业务架构入手，分析不同行业、产品、流程、功能的服务共性，将合作方产品与商业银行产品剥离，将合作方特性与共性剥离，采用分层设计思想，提炼共性服务形成合作互联应用核心基础服务。其次，抽取行业、产品、业务功能的行业共性，形成各行业标准模型。最后，基于抽取形成的行业模型和核心基础服务构建合作互联平台，并根据合作方行业特性提供个性化扩展支持，桥接相关的银行服务，形成完整的行业解决方案。合作方互联系统架构示意图如图3-34所示。

表3-7 合作互联业务

对于商业银行新增的合作方业务，可以快速定位合作方行业和产品，从而确定需要使用的具体业务模型和基础服务。然后根据具体合作方机构特性进行实例化，以及业务流程、产品个性化定制和扩展，实现合作方业务和产品的快速上线。

合作互联应用平台采用面向服务、层次化架构设计理念，由服务交付层和服务提供层组成，如图3-35所示。其中服务交付层采用消息驱动模式，对外发布银行金融服务。服务提供层实现服务组合，提供各类行业领域所需特色服务。平台通过服务标准化定义，针对不同行业领域实现开放式金融服务API接口。支持合作互联金融服务的多银行代理、多合作机构运行、多渠道服务等业务处理模式。

以民生领域服务为例，按照“领域建模、服务分层”的架构设计原则，搭建民生领域合作方应用系统，将民生领域与银行金融领域的服务标准化，并与灵活的业务模型、核心基础服务相组合，以适应不同民生领域的业务服务需求。系统支持第三方渠道与银行自有渠道的相互访问，实现了服务渠道、服务实现、服务发布等民生领域金融服务全生命周期的管理。丰富的可扩展支持的API接口可以满足包括医院、公积金中心、地方财政等合作机构的定制化需求。

(www.xing528.com)

图3-34 合作方互联系统架构示意图

图3-35 合作互联应用平台

2.高时效性互联通信分层设计

按照连接方式，银行与合作互联主要分为间联、直联二种模式。间联是指银行与合作方通过网络以批量交互数据的方式合作互联。直联是指银行与合作方通过网络以实时交互数据的方式合作互联，该合作模式又被称为高时效性的合作互联模式，其显著特点是交易时效性要求高，与外部市场环境关系紧密，存在交易瞬时突发的可能性较高。

高时效性的合作互联应用系统，可以把整个外联部分划分为前置服务和后台业务处理两部分。前置服务组件负责建立与合作方系统之间的互联通道，提供相应业务报文的协议转换、报文发送和报文接收功能。外网传输功能统一由前置服务组件实现，负责外联传输服务的统一管理，以提高外网传输安全性。后台业务处理组件支持与银行业务处理相关服务，主要与产品、客户、账户、协议相关，提供重用性较高的、具有较高性能要求的功能或服务支持。

前置服务组件与合作互联通信过程，部分接收方的传输和处理流程是分离的，当传输系统收到报文时，首先会向请求方返回应答报文，同时转发到处理系统中，当处理系统接收到请求报文后，进行合法性、逻辑性校验并成功处理后，会向请求方返回回报信息。例如，商业银行与金交所系统之间的通信就是上述的情况。在此模式下，请求方将会在较短的时间内收到报文应答和报文回报。从数量上，一个请求报文对应一个报文应答和一个报文回报（也有可能存在多个应对、回避），在实时高并发交易模式下，如果前置组件把收到的报文应答和报文回报都一视同仁，转发给后台处理，则商业银行后台应用系统将面临不必要的交易压力。从考虑银行运营安全和处理效率的前提下，可以考虑减少不必要的通信和处理环节，前置服务组件不必转发报文应答给后台处理相关组件和应用系统，如图3-36所示。

图3-36 报文通信分层设计示意图