CNAPS 第二代支付系统技术方案介绍.ppt

CNAPSCNAPS1第二代支付系统第二代支付系统技术方案介绍技术方案介绍中国人民银行清算总中心2011年8月2第二代支付系统需求概述：总体需求 第二代支付系统应在支持已有业务类型的同时，主动适应支付业务的创新和发展，使系统未来能以较小的代价快速适应业务需求的变更以及发展本次不改造3第二代支付系统需求概述：非功能性需求 •业务容量需求–HVPS：2016年日均446万笔，峰值128万笔/小时–BEPS：2016年日均1148万笔，峰值242万笔/小时•约合328万包/日，峰值业务量为82万包/小时–IBPS：2011年日均300万笔，峰值75万笔/小时–合计的峰值轧差处理需求为157万次/小时•小额按包进行轧差处理、网银按笔进行轧差处理•可靠性要求–系统的可使用率应保持在总运行时间的99.9%，故障平均修复时间不超过20分钟4第二代支付系统需求概述：运维需求•系统运维需求￿–建立和应用系统有机整合的运行监控系统–建立符合信息化系统管理规范的运行维护系统￿–建立先进的客户服务系统￿5第二代支付系统需求概述：系统切换要求 •第二代支付系统采取“支付系统统一切换、各参与者分步切换”的上线方案，系统在功能上可兼容第一代支付系统的报文标准。

•￿在第二代支付系统上线当日，国家处理中心（NPC）及各CCPC切换到第二代支付系统，同时停止第一代支付系统的运行•已完成二代系统接口改造的参与者可通过新版接口接入第二代支付系统；•未完成二代系统接口改造的参与者可通过原接口程序接入第二代支付系统，待完成系统改造后再通过新版接口接入第二代支付系统•人民银行根据管理需要设置统一的切换期￿6第二代支付系统需求概述：主要变化•与一代系统的主要变化–更全面的流动性风险管理功能–支持新兴电子支付–灵活的接入和清算模式–人民币外币的PVP–支持人民币跨境支付–业务标准与报文格式–支付信息管理7应用系统设计：设计思路设计思路：•集中化、平台化、组件化、标准化•以支付报文传输系统为支撑，支付业务处理系统为核心￿遵循原则：•采用面向服务的架构的理念和技术•业务流程化原则•模块可重用原则￿•子系统松耦合原则￿•子系统内聚性原则￿8应用系统设计：支付业务处理•子系统划分：综合安全性、应用组件功能相似性、子系统内聚性、独立性等因素，将应用组件划分为10个子系统–支付业务处理子系统（大额，小额，网银）；–支付账务处理子系统；–公共管理子系统；–计费子系统；–统一用户认证授权子系统；–明细查询与数据管理子系统；–监控子系统；–统计分析子系统；–行名行号子系统；–参与者业务管理子系统。

9应用系统设计：总体结构报文传输与业务处理分离10应用系统设计：支付报文传输•业务功能：–传输安全￿–报文校验￿–智能路由￿•主要特性￿：–与业务系统无关￿–兼容多种报文格式￿–高可用性￿11应用系统设计：支付报文传输部署•集中交换网关–支持水平扩展方式部署，单台服务器宕机不会影响到报文传输平台的连续运行–对经过的报文同时进行本地和异地集中存储，确保灾难情况下支付报文传输平台业务数据的完整性•区域接入网关–区域汇聚、安全检查–智能路由和报文转发￿–支持水平扩展方式部署•参与者接入端–负责接收商业银行行内系统向支付报文传输平台提交的各类报文–负责接收区域接入网关向本接入点发送的报文，并转发至参与者行内系统–支持采用水平群集方式部署，同一接入点的报文传输平台接入服务器可并行工作，单台服务器失效，不影响该接入点其它服务器的继续运行–支持AIX和Linux操作系统，MQ与TLQ中间件12应用系统设计：应用功能分布•国家处理中心NPC–支付业务处理子系统（大额，小额，网银）–支付账务处理子系统–公共管理子系统–统一用户认证授权子系统–计费子系统–明细查询与数据管理子系统–监控子系统–统计分析子系统–行名行号子系统–集中交换网关子系统•城市处理中心CCPC–区域接入网关子系统–参与者业务管理子系统（根据实际需要）•支付系统参与者–参与者接入端软件–参与者业务管理子系统（间联参与者）13应用系统设计：与一代支付系统的主要变化•实现报文传输和业务处理分离：–方便参与者的灵活接入；–简化业务系统的处理逻辑；￿•业务处理划分为业务处理子系统（含大额、小额、网银）和账务处理子系统：–层次清晰，提高系统整体处理效率；￿•建立统一的业务管理和业务监控平台：–为支付系统的业务人员提供单一入口，通过用户身份认证后按各自授权分别操作、监控和管理各业务系统；￿•增加应用监控子系统：–可随时了解系统运行情况，提前发现系统故障或异常，有助于提高运维水平；•改进对参与者的支持：–通过报文传输平台可支持参与者的灵活接入需求，降低前置机复杂度和维护难度；–建设参与者业务管理系统，支持中小参与者特别是农村金融机构的低成本接入、业务收发和业务管理。

￿14数据管理设计：设计思路•按数据重要性进行区别存储和保护，关键数据应集中在NPC；•满足业务处理性能的要求；￿•注重数据的完整性、一致性和可用性，统一数据的定义、变更等管理；￿•建立有效的数据备份和归档机制￿15数据管理设计：字符集与数据编码 • 为更好的适应国际标准，并适应第二代支付系统的国际化趋势，第二代支付系统数据交换和存储格式统一采用UTF-8编码集•￿UTF-8是Unicode的一种最常用的变长字符编码，可以根据不同的符号自动选择编码的长短在UTF－8中，字符以8位序列来编码，用一个或几个字节来表示一个字符•￿￿UTF-8编码集包含全世界所有国家需要用到的字符，字符集大；同时是国际通行的编码方式，得到了几乎所有系统软件的支持，通用性强UTF-8编码的文字可以在各国支持UTF8字符集的浏览器上显示，而无需下载IE的中文语言支持包￿16数据管理设计：数据交换•查询库–联机交易数据库的实时数据镜像库；–方便对数据实施查询、统计、分析以及采集、监控等功能；–简化各个子系统之间的数据关系；–减少重要业务系统对数据库的压力•主要的数据交换方式：–准实时数据复制–准实时数据采集–联机报文类数据交换–批量处理类数据交换–参数数据交换￿17数据管理设计：数据归档与检索•各业务系统中将超过联机数据保存期的数据按照规定的接口要求导出为XML格式的文件，通过网络将归档文件送给归档与检索系统，归档系统对归档数据进行分级存储，建立索引支持检索。

￿￿•归档数据保存期为15年，归档系统应支持数据的分级存储功能，5年内的数据保存在联机存储上，超出5年的数据自动迁移到低速率的存储介质上，以降低存储成本￿序号数据类型归档需求备注1业务数据√归档子系统+数据异地存储2报文数据√归档子系统+数据异地存储18数据管理设计：与一代支付系统的主要变化•建立查询库–减少业务管理、查询、监测、统计等对交易系统的影响；•建立统一的数据归档和检索平台–为今后支付信息的再加工和再利用提供基础设施和技术条件•字符集、数据编码和报文标准–支持国际标准•数据集中在NPC19计算机方案：混合平台方案 •基本思路￿￿￿￿￿￿￿￿￿￿￿借鉴一代支付系统的成功经验，根据应用系统设计和数据分布设计的结果，通过区分计算资源，将联机交易系统的核心处理逻辑（例如轧差、记账）、关键业务数据（包括清算账户信息，参与者交换的报文信息等）部署在主机平台，而将计算复杂且对CPU资源消耗过高的处理逻辑，例如XML报文的解析、业务流程的控制、业务数据核对等逻辑部署在开放平台，实现联机交易系统数据集中、应用分布的混合平台架构统计分析等子系统的应用和数据均部署在开放平台￿￿￿￿￿￿￿￿￿￿￿在实现上遵循以下原则：￿￿￿￿￿￿￿￿￿（1）联机交易系统依赖的业务数据集中存储在主机平台。

￿￿￿￿￿￿￿￿￿（2）所有对主机平台数据库的更改操作应通过主机核心应用服务完成，分布式平台业务系统通过SNA或IPIC以一阶段方式访问主机上对应的子系统核心服务完成数据更新操作￿￿￿￿￿￿￿￿￿（3）开放平台可通过数据库客户端访问主机数据，但仅限于只读操作￿￿20•NPC逻辑部署：总体结构–主机平台核心服务层•主机上的账务业务处理子系统和各业务处理核心服务层均选择基于成熟的CICS事务管理器和DB2 数据库，维护和管理各自的业务数据•主机平台上存储SAPS账务数据、特殊业务数据、小额业务数据、网银业务数据、大额业务数据、公共管理（含计费）数据；•主机上的数据采用准实时数据复制技术将数据复制到开放系统存储的查询库中，以避免管理客户端、业务监控、应用监控等对主机业务数据查询带来的压力–开发平台业务处理层•访问主机核心服务•为继承现有资产，可部署CICS 事务管理器和WMQ来保障应用逻辑内部数据的一致性和完整性计算机方案：混合平台方案21计算机方案：混合平台方案•MBFE物理部署物理部署：：直连参与者22计算机方案：混合平台方案•MBFE物理部署物理部署：：间连参与者23选择混合结构的考虑•充分利用大型主机的高安全性，将关键业务逻辑部署在主机平台，只有经过主机应用才能修改（增删改）关键业务数据；￿•充分利用IBM大型主机的成熟技术，尽最大限度提高支付系统核心业务系统的高可用性。

基于大型主机实施的GDPS/Hyperswap等技术使系统可用性可达到99.999%以上，保证无论是单台主机还是单台存储出现故障时，业务连续性均可以得到很好的保证目前全球各大银行的关键业务系统大多数都运行在主机平台；国内四大商业银行目前都已采用该技术保障其核心系统的高可用性•一代支付系统就是采用的混合结构，积累了相应的软件开发、工程实施以及运行维护的经验；二代支付系统继续沿用这一结构（在细节方面加以优化），风险相对可控•与在主机上部署全部应用功能相比，采用混合结构能较大程度降低建设运维成本和软件开发难度24计算机方案：与一代支付系统的主要变化•总体技术路线和一代支付系统基本一致：–关键业务系统拟继续采用主机/开放系统的混合结构–辅助信息系统全部使用开发系统–继续采用一代中表现稳定并积累了丰富开发运行管理经验的相关技术和软硬件产品￿•调整数据分布和应用分布：–关键业务数据全部存放在主机–只允许主机应用访问这些数据￿•改进数据交换方式：–通过交易数据镜像库简化子系统之间的数据交互￿25计算机方案：与一代支付系统的主要变化•全面增强系统的可用性：–主要通过采取群集负载均衡，尽量少采用主备模式；–具体包括主机上采用并行耦合技术–报文传输平台自行研发双机/多机并行技术并实现自动选择传输路径等￿•改进系统的可扩展性：–纵向可扩展和水平可扩展；–通过群集技术可以方便的增加服务器来提升系统的处理能力；￿•提升系统的可维护性：–建立集中监控系统，快速发现和定位问题；–提供应用监测手段并与运维管理系统集成；提供系统的维护窗口和维护手段等￿26网络方案：与一代支付系统的主要变化•按照信息安全等级保护的相关要求，采用安全域的概念，按照不同的功能分区划分安全域，不同的安全域采用不同等级的防护策略；￿•支持多中心同时，多中心之间建立高速通道，支持互相访问；￿•提供多种网络管理手段。

27第二代支付系统信息安全保障体系28安全方案：与一代支付系统的主要变化•强化数据传输安全，在传输平台中实现对数据完整性的检查；￿•用户集中管理，建设统一的用户认证和授权子系统，实现用户身份认证、访问控制以及用户操作的安全审计；￿•建立网络安全体系，建设安全域边界、网络边界；重点保护CCPC与参与者之间的边界，对接入支付系统进行更为严格的控制，确保支付系统边界的完整性；￿•注重安全管理，安全审计等，搭建相应的平台￿29运维管理 ：设计思路 •“多中心一体化”的运维管理￿–一体化的监控￿–一体化的运行￿–一体化的维护管理–一体化的服务支持￿•运维监控中心与数据中心分离￿•数据集中与分级管理相适应￿•具备良好的可扩展性和可用性￿30运维管理：与一代支付系统的主要变化•运维管理–从未来将形成多中心的格局和提高运维管理和业务连续性管理水平的角度考虑，运维监控系统的建设依照“多中心一体化（多个物理中心协同形成一个大的逻辑中心）”的思路进行设计，支持一体化的监控、运行、维护等；￿–支持运维中心和数据中心分离；严格数据中心的管理，只允许系统维护人员进入核心运行区，运维监控的支持、管理和操作人员通过远程、甚至异地访问和监控系统运行，并执行运维管理流程的各项工作支持分级运维；￿–增加应用监控等运维功能，提供客户服务、技术论坛及服务支持网站等，改进对清算中心和参与者的技术支持￿31备份系统建设方案：MBFE备份 • 二代支付系统直连参与者MBFE仅部署支付报文传输平台接入端软件–支持水平扩展方式部署，参与者可通过多台MBFE同时向支付系统发送业务–一台MBFE的故障不会影响到参与者的业务连续运行•MBFE备份—主用MBFE与备用MBFE–为防范单个NPC/CCPC故障导致从其接入的MBFE业务受到影响，参与者可选择主备MBFE分别接入主备NPC/CCPC的模式；–主用MBFE（可以多台）与主用NPC/CCPC接入，正常情况下所有业务从该组MBFE进行收发；–备用MBFE与备用NPC/CCPC建立连接，在主用NPC/CCPC出现故障时，改从备用MBFE进行报文收发。

32备份系统建设方案：MBFE备份 •MBFE备份–一般而言，主用线路接入NPC的参与者，备用线路宜选择接入备用NPC；–对于主用线路从CCPC接入的全国性商业银行，则可选择从其备用数据中心所在地CCPC作为备用接入；–对于区域性的城市商业银行或农村信用社，也可以根据自身实际情况来选择是否建立备用接入线路，确有需要的，可以选择从人民银行当地的同城转接中心建立备用接入线路33备份系统：与一代支付系统的主要变化•业务连续性￿–NPC数据备份需求简单，相关业务数据全部位于主机平台，所采用的备份技术相对单一，降低了系统复杂度；–通过应用方式在异地备份了全部报文数据，实现了报文数据零丢失，方便非计划切换情况下的数据查找和恢复；￿–降低了CCPC备份复杂度，CCPC灾难备份水平较一代有明显改善￿；–为参与者MBFE备份提供了多种手段34系统切换方案：基本思路 • 在二代支付系统开发建设期间，按照二代应用架构和数据架构同步改造一代支付系统对于CMT报文的业务处理逻辑，实现一代CMT/二代XML报文处理逻辑相对分离，但数据共享的目的–报文处理逻辑的分离使得开发过程中交叉环节较少，便于系统实现，同时也便于过渡期结束后从二代应用中剥离CMT报文应用逻辑–而业务数据的集中将更便于实现集中查询、统计、分析，并方便实施系统高可用性平台建设和灾难备份系统建设。

￿35系统切换方案：兼容策略 •报文交换￿–为保证一、二代支付系统过渡期间业务平滑处理，二代支付系统将向二代参与者发布“报文目录”，说明各支付系统参与者支持收发的一、二代支付系统报文清单–未完成改造参与者，即一代参与者支持的报文清单默认为所有一代支付系统报文集合–已完成改造参与者，即二代参与者需根据自身情况在该“报文目录”中注册自己支持的收发报文清单￿￿￿36系统切换方案：兼容策略 •业务并行处理￿￿￿￿￿￿￿￿￿￿￿37系统切换方案：兼容策略 •业务管理￿￿￿￿￿￿￿￿￿￿￿二代支付系统投产时，应向参与者提供统一的业务管理界面此方案下，一代/二代业务数据的集中存储更便于实现集中的业务管理界面￿￿￿￿￿￿￿￿￿￿对于CCPC业务人员，其业务管理功能均通过访问NPC的业务管理应用服务器实现，原一代支付系统在CCPC本地安装的客户端将不能再使用￿38系统切换方案：切换流程 采用此切换方案，一代/二代支付系统业务处理逻辑共用业务数据库、基础数据和时序控制信息，实质上只有二代支付系统一个业务系统，因此该方案下，宜采用一次性投产方案，即二代支付系统投产时，同步在NPC和32个CCPC部署二代应用，但在二代支付系统投产前，可考虑分阶段完成CCPC系统软件升级，以提前准备好二代CCPC应用运行环境。

￿第二代支付系第二代支付系统统的的实实施施计计划划1.启动阶段2.系统开发和环境准备阶段3.业务测试阶段4.参与者系统联调测试5.模拟运行和上线试运行阶段谢￿￿谢！。