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

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