基于SOA的银行集团“新一代”系统架构①

金磐石, 朱玉红, 胡宪忠, 李 骁

(中国建设银行股份有限公司 信息技术管理部, 北京100140)

基于SOA的银行集团“新一代”系统架构①

金磐石, 朱玉红, 胡宪忠, 李 骁

(中国建设银行股份有限公司 信息技术管理部, 北京100140)

大型商业银行集团在信息化的进程中面临内部系统众多、实现平台不统一、资源利用率低、成本高、需求响应周期长等弊端. 随着我国银行业的快速发展, 大型商业银行集团系统架构革新势在必行. 本文重点介绍在“新一代”系统建设中采取的基于SOA的架构以及组件化设计的方法. 通过7+1层、12P的整体架构设计, 保证了应用组件、构件间的松耦合, 实现子公司与海外一体化的企业级应用, 从而整合银行集团资源、快速响应业务需求, 达到提升业务可靠性、可用性的目的. 与此同时, 引入企业级业务模型对业务进行标准化, 用结构化的模型语言描述业务能力, 使用流程模型、数据模型、产品模型及用户体验模型为企业级分析及设计工作提供方法和依据.

SOA架构; 商业银行系统; 7+1层; 12P; 企业级业务模型

1 简介

随着业务的发展和信息化的深入, 如何设计满足业务动态变化和流程银行的信息系统架构, 已成为银行下一步信息化建设的重要课题. 银行信息化的重点从单一业务系统建设和改造, 向针对大数据量、高并发访问的企业级架构设计转变.

“新一代”摒弃以往基于部门级需求的分析、设计模式, 从业务架构及IT架构两大方向入手, 建立起统一、规范的企业级架构规划.

业务架构关注对银行业务的企业级描述, 其表现形式为企业级业务模型. 基于业界领先的理论和最佳实践, 将企业级业务模型细分为流程模型、数据模型、产品模型及用户体验模型. 流程建模采用基于TOGAF[1]标准的五级建模方法, 数据建模以金融服务数据模型(FSDM)[2]为基础. 通过企业级业务建模逐层细化战略规划、产品参数化设计以及向流程银行的转变.

IT架构承接业务建模成果. 分为应用架构、数据架构、技术架构以及安全架构[3]. 应用架构关注逻辑应用组件及物理应用组件的实施. 数据架构关注企业级数据模型、数据字典的管理. 技术架构关注技术路线选择、基础设施规划、技术产品目录及部署架构, 安全架构关注企业级安全验证、安全组件的设计及使用.

采用基于SOA的组件化设计方法[4], 将IT架构整合为7层, 此外设计基础设施层作为支持. 7+1层进一步细化为12个技术平台(下文简称12P), 各平台提供通用技术组件, 上层应用基于通用技术组件完成组件化设计和参数化设计.

IT架构规划最终要在机房、服务器、网络等IT基础设施上落地. “新一代”初步建立了基于云计算技术的基础设施环境, 完成了“两地三中心”的灾备方案设计和部分实施工作.

本文主要阐述“新一代”建设中采用的企业级业务模型、“新一代”7+1层及12P的架构设计、基于云计算技术的基础设施建设以及“两地三中心”灾备方案等内容.

2 企业级业务模型

企业级业务模型是以现状业务流程、数据和产品实践为基础, 以待实现的业务需求为输入进行目标建模. 目标模型是IT实施的基础. 企业级业务模型细分为流程模型、数据模型、产品模型及用户体验模型.

2.1 流程模型

采用基于TOGAF[1]标准的五级建模方法作为指导完成流程建模. 银行业务可从五个层级进行描述:

①一级业务领域: 对应银行集团主要业务, 分为核心业务和支撑业务. 如信贷、存款属于核心业务领域, 客户管理属于支撑业务领域.

②二级业务领域内业务组件: 业务领域内部各价值环节, 代表业务功能. 如客户管理领域包含客户信息管理、客户服务管理、合作伙伴管理等功能.

③三级活动: 企业级视角完成某个具有明确目的、创造价值的端到端流程. 如采集客户信息包含从检索客户信息到收集、维护、审核客户信息修改的全流程.

④四级任务: 描述部门或业务单位为完成三级流程所需不同角色完成的具有明确业务目的的事情.如维护客户信息是由同一角色连续完成的任务.

⑤五级步骤规则: 描述员工为完成四级流程所需执行的具体步骤及业务规则. 如维护客户信息包含维护基本信息、联络信息等功能.

每个具体的流程包括了能力的落地实现元素. 如角色、授权信息、政策、业务规则、业务信息、变化因子、业务参考文档和表单报表等内容.

2.2 数据模型

Financial Services Data Model(FSDM)模型[2]是金融行业建立核心应用系统或者数据仓库的数据模型, FSDM模型以数据为中心, 从企业视角提供了自顶向下建立数据蓝图的方法.

2.2.1 企业级C模型及C’模型

FSDM模型提出九大概念(A模型), 即参与人、合约、条件、产品、地点、分类、业务方向、事件、资源项, 作为不同业务领域金融模型的通用性描述.

此外, FSDM模型通过自上而下的层级, 从概念层到物理层逐渐细化. A级、B级模型为概念模型, 企业级C模型提供特定业务范围内的完整属性视图, 是基于目标能力需求及现状系统的数据库表结构, 根据FSDM数据模型设计理念设计得出, 并通过与流程模型对接不断迭代完善.

C’模型在C模型基础上, 增加派生数据以及可控的冗余数据. C与C’模型的关系如图1所示. D模型是物理数据模型, 包含索引等信息. 在“新一代”建设过程中, 数据模型的合理管控是一项重要工作.

图1 C模型与C’模型的关系

2.2.2 企业级数据字典

企业级数据字典是对银行集团经营管理、信息系统研发过程中涉及数据项定义的收录和编制, 通过标准化处理数据项的描述信息提高整体的数据质量, 为业务人员、技术人员以及外部监管提供可靠数据服务奠定基础.

企业级数据字典中的数据来源是数据标准、数据模型、指标数据、技术类数据及元数据. 字典中的每个数据项通过字典编号唯一标识, 通过数据项的分类属性、名称属性、业务属性、技术属性及管理属性进行描述.

企业级数据字典的使用解决了过去同样含义的数据项在不同系统中出现不同名称、长度等情况. 除此之外, 数据字典统一了企业级“数据项”的业务涵义,将企业级“数据项”的技术格式做出统一规范, 数据项的名称、英文简称等均为企业级描述, 同一数据项在所有系统中完全一致. 同时, 企业级数据字典也是检查数据项规范性的基准.

2.3 产品模型

产品建模从企业视角出发, 基于高阶产品目录来优化和完善产品目录, 最终建立企业级的产品模型,确定与产品相关的业务规则、算法、限额、约束、期限、价格等要素项, 并以产品条件及参数的形式表达.

为了达到产品参数化设计, 实现可售产品快速创新、配置与上线的目的, “新一代”采用产品模型作为银行产品的规范化描述方法. 产品按照产品线、产品组、基础产品、可售产品四个层级划分, 所有可售产品均发布在企业级产品目录中.

产品将在产品工厂中组装, 通过结构化、标准化的方法, 使用产品条件、产品参数对基础产品进行描述, 以产品部件的方式完成组装过程, 基础产品通过实例化成为实际可对客户销售的可售产品.

基于产品模型, 产品工厂将会更易于管理银行集团的产品. 产品创新人员可在工厂中灵活选择相应的基础产品、产品组件、产品条件, 进行组件化创新, 更加快捷地将产品推向市场.

2.4 用户体验模型

用户体验模型是从统一系统界面风格和设计标准的角度出发的建模工作. 用户体验建模以现状系统为基础, 结合调研成果, 提出系统界面风格和设计的指导依据, 旨在最大限度提升客户体验.

综上所述, 通过使用企业级业务模型, 用统一建模语言对银行集团业务进行标准化、结构化、规范化的描述, 完成前、中、后台的流程活动对接. 目前企业级业务模型已累计发布14个版本. 流程建模已完成4916个四级任务、23881个五级步骤的建模工作. 数据建模完成147个主题域、2747个实体及25495项属性的建模工作. 产品模型完成12个产品线、45个产品组、123个基础产品, 3722个可售产品的建模工作. 用户体验模型完成327项需求、9802项命名规范、超过150项设计标准.

3 基于7+1层的“新一代”整体架构设计

架构分层是对架构整体复杂性进行解构的方法,“关注点分离 ”是面向服务的架构(SOA)的核心原则.为保持架构的稳定性、灵活性和扩展性, 适应业务的变革和发展, 架构分层遵循这一重要原则.

“新一代”架构中定义了应用和应用组件的概念,用于区分用户视角以及企业视角:

应用: 从用户视角, 基于渠道、产品和客户群, 对同一业务领域下一组活动的实现, 为内外部客户提供整合的产品和服务. 应用关注整合银行产品和服务,提供端到端的、跨渠道统一的完整客户服务流程及业务流程. 提升用户体验是应用的核心目标.

应用组件: 应用组件是基于企业视角的系统功能,是由一组具有特定业务与功能用途, 并存在业务内在联系和相关性的应用组件服务所组成的集合. 应用组件不负责对界面展示的处理实现, 而专注于具体的业务逻辑处理和业务数据处理, 将处理结果以服务形式提供出来, 并通过调用来自其它应用组件或外部的服务进行应用组件间的协作. 应用组件需要屏蔽不同渠道、客户、产品(CPC)的差异, 提供统一的处理逻辑和服务.

应用、应用组件是“新一代”IT目标架构的重要内容, 承载了全部业务功能; 其首要目标就是保持业务与IT的一致性, 实现业务与IT的融合.

3.1 整体架构设计

按照业务功能划分, 架构被分为7层, 除此之外,引入基础设施与治理层作为以上7层架构的基础, 如图2所示.

分层的整体架构提供了集成的综合服务. 渠道整合层作为多种渠道的统一入口, 向后端组件屏蔽前端的多样性和复杂性. 客户服务整合层负责编排和串接产品服务层提供的原子服务, 对外提供集成的客户服务. 产品服务层以应用组件的形式对外提供服务, 产品提供的服务统一发布在应用集成层. 数据集成层则为产品功能提供企业级数据服务. 外联集成层为对外合作单位或监管机构互联互通提供接口服务.

图2 “新一代”整体架构

3.2 渠道整合层

渠道整合层的作用是整合渠道接入, 统一渠道接口处理. 通过标准化接入手段, 渠道整合层接受来自不同渠道的业务请求, 处理并封装请求数据, 调用后台服务并返回结果.

渠道整合层提供内部客户(整合已有高柜、低柜系统)、外部客户(包含ATM、电子银行、手机银行、电话银行、移动终端等)的渠道接入、安全控管认证、接口路由等功能.

3.3 客户服务整合层

客户服务整合层以客户为中心, 从客户视角出发,提供整合的银行产品和服务, 提供良好的使用体验.通过整合端到端的客户服务流程, 为内外部客户提供集成服务.

客户服务整合层基于跨时序、跨角色、跨用户的企业级工作流引擎, 调用产品服务层的服务逻辑完成业务处理过程.

客户服务整合层支持内外部客户按需定制个性化工作流. 支持各类业务领域, 如产品管理、客户之声、理财产品、市场营销和销售管理、集中运营服务、内审与合规等.

3.4 应用集成层

应用集成层通过标准化方式接受来自客户服务整合层(使用工作流的业务)及渠道整合层的服务请求,屏蔽后台服务的技术特性, 以一致的形式返回结果.主要功能包括服务目录管理、报文转换、交易路由、服务调用、资源分配等.

产品服务层的应用组件将服务以统一形式发布在应用集成层的服务目录中. 各组件之间的服务请求通过应用集成层转发及响应.

3.5 外联集成层

外联集成层负责外部金融和非金融机构与“新一代”之间的系统交互. 如第三方支付系统、保险公司、人行征信系统等. 主要完成协议转换、报文转发等功能, 并可提供实时和非实时的服务, 为内部系统屏蔽各类网络接口的技术特性. 接入单位包含SWIFT接入、VISA/MASTER接入、CNAP接入以及第三方支付接入等.

3.6 产品服务层

产品服务层提供企业视角的产品服务, 支持银行集团核心业务, 涉及产品、客户、合约、核算等服务, 提供与渠道无关的产品、服务处理组件. 产品服务层以应用组件作为服务的载体, 将服务发布在应用集成层.

产品服务层包括存款、贷款、代理、贸易融资、托管、客户管理等产品线, 包括子公司的产品和服务,是银行信息系统的核心.

3.7 数据集成层

数据集成层整合企业范围内的各类数据, 提供统一数据存储及交换服务, 为产品服务层和管理分析层提供一致的数据服务. 数据集成层可提供面向企业级数据的集成服务和周期性、大规模数据的批量处理.

数据集成层是企业级信息视图的必要条件.

3.8 管理分析层

管理分析层为银行内部管理和决策提供支持. 该层包含所有管理分析类应用, 所有应用从数据集成层获取数据, 进行加工、处理及分析.

管理分析层包括通过数据分析提供决策支持的应用、风险管理、财务管理、内部管理、黑名单等管理型应用[6].

3.9 基础设施与治理层

应用系统的上线运行离不开基础设施, 基础设施与治理层提供硬件设备、网络、操作系统、中间件和数据库等基础支持.

大型商业银行集团的核心系统一般采用大型机作为基础设施, 面对业务量的飞速增长, 只能通过扩容方式解决, 运行和维护成本越来越高. “新一代”在原有大型机基础上, 参考云计算模型, 采用虚拟化技术搭建了基于X86服务器的云基础设施平台, 逐步形成了“大型机+X86云”的混合基础设施架构. 随着“新一代”功能的逐步释放, 大量产品服务层的应用组件都已经部署在了基于X86服务器的云环境中. 目标是打造“两地三中心”的云数据中心运维体系[5].

4 “新一代”架构中的12个应用平台

根据SOA架构设计原则, “新一代”架构将7层架构分解为12个应用平台. 如图3所示.

图3 12个应用平台

应用平台是一系列软硬件技术组件的集合, 向应用或应用组件提供服务. 应用平台可以看作应用或应用组件的容器.

基于应用平台的开发模式极大程度减少重复开发量, 借助平台提供的通用技术组件及服务可达到敏捷开发, 快速响应业务需求的目的. 整体来看, 应用平台具备如下基本能力:

① 参数化开发能力: 支持灵活的参数配置和管理能力. 如前端界面定制化开发、业务流程的配置、后端产品组件的参数化配置等能力.

② 横向扩展能力: 对于主机平台, 支持Sysplex并行处理. 对于开放平台, 支持集群部署能力, 支持动态负载均衡能力.

③ 高可用支持能力: 支持无单点故障的部署、支持组件或应用功能的热部署能力, 降低系统维护停机时间.

④ 数据加解密能力: 支持交易信息和交易报文的加解密处理、支持关键交易的签名处理、支持对加密信息的存储和访问控制.

⑤ 可跟踪能力: 平台完整记录内外部客户的操作痕迹. 提供跟踪交易异常信息功能. 各平台采用全局事件跟踪号作为交易的唯一标识, 由交易发起端生成, 在全流程中保持唯一, 便于跨平台、组件跟踪问题.

⑥ 应用监控能力: 平台可对应用状态数据进行采集, 提供给企业级的监控系统.

⑦ 安全控制能力: 平台对访问系统的用户进行身份认证, 保证用户合法性. 对外部交互系统进行识别认证, 保证具备交互权限的系统才能访问系统服务.支持访问控制授权和审计跟踪、风险预警能力.

应用平台建立在各种技术框架基础之上, 使用技术框架提供的通用功能组件及服务完成平台功能. 实际开发中, 应用开发者更关注于平台的使用, 底层技术框架对应用开发人员屏蔽技术细节.

4.1 技术框架概述

技术框架是一组具有紧密联系的技术组件的集合,并提供常用的技术性基础功能(如日志记录、基础函数、流量控制等), 具有被各类应用共享且相对稳定的基本特征, 是可以直接支撑应用平台和业务应用开发的企业级可复用软件资产.

“新一代”技术框架包括主机、C、JAVA、电子渠道四个框架. 12个应用平台则构建于技术框架之上,应用平台及技术框架的关系如图4所示.

图4 技术框架定位

由图4可知, 技术框架处于基础设施和应用平台之间, 对下屏蔽基础设施的差异, 构建基础的应用运行环境. 对上为各平台提供通用技术组件.

4.1.1 主机框架

“新一代”主机框架基于大型机环境构建, 并采用主机系统常用的COBOL作为主要开发语言. 主机框架支持采用COBOL开发的产品服务层应用组件, 并支持联机事务处理及批处理功能.

4.1.2 C框架

开放环境通用技术C框架基于UNIX/Linux环境构建, 属于主流的通用性技术框架, 支持UNIX小型机、X86服务器环境下C开发技术, 支持开放环境下渠道整合、客户服务整合、产品服务、应用集成和管理分析等架构层次相关应用的开发.

4.1.3 JAVA框架

JAVA框架使用HTTP协议接入前端服务请求, 服务管理和服务路由等组件都由Spring容器管理. 数据访问层支持目前主流的关系数据库持久化访问技术.该框架可更广泛的去除应用系统各层间的耦合性, 增加服务的复用性, 同时为系统开发提供更多的基础技术的支撑, 使开发者只需关注业务逻辑.

4.1.4 电子银行类型专用框架

由于电子银行渠道系统(网银、手机银行、电话银行、家居银行等)在安全控制、终端系统环境及新技术应用方面的特殊性, 并且其底层实现与具体应用逻辑耦合度高, 因此, 针对电子银行应用开发采用了专用的技术框架. 该技术框架部分组件共享其他技术框架的成果, 但总体而言自成体系.

4.2 外部客户渠道整合平台(P1)

图5 外部客户渠道整合平台整体设计

外部客户渠道整合平台(P1)支持受理外部客户使用不同终端设备、不同客户端的业务请求. P1屏蔽终端设备和请求协议的差异, 统一封装不同的渠道业务数据, 并将结果数据和渠道展示特性进行适配转换,返回终端设备及客户端. P1平台可提供多种展现格式,支持多种界面语言. 可提供客户安全认证功能、渠道交易限额、交易流量限制功能.

P1平台支持的渠道范围包括: 网上银行、手机银行、电话银行、短信、电话、智能终端(手机、平板电脑)、ATM、POS、排队机、互联网网站、电子商务网站及第三方渠道设备等. 平台的整体设计如图5所示.

P1平台支持C/S和B/S模式. 平台使用框架中的控制驱动组件、功能处理组件及基础技术组件来完成P1的功能.

4.3 内部客户渠道整合平台(P2)

P2平台为内部员工提供统一的操作门户, 支持员工使用不同终端设备的业务请求.

P2平台整合已有高柜、低柜系统, 提供客户端和网页两种展现模式. 客户端模式针对要求交易高效操作、快速响应的场景, 网页模式针对管理类、流程类等时效性要求不高的场景. 两种模式的界面都在平台客户端框架内. 平台提供前端界面和后端业务处理的参数化配置开发能力, 可快速发布新产品. 客户端可通过检查版本服务器的发布版本完成自动更新操作. P2还可根据操作员权限动态展示可操作菜单, 拒绝无权限的交易发起请求.

P1、P2平台均包含客户端及服务端, 客户端负责处理界面展现、校验、流控、外设接入适配、版本管理等功能; 服务端完成后端业务调用及处理、加解密、资源调度等功能.

图6 内部客户渠道整合平台整体设计

P2平台的整体设计如图6所示. 服务端功能由框架提供的公共组件以及平台实现的功能组件共同完成. P2平台提供的功能与P1平台相似, 区别主要在于P2平台底层的技术框架是JAVA框架.

4.4 客户服务整合平台(P3)

银行业务存在需要多人审核、会签的场景, 一般出现在对公业务流程中. 同样的需求也存在于企业客户. 现状中, 由于每个业务系统相对独立, 流程的管控和实现在各业务系统中实现, 功能重复开发且设计不统一. 针对以上情况, 流程被重新定义和设计, 在客户服务整合平台上实现.

P3平台整合端到端的客户服务流程、为渠道提供集成的服务. 平台提供面向内外部用户跨角色、跨时序、可中断的流程编排服务.

P3平台的核心是工作流引擎, 平台基于JAVA框架开发, 可提供业务流程灵活定制与编排服务. 服务配置为可视化操作, 并可动态增加流程角色、组织结构、流程路由、流程节点等要素. 工作流引擎的整体功能如图7所示.

图7 工作流引擎

根据实际业务需求, 流程可预先定义, 或由客户通过流程模板定制, 创建流程时可自定义流程规则. P3平台提供通用的流程管理、任务管理服务, 提供流程执行中的选人模式管理服务.

P3平台采用流程与服务分离的设计, 流程的执行与服务为松耦合关系.

P3平台提供基于事件的调度管理, 支持事件触发服务.

4.5 应用集成平台(P4、P5)

应用集成平台分为内联(P4)及外联(P5)平台, 其存在形式为企业级服务总线(ESB). 应用集成平台提供通讯连接、报文转换、集成适配、路由交换、服务分类调度管理、服务组合等集成功能.

产品服务层的服务注册并发布在P4服务目录中,以供内外部系统使用.

内联服务平台(P4)主要为客户服务整合层及渠道整合层(其他层)提供标准化的服务调用功能.

外联集成平台(P5)提供与外部金融和非金融机构系统间的服务交互.

4.6 产品服务平台

产品服务层作为企业级视角的产品服务的提供方,支持银行集团产品、客户、合约等核心业务服务.

产品服务平台采用相同的架构设计, 由基础框架开发而来. 目前设计三个产品服务平台, 主要在开发语言上有所区分.

产品服务平台的整体架构设计如图8所示.

图8 产品服务平台架构设计

产品服务平台具备如下能力:

① 联机服务处理能力: 能够处理P4发过来的联机服务请求.

② 批量服务处理能力: 为平台产品服务层提供公用的批量任务处理的机制.

③ 构件组合能力: 提供通过配置方式将多个原子构件服务组合成新的构件服务.

④ 冲正: 提供本地超时和后端系统超时后的同步或异步冲正功能, 发布统一的冲正服务, 在接受到前端冲正请求时能追溯正交易过程.

⑤ 公共业务处理: 为平台上的业务应用组件提供公共的业务处理构件, 可提供联机服务前处理、后处理服务.

⑥ 数据同步: 将平台上业务应用组件管理和维护的数据同步给数据集成平台.

⑦ 文件传输: 支持跨平台的文件传输能力.

4.6.1 产品服务主机平台(P6)

产品服务平台P6构建在主机系统, 基于COBOL语言实现.

P6平台支持快速产品创新和部署的能力, 支撑灵活的定价, 并能提供银行集团统一的客户视图. 支持跨系统平台、数据库、中间件、操作系统部署的能力.支持同构平台内构件或模块的注册或调用的能力.

4.6.2 产品服务C平台(P7)

产品服务C平台(P7)基于TP MONITOR和C语言实现, 利用基础技术C框架, 以配置化的方法实现业务应用组件交易服务的内部构件串接和驱动. 与P6相似, P7也具备支持产品创新、灵活部署、联机处理与批处理等能力.

4.6.3 产品服务J2EE平台(P8)

产品服务J2EE平台(P8)依赖于J2EE基础技术框架. 在“新一代”7层架构中, 与P6、P7一样处于产品服务层. P8平台提供批量调度服务, 采用基础数据变化捕获工具和文件传输工具, 以准实时或定时批量模式将业务数据以增量或全量的方式同步到P9平台.

P8平台针对未来产品服务类应用组件的交易过程、异常处理等基础业务能力需求进行了整体性设计,提供公用的流水记录、冲正等平台组件来尽量减少未来业务应用组件的开发难度.

4.7 数据集成平台(P9)

数据集成平台(P9)提供支持管理分析层实现的统一数据存储与交换, 支持管理分析层与产品服务层之间的批量数据交换, 支持产品服务平台和管理分析平台应用访问的技术服务.

P9平台支持的应用访问技术服务包括: 信息管理、信息集成组件、ETL、信息交换、资源供给服务(基础架构服务)、业务可用性(通用服务)、目录服务(应用集成服务)、信息访问(数据部署)、信息索引(数据部署).整体设计如图9所示.

P9平台具有海量数据存储能力、数据按主题归类能力、大数据量分区能力、大批量处理的计算能力、数据质量的控制能力、高并发处理能力、报表数据存储能力、非结构化数据管理能力.

P9平台采用大规模并行处理(MPP)数据库技术、

HADOOP分布式计算技术、数据的对象管理和存储技术, 实现海量数据加载、处理和分级存储. 利用自有核心技术构建10万任务级复杂数据处理的技术框架, 实现可配置、易监控、扩展性强的集群调度模式, 组件化对外服务.

图9 数据集成平台整体设计

4.8 管理分析服务平台(P10)

管理分析服务平台(P10)提供银行内部管理和决策所需的所有管理分析类格式化展现和分析应用, 同时支持面向外部客户的固定格式报表和灵活定制报表.

P10平台总体框架上下文关系如图10所示. 图中D2表示管理分析服务平台与数据集成平台的关系, C1表示可通过页面链接的方式访问P10交互界面.

图10 管理分析服务平台总体框架上下文关系

P10平台支持业务领域管理人员自行定制和发布数据业务. 可基于选定的数据项集合自行定制数据展现格式, 自行决定是否发布给其他用户使用. 支持技术人员在业务人员工作的基础上进行调优, 提供商业智能组件, 包括报表、仪表盘、多维分析、预测分析、假设分析和数据挖掘.

P10平台采用HTML5技术, 增强用户体验. 采用互联网搜索引擎, 构建银行集团数据索引, 方便业务用户直接使用数据. 采用X86云部署技术, 保障运行的高可靠性、高可用和可管理性.

4.9 事务控制服务平台(P11)

事务控制平台主要用于高效行政相关系统, 包括电子邮件和办公自动化等.

4.10 在线交易数据服务平台(P12)

在线交易数据服务平台(P12)为在线交易提供运营决策服务和信息访问服务. 支持基于历史数据的实时计算和查询, 具备灵活的规则定制和高效的数据访问能力. 支撑管理分析层的反欺诈、反洗钱、监管合规、稽核监测、风险管理等应用组件.

P12平台支撑的应用模式如图11所示.

图11 在线交易数据服务平台支撑的应用模式

P12平台可按照预定义的业务规则, 基于历史数据进行计算处理, 为在线交易实时返回计算结果. 其中规则定制支持在线调整和发布, 支持信息访问. 即对数据集成层处理结果的快速查询, 或者基于数据集成层的数据进行信息聚合, 并返回查询结果.

P12平台采用规则引擎技术和分布式缓存技术,分别支撑运营决策能力和信息访问能力. 采用规则引擎技术实现规则的集中管理、规则在线调整和发布;采用分布式缓存技术对读多写少的数据进行缓存, 以提升数据访问效率, 并减少对数据集成层的压力.

5 面向云服务的基础设施建设与灾备体系

基础设施与治理层是“新一代”7+1层架构中的1层, 是应用组件运行的基础环境. 在实施“新一代”建设的过程中, 设计了基于云计算技术的基础设施体系,初步建成云计算数据中心及运维体系.

灾备对于保障银行业务连续性至关重要. 按照《IT灾备体系规划项目》的目标, 确定了以“两地三中心”为核心的IT灾备体系[7]. 以云计算数据中心架构设计为依托, 构建形成“新一代”IT灾备体系.

5.1 企业级云数据中心模型

云数据中心的基础设施及服务层涉及网络、存储、计算、安全、运维管理等技术组件, 其总体技术架构如图12所示.

图12 云数据中心技术架构逻辑模型

新的技术架构融入了云计算的构建思想和元素,将整个数据中心的基础资源和运维管理分为基础设施资源层、通用服务层、基础设施服务目录层、基础设施服务层、前端层和统一管理层. 服务目录层是将网络、存储、计算以及各种技术组件通过标准化过程抽象成不同的云服务, 然后再通过云管理平台进行调度和管理[8].

经过前期的规划设计, 共梳理出31个技术组件和28个云服务. 不仅涉及网络、存储、计算等基础资源,还涉及云管理、监控、运维流程、配置管理等IT服务管理. 这些技术组件及技术架构为云计算数据中心的逐步完善奠定了基础.

5.2 核心网络架构

目前各数据中心(DC)、开发中心、分行、业务中心及子公司、海外机构等通过核心网完成银行集团网络的集中接入. 核心网整体采用层次化的架构, 分为核心层、分布层、接入层. 核心网节点内部采用模块化设计, 由位于核心层的核心节点, 以及位于分布层的DC接入区和WAN接入区组成, 可用性高, 架构灵活. 核心网是“两地三中心”灾备方案的基础, 其整体结构如图13所示.

核心层实现核心层节点之间高速互联, 数据流可以根据业务的需要, 不受实际连接的限制而灵活高速地传输. 分布层提供各个网络单元的接入, 分为WAN和DC两个接入区, 用于隔离失效域, 提升可用性. 接入网为各个网络接入单元. 如数据中心、业务中心、开发测试中心、分行等.

图13 核心网结构图

原则上, 开发中心、业务中心均连到WAN接入区,各数据中心只连到DC接入区. 从接入的密度和可管理性角度考虑, 在目前的负载情况下, WAN区作为一个集成的接入区, 不考虑分区方案. 未来接入密度出现瓶颈时, 可将WAN接入区分为多个区域.

5.3 “两地三中心”灾备方案

“两地三中心”方案要求在同城建立两个数据中心作为同城备份, 在异地建立灾备中心, 当两个生产数据中心均不可用时, 生产系统切换至异地灾备中心.目前, “新一代”建立两个数据中心及一个灾备中心, 各中心的主要职责如下:

①A1数据中心: 作为主要系统的生产中心, 也是运维控制中心. 部署交易类生产系统及部分开发/测试集成环境, 部署渠道接入系统. 同时也是管理分析类系统的异地灾备.

②A2数据中心: 作为A1数据中心的同城备份,实时备份生产数据, 同时部署渠道接入系统.

③ B数据中心: 作为主要系统的灾备中心. 部署准生产版本验证测试环境. 部署部分渠道接入系统、管理信息系统, 是历史数据存储的生产中心.

各平台在三个中心有如下几种部署模式:

Active: 在Active模式下平台及应用组件对外提供服务, 允许更新各类业务数据, 为主要运行模式.当Active模式的实例发生故障时, 服务将由同城的Query模式部署实例提供.

Query: 运行在Active模式下的平台及应用组件以准实时(约20毫秒延迟)的方式将数据同步到同城数据中心. Query模式下, 平台及组件仅对外提供非强实时性要求的查询类交易. 对于要求实时数据的查询类交易, 依然由Active部署模式的数据中心提供服务.

Standby: 在Standby模式下的平台及组件主要作为灾难恢复所用, 为异地数据中心, 其数据延迟在分钟级. 当Active及Query模式下的服务均不可用时, 将切换至Standby模式下的部署实例.

由于各平台的应用模式不同, 其部署模式也不相同, 12P的灾备部署模式如图14所示. P1至P5平台主要负责接入功能, 采取三地生产中心(A-A-A)的部署模式. 产品层P6至P8平台为生产-查询-灾备(A-Q-S)部署模式, A1数据中心为主要生产中心. P9至P12平台为生产-灾备(A-S)模式, B数据中心为其生产中心.

图14 各应用平台灾备模式

从图14可知, 各平台从Active模式向Query及Standby模式传输数据. 产品系统产生的业务数据传输至P9的生产部署, 进而被P10至P12平台使用. 查询请求经P4平台接入P6至P8平台的Query部署模式实例. 业务流通过P1、P2、P5平台接入.

6 结论

“新一代”核心系统建设从业务建模入手, 运用业界领先的建模语言和工具, 全面梳理了银行集团的业务流程、产品和数据现状, 通过差距分析, 绘制了企业级的目标业务架构蓝图. 基于分层和SOA组件化的设计思想, 完成了从业务架构蓝图到7+1层、12个平台的IT系统架构的映射. 基本建成了组件化、平台化、面向服务的“新一代”核心系统架构. “两地三中心”、双活和主备结合的灾备体系为IT系统安全稳定运行打下了坚实的基础, 为业务连续性提供了保障.

“新一代”建设成效显著. 主要表现在: 产品快速推向市场能力显著增强, “快贷”和“速赢”等产品的推出时间由数月缩短为数周; 系统吞吐量和稳定性稳步提高, 2015年天猫双“十一”, 交易额占支付宝总交易额23.6%, 处于同业第一; 系统运行平稳, 关键系统可用率近几年一直保持在99.99%以上; 新版互联网站、网上银行和手机银行陆续推出, 不断提高用户体验;基于云计算的IT基础设施交付能力显著提高, IT资源供给周期从“周”缩短到“分钟”.

通过“新一代”建设, 已经建立起“一套业务模型、一套IT架构、一套实施工艺、一套管理流程”的企业级IT长效机制, 增强了自主研发能力, 形成集中统一的IT研发模式, 建立起以支持引领、自主研发和安全运营为核心的IT能力, 为实现“国内最佳、国际一流”的发展愿景提供支持和保障.

致谢: 感谢常江涛先生在“新一代”建设项目中做出的杰出贡献. 感谢他为本论文贡献的专业洞见和理论总结. 感谢他的家人对他的大力支持和无私奉献.

1 TOGAF. http://www.opengroup.org/subjectareas/enterprise/ togaf.

2 IBM Software Group. FSDM金融服务数据模型, 2005.

3 金磐石.构建“安全即服务”的安全架构.中国金融电脑, 2014,(12):23–25.

4 金磐石.“产、用”战略联动 推进信息化自主可控进程.金融电子化,2014,(8):28–29.

5 金磐石.科学构建灾备保障体系.金融电子化,2013,(1): 23–23.

6 金磐石.用IT审计管控信息科技风险.金融电子化,2011, (12):28–29.

7 中国建设银行.北京数据中心稻香湖新址规划建设情况报告,2014,(11):18–20.

8 金磐石.建设银行云计算数据中心及运维体系建设实践探讨.中国金融电脑,2014,(7):18–22.

SOA-Based New Generation Banking System Architecture for Banking Group

JIN Pan-Shi, ZHU Yu-Hong, HU Xian-Zhong, LI Xiao
(IT Management Department, China Construction Bank, Beijing 100140, China)

Large commercial banking group encounters many problems in the process of informatization, such as large number of internal systems, existence of many non-uniform platforms, low usage of resources and high cost, long cycle of demand response and other defects. With the rapid growth of China’s banking industry, commercial banking group’s system architecture innovation is imperative. This article focuses on the SOA-based framework and component-based design method which are employed in the construction of the new generation banking system. By 7+1 levels and 12P overall framework design, we ensure the application components loosely coupled and uniform the domestic and overseas application to realize the enterprise-wide integration of resources and quick response to business requirements. Accordingly, we achieve the purpose of enhancing the service reliability and availability. We introduce in enterprise level business model to standardize our business process and use structured modelling language to describe our business capability. We use process model, product model, data model and user experience model to provide methods and basis for enterprise level analysis and design.

SOA; commercial banking system; 7+1 level; 12P; enterprise-level business model

2016-03-23;收到修改稿时间:2016-05-30

10.15888/j.cnki.csa.005542