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