商业银行支付系统技术总体方案
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
12
建设目标和原则：方案设计原则
1. 满足业务需求 2. 系统平滑过渡 3. 提升系统安全性 4. 提升系统整体可用性 5. 灵活可扩展的应用架构 6. 提升系统可维护性 7. 灵活多样的接入方式 8. 国际化的业务标准
13
应用系统设计：设计思路
设计思路：
• 集中化、平台化、组件化、标准化 • 以支付报文传输系统为支撑，支付业务处理系统为核心
• 建立统一的业务管理和业务监控平台：
– 为支付系统的业务人员提供单一入口，通过用户身份认证后按各自授 权分别操作、监控和管理各业务系统；
• 增加应用监控子系统：
– 可随时了解系统运行情况，提前发现系统故障或异常，有助于提高运 维水平；
• 改进对参与者的支持：
– 通过报文传输平台可支持参与者的灵活接入需求，降低前置机复杂度 和维护难度；
15
应用系统设计：总体结构
报文传输与业务处理分离
CFXPS
CNAPS2
大额支付系统 小额支付系统 网上支付跨行清算系统 清算账户管理系统 公共管理系统
ECDS
国债 银联
支付报文传输平台
商业银行
清算组织
ACS TCBS ......
16
应用系统设计：支付报文传输
• 业务功能：
– 传输安全 – 报文校验 – 智能路由
6
第二代支付系统需求概述：非功能性需求
• 业务容量需求
– HVPS：2016年日均446万笔，峰值128万笔/小时 – BEPS：2016年日均1148万笔，峰值242万笔/小时
• 约合328万包/日，峰值业务量为82万包/小时
– IBPS：2011年日均300万笔，峰值75万笔/小时 – 合计的峰值轧差处理需求为157万次/小时
– 开放应用服务器：热备模式（Active/Warm Stanby） NPC/CCPC
• 报文标准
– CMT/PKG
2
第一代支付系统在技术上的主要特点（二）
• 参与者适当集中接入 – 参与者主要以省级分行作为直接参与者接入当地城市处理中心； – 部分参与者（如国债、银联、TCBS）通过NPCFE一点接入NPC。
• 建立查询库 – 减少业务管理、查询、监测、统计等对交易系统 的影响；
• 建立统一的数据归档和检索平台 – 为今后支付信息的再加工和再利用提供基础设施 和技术条件
• 字符集、数据编码和报文标准 – 支持国际标准
• 数据集中在NPC
25
计算机方案：混合平台方案
• 基本思路
借鉴一代支付系统的成功经验，根据应用系统设计和数据分布 设计的结果，通过区分计算资源，将联机交易系统的核心处理逻辑 （例如轧差、记账）、关键业务数据（包括清算账户信息，参与者 交换的报文信息等）部署在主机平台，而将计算复杂且对CPU资源 消耗过高的处理逻辑，例如XML报文的解析、业务流程的控制、业 务数据核对等逻辑部署在开放平台，实现联机交易系统数据集中、 应用分布的混合平台架构。统计分析等子系统的应用和数据均部署 在开放平台。
控等功能； – 简化各个子系统之间的数据关系； – 减少重要业务系统对数据库的压力。
• 主要的数据交换方式：
– 准实时数据复制 – 准实时数据采集 – 联机报文类数据交换 – 批量处理类数据交换 – 参数数据交换
23
数据管理设计：数据归档与检索
• 各业务系统中将超过联机数据保存期的数据按照规定的接口 要求导出为XML格式的文件，通过网络将归档文件送给归档 与检索系统，归档系统对归档数据进行分级存储，建立索引 支持检索。
3
第一代支付系统在技术上存在的主要不足
• 分布实施，总体架构设计不够； • 数据及应用在NPC和CCPC的分布不尽合理； • 应用系统耦合程度较高，不能快速响应业务需求的变化； • 缺少先进完善的灾难备份系统； • 缺乏应用监控手段； • 系统接入方式不够灵活； • 报文标准未采用国际标准。
4
信息化技术发展趋势
11
建设目标和原则：基本原则
• 要有利于高标准履行职责，确保支付系统安全稳定运行 • 建设风险可控：要充分吸收一代支付系统的成功经验；要确
保所选择的技术必须是成熟可靠且有发展前景的，并在国内 外类似的关键业务系统中得到了成功应用； • 体现二代支付系统的先进性：要优化系统架构，完善系统功 能，改进运维管理，方便运行维护，提高处理效率；要结合 未来几年的技术业务发展趋势，具有一定的前瞻性，适应未 来支付清算业务发展和创新需求； • 统筹规划：要通过借鉴吸收其他系统建设经验，统盘考虑各 应用系统的备份系统建设，避免资源浪费。
21
数据管理设计：字符集与数据编码
• 为更好的适应国际标准，并适应第二代支付系统的国
际化趋势，第二代支付系统数据交换和存储格式统一采 用UTF-8编码集。 • UTF-8是Unicode的一种最常用的变长字符编码，可以 根据不同的符号自动选择编码的长短。在UTF－8中， 字符以8位序列来编码，用一个或几个字节来表示一个 字符。
10
建设目标和原则：总体目标
立足第一代支付系统的成功经验，引入先进的支付 清算管理理念和技术，满足业务需求，解决原系统中 存在的突出问题，进一步丰富系统功能，加强运行监 控，完善灾备系统，建设适应新兴电子支付发展的、 面向参与者管理需要的、功能更完善、架构更合理、 技术更先进、管理更简便，以上海中心建设为起点， 以北京中心投产为建成的新一代支付系统。
• 主要特性 ：
– 与业务系统无关 – 兼容多种报文格式 – 高可用性
17
应用系统设计：支付报文传输部署
• 集中交换网关 – 支持水平扩展方式部署，单台服务器宕机不会影响到报文传输平台的连续 运行 – 对经过的报文同时进行本地和异地集中存储，确保灾难情况下支付报文传 输平台业务数据的完整性
• 区域接入网关 – 区域汇聚、安全检查 – 智能路由和报文转发 – 支持水平扩展方式部署
第二代支付系统 技术总体方案简介
中国人民银行清算总中心 张清明 2010年10月
1
第一代支付系统在技术上的主要特点（一）
• 分步建设
– 先建设了清算账户管理系统和大额支付系统，再逐步建设了小额支 付系统、支付管理信息系统等应用系统；
– 作为第二代支付系统应用系统之一，先行建设了IBPS。 • 混合结构
• 参与者接入端 – 负责接收商业银行行内系统向支付报文传输平台提交的各类报文 – 负责接收区域接入网关向本接入点发送的报文，并转发至参与者行内系统 – 支持采用水平群集方式部署，同一接入点的报文传输平台接入服务器可并 行工作，单台服务器失效，不影响该接入点其它服务器的继续运行 – 支持AIX和Linux操作系统，MQ与TLQ中间件
8
第二代支付系统需求概述：系统切换要求
• 第二代支付系统采取“支付系统统一切换、各参与者分 步切换”的上线方案，系统在功能上可兼容第一代支付 系统的报文标准。
• 在第二代支付系统上线当日，国家处理中心（NPC）及 各CCPC切换到第二代支付系统，同时停止第一代支付系 统的运行。
• 已完成二代系统接口改造的参与者可通过新版接口接入 第二代支付系统；
18
应用系统设计：应用功能分布
• 国家处理中心NPC – 支付业务处理子系统（大额，小额，网银） – 支付账务处理子系统 – 公共管理子系统 – 统一用户认证授权子系统 – 计费子系统 – 明细查询与数据管理子系统 – 监控子系统 – 统计分析子系统 – 行名行号子系统 – 集中交换网关子系统
• 城市处理中心CCPC – 区域接入网关子系统 – 参与者业务管理子系统（根据实际需要）
• 归档数据保存期为15年，归档系统应支持数据的分级存储功 能，5年内的数据保存在联机存储上，超出5年的数据自动迁 移到低速率的存储介质上，以降低存储成本 。
序号 数据类型
1
业务数据
归档需求 备注
√
归档子系统+数据异地存储
2
报文数据
√
归档子系统+数据异地存储
24
数据管理设计：与一代支付系统的主要变化
• UTF-8编码集包含全世界所有国家需要用到的字符， 字符集大；同时是国际通行的编码方式，得到了几乎所 有系统软件的支持，通用性强。UTF-8编码的文字可以 在各国支持UTF8字符集的浏览器上显示，而无需下载 IE的中文语言支持包。
22
数据管理设计：数据交换
• 查询库
– 联机交易数据库的实时数据镜像库； – 方便对在线数据实施查询、统计、分析以及采集、监
39北京中心生产中心北京主站同城备份中心同步传输异步传输上海中心远程备份中心40备份系统建设方案两地三中心方案主机平台数据备份方案40同步pprcficon交换机业务处理子系统主磁盘阵列磁盘阵ficon交换机sa交换san交换生产中心同城备份中心公共管理子系统以太网交换机业务处理子系统以太网交换机磁盘阵ficon交换机san交换远程备份中心业务处理子系统以太网交换机异步pprc41备份系统建设方案两地三中心方案开放平台数据备份方案41磁盘阵列同步pprc其他子系统生产中心同城备份中心磁盘阵列统计分析子系统远程备份中心异步pprc磁盘阵列san交换机san交换机san交换机4242备份系统建设方案
– 账户管理系统：核心数据和核心应用部署在主机；辅助数据和主要 业务逻辑部署在开发系统；
– 大额、小额：数据和应用部署在开放系统；
– 管理信息系统：数据和应用部署在开放系统
• 高可靠性保障
– 主机：冷备份（Active/Cold Stanby）
NPC
– 开放数据库服务器：群集模式（Active/Active） NPC/CCPC
• 小额按包进行轧差处理、网银按笔进行轧差处理
• 可靠性要求
– 系统的可使用率应保持在总运行时间的99.9%，故障平均修复时 间不超过20分钟。
7
第二代支付系统需求概述：运维需求
• 系统运维需求
– 建立和应用系统有机整合的运行监控系统 – 建立符合信息化系统管理规范的运行维护系统 – 建立先进的客户服务系统
5
第二代支付系统需求概述：总体需求
第二代支付系统应在支持已有业务类型的同时， 主动适应支付业务的创新和发展，使系统未来能以较 小的代价快速适应业务需求的变更以及发展。
清算账户管理系统
（账户管理、实时清算、净额清算）
大额支付系统 小额支付系统
网上支付 跨行清算系统
支付管理信息系统
本次不改造
支票影像交换系统
• 支付系统参与者 – 参与者接入端软件 – 参与者业务管理子系统（间联参与者）
19
应用系统设计：与一代支付系统的主要变化
• 实现报文传输和业务处理分离：
– 方便参与者的灵活接入； – 简化业务系统的处理逻辑；
• 业务处理划分为业务处理子系统（含大额、小额、网银）和 账务处理子系统：
– 层次清晰，提高系统整体处理效率；
• 未完成二代系统接口改造的参与者可通过原接口程序接 入第二代支付系统，待完成系统改造后再通过新版接口 接入第二代支付系统。
• 人民银行根据管理需要设置统一的切换期。
9
第二代支付系统需求概述：主要变化 • 与一代系统的主要变化
– 更全面的流动性风险管理功能 – 支持新兴电子支付 – 灵活的接入和清算模式 – 人民币外币的PVP – 支持人民币跨境支付 – 业务标准与报文格式 – 支付信息管计，提倡面向服务的系统架构； – 注重应用系统整合及信息共享； – 数据及核心应用逐步集中； – 加强系统备份能力建设，保障业务连续性； – 使用开放的国际标准、国内标准和行业标准； – 采取纵深防御的策略，按等级保护要求强化信息系统
安全； – 提升系统的可扩展性和可维护性，改进运维管理； – 注重数据分析和信息挖掘。
– 建设参与者业务管理系统，支持中小参与者特别是农村金融机构的低 成本接入、业务收发和业务管理。
20
数据管理设计：设计思路
• 按数据重要性进行区别存储和保护，关键数据应集中 在NPC；
• 满足业务处理性能的要求； • 注重数据的完整性、一致性和可用性，统一数据的定
义、变更等管理； • 建立有效的数据备份和归档机制。
遵循原则：
• 采用面向服务的架构的理念和技术 • 业务流程化原则 • 模块可重用原则 • 子系统松耦合原则 • 子系统内聚性原则
14
应用系统设计：支付业务处理
• 子系统划分：综合安全性、应用组件功能相似性、子
系统内聚性、独立性等因素，将应用组件划分为10个子 系统。 – 支付业务处理子系统（大额，小额，网银）； – 支付账务处理子系统； – 公共管理子系统； – 计费子系统； – 统一用户认证授权子系统； – 明细查询与数据管理子系统； – 监控子系统； – 统计分析子系统； – 行名行号子系统； – 参与者业务管理子系统。
• 一定的备份等级水平 – 逐步建设完善了应急备份系统，实现了NPC站点备份； – 主要应用系统备份水平达到Tier 5 （RPO<1分钟，RTO<2小时）； – 建设了XCCPC，能实施对特定CCPC数据实时备份； – 部分CCPC建设了同城备份系统。
• 一定的监控和运维管理水平 – 在NPC/CCPC部署了CA监控系统，能监控部分系统软件和硬件。 – 实现了应用软件自主开发，逐步建立了客户服务和技术支持体系。
建设目标和原则：方案设计原则
1. 满足业务需求 2. 系统平滑过渡 3. 提升系统安全性 4. 提升系统整体可用性 5. 灵活可扩展的应用架构 6. 提升系统可维护性 7. 灵活多样的接入方式 8. 国际化的业务标准
13
应用系统设计：设计思路
设计思路：
• 集中化、平台化、组件化、标准化 • 以支付报文传输系统为支撑，支付业务处理系统为核心
• 建立统一的业务管理和业务监控平台：
– 为支付系统的业务人员提供单一入口，通过用户身份认证后按各自授 权分别操作、监控和管理各业务系统；
• 增加应用监控子系统：
– 可随时了解系统运行情况，提前发现系统故障或异常，有助于提高运 维水平；
• 改进对参与者的支持：
– 通过报文传输平台可支持参与者的灵活接入需求，降低前置机复杂度 和维护难度；
15
应用系统设计：总体结构
报文传输与业务处理分离
CFXPS
CNAPS2
大额支付系统 小额支付系统 网上支付跨行清算系统 清算账户管理系统 公共管理系统
ECDS
国债 银联
支付报文传输平台
商业银行
清算组织
ACS TCBS ......
16
应用系统设计：支付报文传输
• 业务功能：
– 传输安全 – 报文校验 – 智能路由
6
第二代支付系统需求概述：非功能性需求
• 业务容量需求
– HVPS：2016年日均446万笔，峰值128万笔/小时 – BEPS：2016年日均1148万笔，峰值242万笔/小时
• 约合328万包/日，峰值业务量为82万包/小时
– IBPS：2011年日均300万笔，峰值75万笔/小时 – 合计的峰值轧差处理需求为157万次/小时
– 开放应用服务器：热备模式（Active/Warm Stanby） NPC/CCPC
• 报文标准
– CMT/PKG
2
第一代支付系统在技术上的主要特点（二）
• 参与者适当集中接入 – 参与者主要以省级分行作为直接参与者接入当地城市处理中心； – 部分参与者（如国债、银联、TCBS）通过NPCFE一点接入NPC。
• 建立查询库 – 减少业务管理、查询、监测、统计等对交易系统 的影响；
• 建立统一的数据归档和检索平台 – 为今后支付信息的再加工和再利用提供基础设施 和技术条件
• 字符集、数据编码和报文标准 – 支持国际标准
• 数据集中在NPC
25
计算机方案：混合平台方案
• 基本思路
借鉴一代支付系统的成功经验，根据应用系统设计和数据分布 设计的结果，通过区分计算资源，将联机交易系统的核心处理逻辑 （例如轧差、记账）、关键业务数据（包括清算账户信息，参与者 交换的报文信息等）部署在主机平台，而将计算复杂且对CPU资源 消耗过高的处理逻辑，例如XML报文的解析、业务流程的控制、业 务数据核对等逻辑部署在开放平台，实现联机交易系统数据集中、 应用分布的混合平台架构。统计分析等子系统的应用和数据均部署 在开放平台。
控等功能； – 简化各个子系统之间的数据关系； – 减少重要业务系统对数据库的压力。
• 主要的数据交换方式：
– 准实时数据复制 – 准实时数据采集 – 联机报文类数据交换 – 批量处理类数据交换 – 参数数据交换
23
数据管理设计：数据归档与检索
• 各业务系统中将超过联机数据保存期的数据按照规定的接口 要求导出为XML格式的文件，通过网络将归档文件送给归档 与检索系统，归档系统对归档数据进行分级存储，建立索引 支持检索。
3
第一代支付系统在技术上存在的主要不足
• 分布实施，总体架构设计不够； • 数据及应用在NPC和CCPC的分布不尽合理； • 应用系统耦合程度较高，不能快速响应业务需求的变化； • 缺少先进完善的灾难备份系统； • 缺乏应用监控手段； • 系统接入方式不够灵活； • 报文标准未采用国际标准。
4
信息化技术发展趋势
11
建设目标和原则：基本原则
• 要有利于高标准履行职责，确保支付系统安全稳定运行 • 建设风险可控：要充分吸收一代支付系统的成功经验；要确
保所选择的技术必须是成熟可靠且有发展前景的，并在国内 外类似的关键业务系统中得到了成功应用； • 体现二代支付系统的先进性：要优化系统架构，完善系统功 能，改进运维管理，方便运行维护，提高处理效率；要结合 未来几年的技术业务发展趋势，具有一定的前瞻性，适应未 来支付清算业务发展和创新需求； • 统筹规划：要通过借鉴吸收其他系统建设经验，统盘考虑各 应用系统的备份系统建设，避免资源浪费。
21
数据管理设计：字符集与数据编码
• 为更好的适应国际标准，并适应第二代支付系统的国
际化趋势，第二代支付系统数据交换和存储格式统一采 用UTF-8编码集。 • UTF-8是Unicode的一种最常用的变长字符编码，可以 根据不同的符号自动选择编码的长短。在UTF－8中， 字符以8位序列来编码，用一个或几个字节来表示一个 字符。
10
建设目标和原则：总体目标
立足第一代支付系统的成功经验，引入先进的支付 清算管理理念和技术，满足业务需求，解决原系统中 存在的突出问题，进一步丰富系统功能，加强运行监 控，完善灾备系统，建设适应新兴电子支付发展的、 面向参与者管理需要的、功能更完善、架构更合理、 技术更先进、管理更简便，以上海中心建设为起点， 以北京中心投产为建成的新一代支付系统。
• 主要特性 ：
– 与业务系统无关 – 兼容多种报文格式 – 高可用性
17
应用系统设计：支付报文传输部署
• 集中交换网关 – 支持水平扩展方式部署，单台服务器宕机不会影响到报文传输平台的连续 运行 – 对经过的报文同时进行本地和异地集中存储，确保灾难情况下支付报文传 输平台业务数据的完整性
• 区域接入网关 – 区域汇聚、安全检查 – 智能路由和报文转发 – 支持水平扩展方式部署
第二代支付系统 技术总体方案简介
中国人民银行清算总中心 张清明 2010年10月
1
第一代支付系统在技术上的主要特点（一）
• 分步建设
– 先建设了清算账户管理系统和大额支付系统，再逐步建设了小额支 付系统、支付管理信息系统等应用系统；
– 作为第二代支付系统应用系统之一，先行建设了IBPS。 • 混合结构
• 参与者接入端 – 负责接收商业银行行内系统向支付报文传输平台提交的各类报文 – 负责接收区域接入网关向本接入点发送的报文，并转发至参与者行内系统 – 支持采用水平群集方式部署，同一接入点的报文传输平台接入服务器可并 行工作，单台服务器失效，不影响该接入点其它服务器的继续运行 – 支持AIX和Linux操作系统，MQ与TLQ中间件
8
第二代支付系统需求概述：系统切换要求
• 第二代支付系统采取“支付系统统一切换、各参与者分 步切换”的上线方案，系统在功能上可兼容第一代支付 系统的报文标准。
• 在第二代支付系统上线当日，国家处理中心（NPC）及 各CCPC切换到第二代支付系统，同时停止第一代支付系 统的运行。
• 已完成二代系统接口改造的参与者可通过新版接口接入 第二代支付系统；
18
应用系统设计：应用功能分布
• 国家处理中心NPC – 支付业务处理子系统（大额，小额，网银） – 支付账务处理子系统 – 公共管理子系统 – 统一用户认证授权子系统 – 计费子系统 – 明细查询与数据管理子系统 – 监控子系统 – 统计分析子系统 – 行名行号子系统 – 集中交换网关子系统
• 城市处理中心CCPC – 区域接入网关子系统 – 参与者业务管理子系统（根据实际需要）
• 归档数据保存期为15年，归档系统应支持数据的分级存储功 能，5年内的数据保存在联机存储上，超出5年的数据自动迁 移到低速率的存储介质上，以降低存储成本 。
序号 数据类型
1
业务数据
归档需求 备注
√
归档子系统+数据异地存储
2
报文数据
√
归档子系统+数据异地存储
24
数据管理设计：与一代支付系统的主要变化
• UTF-8编码集包含全世界所有国家需要用到的字符， 字符集大；同时是国际通行的编码方式，得到了几乎所 有系统软件的支持，通用性强。UTF-8编码的文字可以 在各国支持UTF8字符集的浏览器上显示，而无需下载 IE的中文语言支持包。
22
数据管理设计：数据交换
• 查询库
– 联机交易数据库的实时数据镜像库； – 方便对在线数据实施查询、统计、分析以及采集、监
39北京中心生产中心北京主站同城备份中心同步传输异步传输上海中心远程备份中心40备份系统建设方案两地三中心方案主机平台数据备份方案40同步pprcficon交换机业务处理子系统主磁盘阵列磁盘阵ficon交换机sa交换san交换生产中心同城备份中心公共管理子系统以太网交换机业务处理子系统以太网交换机磁盘阵ficon交换机san交换远程备份中心业务处理子系统以太网交换机异步pprc41备份系统建设方案两地三中心方案开放平台数据备份方案41磁盘阵列同步pprc其他子系统生产中心同城备份中心磁盘阵列统计分析子系统远程备份中心异步pprc磁盘阵列san交换机san交换机san交换机4242备份系统建设方案
– 账户管理系统：核心数据和核心应用部署在主机；辅助数据和主要 业务逻辑部署在开发系统；
– 大额、小额：数据和应用部署在开放系统；
– 管理信息系统：数据和应用部署在开放系统
• 高可靠性保障
– 主机：冷备份（Active/Cold Stanby）
NPC
– 开放数据库服务器：群集模式（Active/Active） NPC/CCPC
• 小额按包进行轧差处理、网银按笔进行轧差处理
• 可靠性要求
– 系统的可使用率应保持在总运行时间的99.9%，故障平均修复时 间不超过20分钟。
7
第二代支付系统需求概述：运维需求
• 系统运维需求
– 建立和应用系统有机整合的运行监控系统 – 建立符合信息化系统管理规范的运行维护系统 – 建立先进的客户服务系统
5
第二代支付系统需求概述：总体需求
第二代支付系统应在支持已有业务类型的同时， 主动适应支付业务的创新和发展，使系统未来能以较 小的代价快速适应业务需求的变更以及发展。
清算账户管理系统
（账户管理、实时清算、净额清算）
大额支付系统 小额支付系统
网上支付 跨行清算系统
支付管理信息系统
本次不改造
支票影像交换系统
• 支付系统参与者 – 参与者接入端软件 – 参与者业务管理子系统（间联参与者）
19
应用系统设计：与一代支付系统的主要变化
• 实现报文传输和业务处理分离：
– 方便参与者的灵活接入； – 简化业务系统的处理逻辑；
• 业务处理划分为业务处理子系统（含大额、小额、网银）和 账务处理子系统：
– 层次清晰，提高系统整体处理效率；
• 未完成二代系统接口改造的参与者可通过原接口程序接 入第二代支付系统，待完成系统改造后再通过新版接口 接入第二代支付系统。
• 人民银行根据管理需要设置统一的切换期。
9
第二代支付系统需求概述：主要变化 • 与一代系统的主要变化
– 更全面的流动性风险管理功能 – 支持新兴电子支付 – 灵活的接入和清算模式 – 人民币外币的PVP – 支持人民币跨境支付 – 业务标准与报文格式 – 支付信息管计，提倡面向服务的系统架构； – 注重应用系统整合及信息共享； – 数据及核心应用逐步集中； – 加强系统备份能力建设，保障业务连续性； – 使用开放的国际标准、国内标准和行业标准； – 采取纵深防御的策略，按等级保护要求强化信息系统
安全； – 提升系统的可扩展性和可维护性，改进运维管理； – 注重数据分析和信息挖掘。
– 建设参与者业务管理系统，支持中小参与者特别是农村金融机构的低 成本接入、业务收发和业务管理。
20
数据管理设计：设计思路
• 按数据重要性进行区别存储和保护，关键数据应集中 在NPC；
• 满足业务处理性能的要求； • 注重数据的完整性、一致性和可用性，统一数据的定
义、变更等管理； • 建立有效的数据备份和归档机制。
遵循原则：
• 采用面向服务的架构的理念和技术 • 业务流程化原则 • 模块可重用原则 • 子系统松耦合原则 • 子系统内聚性原则
14
应用系统设计：支付业务处理
• 子系统划分：综合安全性、应用组件功能相似性、子
系统内聚性、独立性等因素，将应用组件划分为10个子 系统。 – 支付业务处理子系统（大额，小额，网银）； – 支付账务处理子系统； – 公共管理子系统； – 计费子系统； – 统一用户认证授权子系统； – 明细查询与数据管理子系统； – 监控子系统； – 统计分析子系统； – 行名行号子系统； – 参与者业务管理子系统。
• 一定的备份等级水平 – 逐步建设完善了应急备份系统，实现了NPC站点备份； – 主要应用系统备份水平达到Tier 5 （RPO<1分钟，RTO<2小时）； – 建设了XCCPC，能实施对特定CCPC数据实时备份； – 部分CCPC建设了同城备份系统。
• 一定的监控和运维管理水平 – 在NPC/CCPC部署了CA监控系统，能监控部分系统软件和硬件。 – 实现了应用软件自主开发，逐步建立了客户服务和技术支持体系。