商业银行支付系统技术总体方案

1 第二代支付系统 技术总体方案简介 中国人民银行清算总中心 张清明 2010年 10月 2 第一代支付系统在技术上的主要特点（一） 分步建设 先建设了清算账户管理系统和大额支付系统，再逐步建设了小额支付系统、支付管理信息系统等应用系统； 作为第二代支付系统应用系统之一，先行建设了 IBPS。 混合结构 账户管理系统：核心数据和核心应用部署在主机；辅助数据和主要业务逻辑部署在开发系统； 大额、小额：数据和应用部署在开放系统； 管理信息系统：数据和应用部署在开放系统 高可靠性保障 主机：冷备份（ Active/Cold Stanby） NPC 开放数据库服务器：群集模式（ Active/Active） NPC/CCPC 开放应用服务器：热备模式（ Active/Warm Stanby） NPC/CCPC 报文标准 CMT/PKG 3 第一代支付系统在技术上的主要特点（二） 参与者适当集中接入 参与者主要以省级分行作为直接参与者接入当地城市处理中心； 部分参与者（如国债、银联、 TCBS）通过 NPCFE一点接入 NPC。 一定的备份等级水平 逐步建设完善了应急备份系统，实现了 NPC站点备份； 主要应用系统备份水平达到 Tier 5 （ RPO1分钟， RTO2小时）； 建设了 XCCPC，能实施对特定 CCPC数据实时备份； 部分 CCPC建设了同城备份系统。 一定的监控和运维管理水平 在 NPC/CCPC部署了 CA监控系统，能监控部分系统软件和硬件。 实现了应用软件自主开发，逐步建立了客户服务和技术支持体系。 4 第一代支付系统在技术上存在的主要不足 分布实施，总体架构设计不够； 数据及应用在 NPC和 CCPC的分布不尽合理； 应用系统耦合程度较高，不能快速响应业务需求的变化； 缺少先进完善的灾难备份系统； 缺乏应用监控手段； 系统接入方式不够灵活； 报文标准未采用国际标准。 5 信息化技术发展趋势 金融业务系统发展趋势 重视系统架构设计，提倡面向服务的系统架构； 注重应用系统整合及信息共享； 数据及核心应用逐步集中； 加强系统备份能力建设，保障业务连续性； 使用开放的国际标准、国内标准和行业标准； 采取纵深防御的策略，按等级保护要求强化信息系统安全； 提升系统的可扩展性和可维护性，改进运维管理； 注重数据分析和信息挖掘。 6 第二代支付系统需求概述：总体需求 第二代支付系统应在支持已有业务类型的同时，主动适应支付业务的创新和发展，使系统未来能以较小的代价快速适应业务需求的变更以及发展。 大 额 支 付 系 统清 算 账 户 管 理 系 统（ 账 户 管 理 、 实 时 清 算 、 净 额 清 算 ）支 付 管 理 信 息 系 统小 额 支 付 系 统支 票 影 像 交 换 系 统网 上 支 付跨 行 清 算 系 统本次不改造 7 第二代支付系统需求概述：非功能性需求 业务容量需求 HVPS： 2016年日均 446万笔，峰值 128万笔 /小时 BEPS： 2016年日均 1148万笔，峰值 242万笔 /小时 约合 328万包 /日，峰值业务量为 82万包 /小时 IBPS： 2011年日均 300万笔，峰值 75万笔 /小时 合计的峰值轧差处理需求为 157万次 /小时 小额按包进行轧差处理、网银按笔进行轧差处理 可靠性要求 系统的可使用率应保持在总运行时间的 99.9%，故障平均修复时间不超过 20分钟。 8 第二代支付系统需求概述：运维需求 系统运维需求 建立和应用系统有机整合的运行监控系统 建立符合信息化系统管理规范的运行维护系统 建立先进的客户服务系统 9 第二代支付系统需求概述：系统切换要求 第二代支付系统采取“支付系统统一切换、各参与者分步切换”的上线方案，系统在功能上可兼容第一代支付系统的报文标准。 在第二代支付系统上线当日，国家处理中心（ NPC）及各 CCPC切换到第二代支付系统，同时停止第一代支付系统的运行。 已完成二代系统接口改造的参与者可通过新版接口接入第二代支付系统； 未完成二代系统接口改造的参与者可通过原接口程序接入第二代支付系统，待完成系统改造后再通过新版接口接入第二代支付系统。 人民银行根据管理需要设置统一的切换期。 10 第二代支付系统需求概述：主要变化 与一代系统的主要变化 更全面的流动性风险管理功能 支持新兴电子支付 灵活的接入和清算模式 人民币外币的 PVP 支持人民币跨境支付 业务标准与报文格式 支付信息管理 11 建设目标和原则：总体目标 立足第一代支付系统的成功经验，引入先进的支付清算管理理念和技术，满足业务需求，解决原系统中存在的突出问题，进一步丰富系统功能，加强运行监控，完善灾备系统，建设适应新兴电子支付发展的、面向参与者管理需要的、功能更完善、架构更合理、技术更先进、管理更简便，以上海中心建设为起点，以北京中心投产为建成的新一代支付系统。 12 建设目标和原则：基本原则 要有利于高标准履行职责，确保支付系统安全稳定运行 建设风险可控：要充分吸收一代支付系统的成功经验；要确保所选择的技术必须是成熟可靠且有发展前景的，并在国内外类似的关键业务系统中得到了成功应用； 体现二代支付系统的先进性：要优化系统架构，完善系统功能，改进运维管理，方便运行维护，提高处理效率；要结合未来几年的技术业务发展趋势，具有一定的前瞻性，适应未来支付清算业务发展和创新需求； 统筹规划：要通过借鉴吸收其他系统建设经验，统盘考虑各应用系统的备份系统建设，避免资源浪费。 13 建设目标和原则：方案设计原则 1. 满足业务需求 2. 系统平滑过渡 3. 提升系统安全性 4. 提升系统整体可用性 5. 灵活可扩展的应用架构 6. 提升系统可维护性 7. 灵活多样的接入方式 8. 国际化的业务标准 14 应用系统设计：设计思路 设计思路： 集中化、平台化、组件化、标准化 以支付报文传输系统为支撑，支付业务处理系统为核心 遵循原则： 采用面向服务的架构的理念和技术 业务流程化原则 模块可重用原则 子系统松耦合原则 子系统内聚性原则 15 应用系统设计：支付业务处理 子系统划分： 综合安全性、应用组件功能相似性、子系统内聚性、独立性等因素，将应用组件划分为 10个子系统。 支付业务处理子系统（大额，小额，网银）； 支付账务处理子系统； 公共管理子系统； 计费子系统； 统一用户认证授权子系统； 明细查询与数据管理子系统； 监控子系统； 统计分析子系统； 行名行号子系统； 参与者业务管理子系统。 16 应用系统设计：总体结构 C N A P S 2A C S商 业 银 行T C B S银 联清 算 组 织国 债支 付 报 文 传 输 平 台C F X P SE C D S大 额 支 付 系 统小 额 支 付 系 统网 上 支 付 跨 行 清 算 系 统清 算 账 户 管 理 系 统公 共 管 理 系 统. . . . . .报文传输与业务处理分离 17 应用系统设计：支付报文传输 业务功能： 传输安全 报文校验 智能路由 主要特性 ： 与业务系统无关 兼容多种报文格式 高可用性 18 应用系统设计：支付报文传输部署 集中交换网关 支持水平扩展方式部署，单台服务器宕机不会影响到报文传输平台的连续运行 对经过的报文同时进行本地和异地集中存储，确保灾难情况下支付报文传输平台业务数据的完整性 区域接入网关 区域汇聚、安全检查 智能路由和报文转发 支持水平扩展方式部署 参与者接入端 负责接收商业银行行内系统向支付报文传输平台提交的各类报文 负责接收区域接入网关向本接入点发送的报文，并转发至参与者行内系统 支持采用水平群集方式部署，同一接入点的报文传输平台接入服务器可并行工作，单台服务器失效，不影响该接入点其它服务器的继续运行 支持 AIX和 Linux操作系统， MQ与 TLQ中间件 19 应用系统设计：应用功能分布 国家处理中心 NPC 支付业务处理子系统（大额，小额，网银） 支付账务处理子系统 公共管理子系统 统一用户认证授权子系统 计费子系统 明细查询与数据管理子系统 监控子系统 统计分析子系统 行名行号子系统 集中交换网关子系统 城市处理中心 CCPC 区域接入网关子系统 参与者业务管理子系统（根据实际需要） 支付系统参与者 参与者接入端软件 参与者业务管理子系统（间联参与者） 20 应用系统设计：与一代支付系统的主要变化 实现报文传输和业务处理分离： 方便参与者的灵活接入； 简化业务系统的处理逻辑； 业务处理划分为业务处理子系统（含大额、小额、网银）和账务处理子系统： 层次清晰，提高系统整体处理效率； 建立统一的业务管理和业务监控平台： 为支付系统的业务人员提供单一入口，通过用户身份认证后按各自授权分别操作、监控和管理各业务系统； 增加应用监控子系统： 可随时了解系统运行情况，提前发现系统故障或异常，有助于提高运维水平； 改进对参与者的支持： 通过报文传输平台可支持参与者的灵活接入需求，降低前置机复杂度和维护难度； 建设参与者业务管理系统，支持中小参与者特别是农村金融机构的低成本接入、业务收发和业务管理。 21 数据管理设计：设计思路 按数据重要性进行区别存储和保护，关键数据应集中在 NPC； 满足业务处理性能的要求； 注重数据的完整性、一致性和可用性，统一数据的定义、变更等管理； 建立有效的数据备份和归档机制。 22 数据管理设计：字符集与数据编码 为更好的适应国际标准，并适应第二代支付系统的国际化趋势，第二代支付系统数据交换和存储格式统一采用 UTF-8编码集。 UTF-8是 Unicode的一种最常用的变长字符编码，可以根据不同的符号自动选择编码的长短。在 UTF 8中，字符以 8位序列来编码，用一个或几个字节来表示一个字符。 UTF-8编码集包含全世界所有国家需要用到的字符，字符集大；同时是国际通行的编码方式，得到了几乎所有系统软件的支持，通用性强。 UTF-8编码的文字可以在各国支持 UTF8字符集的浏览器上显示，而无需下载IE的中文语言支持包。 23 数据管理设计：数据交换 查询库 联机交易数据库的实时数据镜像库； 方便对在线数据实施查询、统计、分析以及采集、监控等功能； 简化各个子系统之间的数据关系； 减少重要业务系统对数据库的压力。 主要的数据交换方式： 准实时数据复制 准实时数据采集 联机报文类数据交换 批量处理类数据交换 参数数据交换 24 数据管理设计：数据归档与检索 各业务系统中将超过联机数据保存期的数据按照规定的接口要求导出为 XML格式的文件，通过网络将归档文件送给归档与检索系统，归档系统对归档数据进行分级存储，建立索引支持检索。 归档数据保存期为 15年，归档系统应支持数据的分级存储功能， 5年内的数据保存在联机存储上，超出 5年的数据自动迁移到低速率的存储介质上，以降低存储成本 。 序号 数据类型 归档需求 备注 1 业务数据 归档子系统 +数据异地存储 2 报文数据 归档子系统 +数据异地存储 25 数据管理设计：与一代支付系统的主要变化 建立查询库 减少业务管理、查询、监测、统计等对交易系统的影响； 建立统一的数据归档和检索平台 为今后支付信息的再加工和再利用提供基础设施和技术条件 字符集、数据编码和报文标准 支持国际标准 数据集中在 NPC 26 计算机方案：混合平台方案 基本思路 借鉴一代支付系统的成功经验，根据应用系统设计和数据分布设计的结果，通过区分计算资源，将联机交易系统的核心处理逻辑（例如轧差、记账）、关键业务数据（包括清算账户信息，参与者交换的报文信息等）部署在主机平台，而将计算复杂且对 CPU资源消耗过高的处理逻辑，例如 XML报文的解析、业务流程的控制、业务数据核对等逻辑部署在开放平台，实现联机交易系统数据集中、应用分布的混合平台架构。统计分析等子系统的应用和数据均部署在开放平台。 在实现上遵循以下原则： （ 1）联机交易系统依赖的业务数据集中存储在主机平台。 （ 2）所有对主机平台数据库的更改操作应通过主机核心应用服务完成，分布式平台业务系统通过 SNA或 IPIC以一阶段方式访问主机上对应的子系统核心服务完成数据更新操作。 （ 3）开放平台可通过数据库客户端访问主机数据，但仅限于只读操作 。 27 NPC逻辑部署：总体结构 主机平台核心服务层 主机上的账务业务处理子系统和各业务处理核心服务层均选择基于成熟的 CICS事务管理器和 DB2 数据库，维护和管理各自的业务数据 主机平台上存储 SAPS账务数据、特殊业务数据、小额业务数据、网银业务数据、大额业务数据、公共管理（含计费）数据； 主机上的数据采用准实时数据复制技术将数据复制到开放系统存储的查询库中，以避免管理客户端、业务监控、应用监控等对主机业务数据查询带来的压力 开发平台业务处理层 访问主机核心服务 为继承现有资产，可部署 CICS 事务管理器和 WMQ来保障应用逻辑内部数据的一致性和完整性。 计算机方案：混合平台方案 28 计算机方案：混合平台方案 MBFE物理部署 ： 直连参与者 参 与 者业 务 系 统 2报 文 传 输参 与 者 接 入 端服 务 器 B报 文 传 输参 与 者 接 入 端服 务 器 A管 理 客 户 端L A N查 询 客 户 端参 与 者业 务 系 统 N参 与 者业 务 系 统 1密 押 服 务 器签 名 服 务 器29 计算机方案：混合平台方案 MBFE物理部署 ： 间连参与者 间 连 M B F E数 据 库 服 务 器支 付 报 文 传 输 平 台参 与 者 接 入 端 服 务 器管 理 客 户 端L A N查 询 客 户 端间 连 M B F E应 用 服 务 器可 合 并 部 署密 押 服 务 器签 名 服 务 器30 选择混合结构的考虑 充分利用大型主机的高安全性，将关键业务逻辑部署在主机平台，只有经过主机应用才能修改（增删改）关键业务数据； 充分利用 IBM大型主机的成熟技术，尽最大限度提高支付系统核心业务系统的高可用性。基于大型主机实施的GDPS/Hyperswap等技术使系统可用性可达到 99.999%以上，保证无论是单台主机还是单台存储出现故障时，业务连续性均可以得到很好的保证。目前全球各大银行的关键业务系统大多数都运行在主机平台；国内四大商业银行目前都已采用该技术保障其核心系统的高可用性。 一代支付系统就是采用的混合结构，积累了相应的软件开发、工程实施以及运行维护的经验；二代支付系统继续沿用这一结构（在细节方面加以优化），风险相对可控。 与在主机上部署全部应用功能相比，采用混合结构能较大程度降低建设运维成本和软件开发难度。 31 计算机方案：与一代支付系统的主要变化 总体技术路线和一代支付系统基本一致： 关键业务系统拟继续采用主机 /开发系统的混合结构 辅助信息系统全部使用开发系统 继续采用一代中表现稳定并积累了丰富开发运行管理经验的相关技术和软硬件产品。 调整数据分布和应用分布： 关键业务数据全部存放在主机 只允许主机应用访问这些数据 改进数据交换方式： 通过交易数据镜像库简化子系统之间的数据交互 32 计算机方案：与一代支付系统的主要变化 全面增强系统的可用性： 主要通过采取群集负载均衡，尽量少采用主备模式； 具体包括主机上采用并行耦合技术 报文传输平台自行研发双机 /多机并行技术并实现自动选择传输路径等 改进系统的可扩展性： 纵向可扩展和水平可扩展； 通过群集技术可以方便的增加服务器来提升系统的处理能力； 提升系统的可维护性： 建立集中监控系统，快速发现和定位问题； 提供应用监测手段并与运维管理系统集成；提供系统的维护窗口和维护手段等 33 网络方案：与一代支付系统的主要变化 按照信息安全等级保护的相关要求，采用安全域的概念，按照不同的功能分区划分安全域，不同的安全域采用不同等级的防护策略； 支持多中心同时在线，多中心之间建立高速通道，支持互相访问； 提供多种网络管理手段。 34 第二代支付系统信息安全保障体系 35 安全方案：与一代支付系统的主要变化 强化数据传输安全，在传输平台中实现对数据完整性的检查； 用户集中管理，建设统一的用户认证和授权子系统，实现用户身份认证、访问控制以及用户操作的安全审计； 建立网络安全体系，建设安全域边界、网络边界；重点保护 CCPC与参与者之间的边界，对接入支付系统进行更为严格的控制，确保支付系统边界的完整性； 注重安全管理，安全审计等，搭建相应的平台。 36 运维管理 ：设计思路 多中心一体化”的运维管理 一体化的监控 一体化的运行 一体化的维护管理 一体化的服务支持 运维监控中心与数据中心分离 数据集中与分级管理相适应 具备良好的可扩展性和可用性 37 运维管理：与一代支付系统的主要变化 运维管理 从未来将形成多中心的格局和提高运维管理和业务连续性管理水平的角度考虑，运维监控系统的建设依照“多中心一体化（多个物理中心协同形成一个大的逻辑中心）”的思路进行设计，支持一体化的监控、运行、维护等； 支持运维中心和数据中心分离；严格数据中心的管理，只允许系统维护人员进入核心运行区，运维监控的支持、管理和操作人员通过远程、甚至异地访问和监控系统运行，并执行运维管理流程的各项工作支持分级运维； 增加应用监控等运维功能，提供客户服务、技术论坛及服务支持网站等，改进对清算中心和参与者的技术支持 38 第二代支付系统备份系统建设路径 上海中心投产时的备份系统建设 第二代支付系统在上海中心投产时，支付系统北京中心尚未建成，为确保支付系统的备份能力，应以上海中心作为生产中心，无锡主站作为应急备份中心。 北 京 中 心（ 建 设 中 . . .）北 京 主 站（ 改 造 中 . . .）无 锡 主 站应 急 备 份 中 心异 步 传 输上 海 中 心生 产 中 心39 第二代支付系统备份系统建设路径 北京中心建成后的备份系统建设目标 将生产中心从上海中心切换到北京中心，从而形成北京中心作为生产中心、北京主站作为同城备份中心和上海中心作为远程备份中心的“两地三中心”最终格局。 北 京 中 心生 产 中 心北 京 主 站同 城 备 份 中 心同 步 传 输异 步 传 输上 海 中 心远 程 备 份 中 心40 备份系统建设方案 两地三中心方案 主机平台数据备份方案 同 步 P P R CF I C O N 交换 机业 务 处 理 子 系 统 x n账 务 处 理 子 系统 x 2主 磁 盘阵 列磁 盘 阵列F I C O N交 换 机S A 交 换机S A N 交 换机 生 产 中 心 同 城 备 份 中 心公 共 管 理 子 系 统 x n以 太 网 交换 机业 务 处 理 子 系 统 x n账 务 处 理 子 系统 x 2公 共 管 理 子 系 统 x n以 太 网 交换 机磁 盘 阵列F I C O N交 换 机S A N 交 换机 远 程 备 份 中 心业 务 处 理 子 系 统 x n账 务 处 理 子 系统 x 2公 共 管 理 子 系 统 x n以 太 网 交换 机异 步 P P R C41 备份系统建设方案 两地三中心方案 开放平台数据备份方案 磁 盘 阵 列同 步 P P R C其 他 子 系 统 x n统 计 分 析 子 系 统 x 2统 计 分 析 子 系 统 x 2 其 他 子 系 统 x n生 产 中 心同 城 备 份 中 心磁 盘 阵 列统 计 分 析 子 系 统 x 2其 他 子 系 统 x n远 程 备 份 中 心异 步 P P R C磁 盘 阵 列S A N 交 换 机S A N 交 换 机S A N 交 换 机42 备份系统建设方案： CCPC备份 系统备份 M B F E 接 入 端 A区 域 网 关 A故 障区 域 网 关 B故 障C C P C 1接 入 服 务 器 A 接 入 服 务 器 BN P C故 障故 障M B F E 接 入 端 B区 域 网 关 A 区 域 网 关 BC C P C 2参 与 者43 备份系统建设方案： CCPC备份 数据备份 为实现 CCPC集中备份系统， CCPC日常需将支付报文传输平台 CCPC区域网关处理软件与辖内参与者接入端软件之间配置信息定时（例如每日日终后）通过报文传递至 NPC， NPC集中存储各 CCPC与辖内参与者中间件连接方式等系统配置信息，在 CCPC发生灾难时导入 CCPC集中备份系统，保证参与者正常接入。 44 备份系统建设方案： MBFE备份 二代支付系统直连参与者 MBFE仅部署支付报文传输平台接入端软件 支持水平扩展方式部署，参与者可通过多台 MBFE同时向支付系统发送业务 一台 MBFE的故障不会影响到参与者的业务连续运行 MBFE备份 主用 MBFE与备用 MBFE 为防范单个 NPC/CCPC故障导致从其接入的 MBFE业务受到影响， 参与者 可 选择主备 MBFE分别接入主备 NPC/CCPC的模式 ； 主用 MBFE（可以多台）与主用 NPC/CCPC接入，正常情况下所有业务从该组 MBFE进行收发； 备用 MBFE与备用 NPC/CCPC建立连接，在主用 NPC/CCPC出现故障时，改从备用 MBFE进行报文收发。 45 备份系统建设方案： MBFE备份 MBFE备份 一般而言，主用线路接入 NPC的参与者，备用线路宜选择接入备用 NPC； 对于主用线路从 CCPC接入的全国性商业银行，则可选择从其备用数据中心所在地 CCPC作为备用接入； 对于区域性的城市商业银行或农村信用社，也可以根据自身实际情况来选择是否建立备用接入线路，确有需要的，可以选择从人民银行当地的同城转接中心建立备用接入线路 46 备份系统：与一代支付系统的主要变化 业务连续性 NPC数据备份需求简单，相关业务数据全部位于主机平台，所采用的备份技术相对单一，降低了系统复杂度； 通过应用方式在异地备份了全部报文数据，实现了报文数据零丢失，方便非计划切换情况下的数据查找和恢