商業(yè)銀行支付系統(tǒng)技術總體方案

1 第二代支付系統(tǒng) 技術總體方案簡介 中國人民銀行清算總中心 張清明 2010年 10月 2 第一代支付系統(tǒng)在技術上的主要特點（一） 分步建設 先建設了清算賬戶管理系統(tǒng)和大額支付系統(tǒng)，再逐步建設了小額支付系統(tǒng)、支付管理信息系統(tǒng)等應用系統(tǒng)； 作為第二代支付系統(tǒng)應用系統(tǒng)之一，先行建設了 混合結構 賬戶管理系統(tǒng)：核心數(shù)據(jù)和核心應用部署在主機；輔助數(shù)據(jù)和主要業(yè)務邏輯部署在開發(fā)系統(tǒng)； 大額、小額：數(shù)據(jù)和應用部署在開放系統(tǒng)； 管理信息系統(tǒng)：數(shù)據(jù)和應用部署在開放系統(tǒng) 高可靠性保障 主機：冷備份（ 開放數(shù)據(jù)庫服務器：群集模式（ 開放應用服務器：熱備模式（ 報文標準 第一代支付系統(tǒng)在技術上的主要特點（二） 參與者適當集中接入 參與者主要以省級分行作為直接參與者接入當?shù)爻鞘刑幚碇行模?部分參與者（如國債、銀聯(lián)、 過 一定的備份等級水平 逐步建設完善了應急備份系統(tǒng)，實現(xiàn)了 主要應用系統(tǒng)備份水平達到 （ 分鐘， 小時）； 建設了 實施對特定 部分 一定的監(jiān)控和運維管理水平 在 監(jiān)控部分系統(tǒng)軟件和硬件。 實現(xiàn)了應用軟件自主開發(fā)，逐步建立了客戶服務和技術支持體系。 4 第一代支付系統(tǒng)在技術上存在的主要不足 分布實施，總體架構設計不夠； 數(shù)據(jù)及應用在 應用系統(tǒng)耦合程度較高，不能快速響應業(yè)務需求的變化； 缺少先進完善的災難備份系統(tǒng)； 缺乏應用監(jiān)控手段； 系統(tǒng)接入方式不夠靈活； 報文標準未采用國際標準。 5 信息化技術發(fā)展趨勢 金融業(yè)務系統(tǒng)發(fā)展趨勢 重視系統(tǒng)架構設計，提倡面向服務的系統(tǒng)架構； 注重應用系統(tǒng)整合及信息共享； 數(shù)據(jù)及核心應用逐步集中； 加強系統(tǒng)備份能力建設，保障業(yè)務連續(xù)性； 使用開放的國際標準、國內標準和行業(yè)標準； 采取縱深防御的策略，按等級保護要求強化信息系統(tǒng)安全； 提升系統(tǒng)的可擴展性和可維護性，改進運維管理； 注重數(shù)據(jù)分析和信息挖掘。 6 第二代支付系統(tǒng)需求概述：總體需求 第二代支付系統(tǒng)應在支持已有業(yè)務類型的同時，主動適應支付業(yè)務的創(chuàng)新和發(fā)展，使系統(tǒng)未來能以較小的代價快速適應業(yè)務需求的變更以及發(fā)展。 大 額 支 付 系 統(tǒng)清 算 賬 戶 管 理 系 統(tǒng)（ 賬 戶 管 理 、 實 時 清 算 、 凈 額 清 算 ）支 付 管 理 信 息 系 統(tǒng)小 額 支 付 系 統(tǒng)支 票 影 像 交 換 系 統(tǒng)網(wǎng) 上 支 付跨 行 清 算 系 統(tǒng)本次不改造 7 第二代支付系統(tǒng)需求概述：非功能性需求 業(yè)務容量需求 2016年日均 446萬筆，峰值 128萬筆 /小時 2016年日均 1148萬筆，峰值 242萬筆 /小時 約合 328萬包 /日，峰值業(yè)務量為 82萬包 /小時 2011年日均 300萬筆，峰值 75萬筆 /小時 合計的峰值軋差處理需求為 157萬次 /小時 小額按包進行軋差處理、網(wǎng)銀按筆進行軋差處理 可靠性要求 系統(tǒng)的可使用率應保持在總運行時間的 故障平均修復時間不超過 20分鐘。 8 第二代支付系統(tǒng)需求概述：運維需求 系統(tǒng)運維需求 建立和應用系統(tǒng)有機整合的運行監(jiān)控系統(tǒng) 建立符合信息化系統(tǒng)管理規(guī)范的運行維護系統(tǒng) 建立先進的客戶服務系統(tǒng) 9 第二代支付系統(tǒng)需求概述：系統(tǒng)切換要求 第二代支付系統(tǒng)采取“支付系統(tǒng)統(tǒng)一切換、各參與者分步切換”的上線方案，系統(tǒng)在功能上可兼容第一代支付系統(tǒng)的報文標準。 在第二代支付系統(tǒng)上線當日，國家處理中心（ 各 時停止第一代支付系統(tǒng)的運行。 已完成二代系統(tǒng)接口改造的參與者可通過新版接口接入第二代支付系統(tǒng)； 未完成二代系統(tǒng)接口改造的參與者可通過原接口程序接入第二代支付系統(tǒng)，待完成系統(tǒng)改造后再通過新版接口接入第二代支付系統(tǒng)。 人民銀行根據(jù)管理需要設置統(tǒng)一的切換期。 10 第二代支付系統(tǒng)需求概述：主要變化 與一代系統(tǒng)的主要變化 更全面的流動性風險管理功能 支持新興電子支付 靈活的接入和清算模式 人民幣外幣的 支持人民幣跨境支付 業(yè)務標準與報文格式 支付信息管理 11 建設目標和原則：總體目標 立足第一代支付系統(tǒng)的成功經驗，引入先進的支付清算管理理念和技術，滿足業(yè)務需求，解決原系統(tǒng)中存在的突出問題，進一步豐富系統(tǒng)功能，加強運行監(jiān)控，完善災備系統(tǒng)，建設適應新興電子支付發(fā)展的、面向參與者管理需要的、功能更完善、架構更合理、技術更先進、管理更簡便，以上海中心建設為起點，以北京中心投產為建成的新一代支付系統(tǒng)。 12 建設目標和原則：基本原則 要有利于高標準履行職責，確保支付系統(tǒng)安全穩(wěn)定運行 建設風險可控：要充分吸收一代支付系統(tǒng)的成功經驗；要確保所選擇的技術必須是成熟可靠且有發(fā)展前景的，并在國內外類似的關鍵業(yè)務系統(tǒng)中得到了成功應用； 體現(xiàn)二代支付系統(tǒng)的先進性：要優(yōu)化系統(tǒng)架構，完善系統(tǒng)功能，改進運維管理，方便運行維護，提高處理效率；要結合未來幾年的技術業(yè)務發(fā)展趨勢，具有一定的前瞻性，適應未來支付清算業(yè)務發(fā)展和創(chuàng)新需求； 統(tǒng)籌規(guī)劃：要通過借鑒吸收其他系統(tǒng)建設經驗，統(tǒng)盤考慮各應用系統(tǒng)的備份系統(tǒng)建設，避免資源浪費。 13 建設目標和原則：方案設計原則 1. 滿足業(yè)務需求 2. 系統(tǒng)平滑過渡 3. 提升系統(tǒng)安全性 4. 提升系統(tǒng)整體可用性 5. 靈活可擴展的應用架構 6. 提升系統(tǒng)可維護性 7. 靈活多樣的接入方式 8. 國際化的業(yè)務標準 14 應用系統(tǒng)設計：設計思路 設計思路： 集中化、平臺化、組件化、標準化 以支付報文傳輸系統(tǒng)為支撐，支付業(yè)務處理系統(tǒng)為核心 遵循原則： 采用面向服務的架構的理念和技術 業(yè)務流程化原則 模塊可重用原則 子系統(tǒng)松耦合原則 子系統(tǒng)內聚性原則 15 應用系統(tǒng)設計：支付業(yè)務處理 子系統(tǒng)劃分： 綜合安全性、應用組件功能相似性、子系統(tǒng)內聚性、獨立性等因素，將應用組件劃分為 10個子系統(tǒng)。 支付業(yè)務處理子系統(tǒng)（大額，小額，網(wǎng)銀）； 支付賬務處理子系統(tǒng)； 公共管理子系統(tǒng)； 計費子系統(tǒng)； 統(tǒng)一用戶認證授權子系統(tǒng)； 明細查詢與數(shù)據(jù)管理子系統(tǒng)； 監(jiān)控子系統(tǒng)； 統(tǒng)計分析子系統(tǒng)； 行名行號子系統(tǒng)； 參與者業(yè)務管理子系統(tǒng)。 16 應用系統(tǒng)設計：總體結構 C N A P S 2A C 銀 行T C B 清 算 組 織國 債支 付 報 文 傳 輸 平 臺C F X P D 支 付 系 統(tǒng)小 額 支 付 系 統(tǒng)網(wǎng) 上 支 付 跨 行 清 算 系 統(tǒng)清 算 賬 戶 管 理 系 統(tǒng)公 共 管 理 系 統(tǒng). . . . . 17 應用系統(tǒng)設計：支付報文傳輸 業(yè)務功能： 傳輸安全 報文校驗 智能路由 主要特性 ： 與業(yè)務系統(tǒng)無關 兼容多種報文格式 高可用性 18 應用系統(tǒng)設計：支付報文傳輸部署 集中交換網(wǎng)關 支持水平擴展方式部署，單臺服務器宕機不會影響到報文傳輸平臺的連續(xù)運行 對經過的報文同時進行本地和異地集中存儲，確保災難情況下支付報文傳輸平臺業(yè)務數(shù)據(jù)的完整性 區(qū)域接入網(wǎng)關 區(qū)域匯聚、安全檢查 智能路由和報文轉發(fā) 支持水平擴展方式部署 參與者接入端 負責接收商業(yè)銀行行內系統(tǒng)向支付報文傳輸平臺提交的各類報文 負責接收區(qū)域接入網(wǎng)關向本接入點發(fā)送的報文，并轉發(fā)至參與者行內系統(tǒng) 支持采用水平群集方式部署，同一接入點的報文傳輸平臺接入服務器可并行工作，單臺服務器失效，不影響該接入點其它服務器的繼續(xù)運行 支持 19 應用系統(tǒng)設計：應用功能分布 國家處理中心 支付業(yè)務處理子系統(tǒng)（大額，小額，網(wǎng)銀） 支付賬務處理子系統(tǒng) 公共管理子系統(tǒng) 統(tǒng)一用戶認證授權子系統(tǒng) 計費子系統(tǒng) 明細查詢與數(shù)據(jù)管理子系統(tǒng) 監(jiān)控子系統(tǒng) 統(tǒng)計分析子系統(tǒng) 行名行號子系統(tǒng) 集中交換網(wǎng)關子系統(tǒng) 城市處理中心 區(qū)域接入網(wǎng)關子系統(tǒng) 參與者業(yè)務管理子系統(tǒng)（根據(jù)實際需要） 支付系統(tǒng)參與者 參與者接入端軟件 參與者業(yè)務管理子系統(tǒng)（間聯(lián)參與者） 20 應用系統(tǒng)設計：與一代支付系統(tǒng)的主要變化 實現(xiàn)報文傳輸和業(yè)務處理分離： 方便參與者的靈活接入； 簡化業(yè)務系統(tǒng)的處理邏輯； 業(yè)務處理劃分為業(yè)務處理子系統(tǒng)（含大額、小額、網(wǎng)銀）和賬務處理子系統(tǒng)： 層次清晰，提高系統(tǒng)整體處理效率； 建立統(tǒng)一的業(yè)務管理和業(yè)務監(jiān)控平臺： 為支付系統(tǒng)的業(yè)務人員提供單一入口，通過用戶身份認證后按各自授權分別操作、監(jiān)控和管理各業(yè)務系統(tǒng)； 增加應用監(jiān)控子系統(tǒng)： 可隨時了解系統(tǒng)運行情況，提前發(fā)現(xiàn)系統(tǒng)故障或異常，有助于提高運維水平； 改進對參與者的支持： 通過報文傳輸平臺可支持參與者的靈活接入需求，降低前置機復雜度和維護難度； 建設參與者業(yè)務管理系統(tǒng)，支持中小參與者特別是農村金融機構的低成本接入、業(yè)務收發(fā)和業(yè)務管理。 21 數(shù)據(jù)管理設計：設計思路 按數(shù)據(jù)重要性進行區(qū)別存儲和保護，關鍵數(shù)據(jù)應集中在 滿足業(yè)務處理性能的要求； 注重數(shù)據(jù)的完整性、一致性和可用性，統(tǒng)一數(shù)據(jù)的定義、變更等管理； 建立有效的數(shù)據(jù)備份和歸檔機制。 22 數(shù)據(jù)管理設計：字符集與數(shù)據(jù)編碼 為更好的適應國際標準，并適應第二代支付系統(tǒng)的國際化趨勢，第二代支付系統(tǒng)數(shù)據(jù)交換和存儲格式統(tǒng)一采用 以根據(jù)不同的符號自動選擇編碼的長短。在 8中，字符以 8位序列來編碼，用一個或幾個字節(jié)來表示一個字符。 符集大；同時是國際通行的編碼方式，得到了幾乎所有系統(tǒng)軟件的支持，通用性強。 無需下載 23 數(shù)據(jù)管理設計：數(shù)據(jù)交換 查詢庫 聯(lián)機交易數(shù)據(jù)庫的實時數(shù)據(jù)鏡像庫； 方便對在線數(shù)據(jù)實施查詢、統(tǒng)計、分析以及采集、監(jiān)控等功能； 簡化各個子系統(tǒng)之間的數(shù)據(jù)關系； 減少重要業(yè)務系統(tǒng)對數(shù)據(jù)庫的壓力。 主要的數(shù)據(jù)交換方式： 準實時數(shù)據(jù)復制 準實時數(shù)據(jù)采集 聯(lián)機報文類數(shù)據(jù)交換 批量處理類數(shù)據(jù)交換 參數(shù)數(shù)據(jù)交換 24 數(shù)據(jù)管理設計：數(shù)據(jù)歸檔與檢索 各業(yè)務系統(tǒng)中將超過聯(lián)機數(shù)據(jù)保存期的數(shù)據(jù)按照規(guī)定的接口要求導出為 過網(wǎng)絡將歸檔文件送給歸檔與檢索系統(tǒng)，歸檔系統(tǒng)對歸檔數(shù)據(jù)進行分級存儲，建立索引支持檢索。 歸檔數(shù)據(jù)保存期為 15年，歸檔系統(tǒng)應支持數(shù)據(jù)的分級存儲功能， 5年內的數(shù)據(jù)保存在聯(lián)機存儲上，超出 5年的數(shù)據(jù)自動遷移到低速率的存儲介質上，以降低存儲成本 。 序號 數(shù)據(jù)類型 歸檔需求 備注 1 業(yè)務數(shù)據(jù) 歸檔子系統(tǒng) +數(shù)據(jù)異地存儲 2 報文數(shù)據(jù) 歸檔子系統(tǒng) +數(shù)據(jù)異地存儲 25 數(shù)據(jù)管理設計：與一代支付系統(tǒng)的主要變化 建立查詢庫 減少業(yè)務管理、查詢、監(jiān)測、統(tǒng)計等對交易系統(tǒng)的影響； 建立統(tǒng)一的數(shù)據(jù)歸檔和檢索平臺 為今后支付信息的再加工和再利用提供基礎設施和技術條件 字符集、數(shù)據(jù)編碼和報文標準 支持國際標準 數(shù)據(jù)集中在 6 計算機方案：混合平臺方案 基本思路 借鑒一代支付系統(tǒng)的成功經驗，根據(jù)應用系統(tǒng)設計和數(shù)據(jù)分布設計的結果，通過區(qū)分計算資源，將聯(lián)機交易系統(tǒng)的核心處理邏輯（例如軋差、記賬）、關鍵業(yè)務數(shù)據(jù)（包括清算賬戶信息，參與者交換的報文信息等）部署在主機平臺，而將計算復雜且對 如 務流程的控制、業(yè)務數(shù)據(jù)核對等邏輯部署在開放平臺，實現(xiàn)聯(lián)機交易系統(tǒng)數(shù)據(jù)集中、應用分布的混合平臺架構。統(tǒng)計分析等子系統(tǒng)的應用和數(shù)據(jù)均部署在開放平臺。 在實現(xiàn)上遵循以下原則： （ 1）聯(lián)機交易系統(tǒng)依賴的業(yè)務數(shù)據(jù)集中存儲在主機平臺。 （ 2）所有對主機平臺數(shù)據(jù)庫的更改操作應通過主機核心應用服務完成，分布式平臺業(yè)務系統(tǒng)通過 （ 3）開放平臺可通過數(shù)據(jù)庫客戶端訪問主機數(shù)據(jù)，但僅限于只讀操作 。 27 體結構 主機平臺核心服務層 主機上的賬務業(yè)務處理子系統(tǒng)和各業(yè)務處理核心服務層均選擇基于成熟的 據(jù)庫，維護和管理各自的業(yè)務數(shù)據(jù) 主機平臺上存儲 殊業(yè)務數(shù)據(jù)、小額業(yè)務數(shù)據(jù)、網(wǎng)銀業(yè)務數(shù)據(jù)、大額業(yè)務數(shù)據(jù)、公共管理（含計費）數(shù)據(jù)； 主機上的數(shù)據(jù)采用準實時數(shù)據(jù)復制技術將數(shù)據(jù)復制到開放系統(tǒng)存儲的查詢庫中，以避免管理客戶端、業(yè)務監(jiān)控、應用監(jiān)控等對主機業(yè)務數(shù)據(jù)查詢帶來的壓力 開發(fā)平臺業(yè)務處理層 訪問主機核心服務 為繼承現(xiàn)有資產，可部署 務管理器和 計算機方案：混合平臺方案 28 計算機方案：混合平臺方案 直連參與者 參 與 者業(yè) 務 系 統(tǒng) 2報 文 傳 輸參 與 者 接 入 端服 務 器 傳 輸參 與 者 接 入 端服 務 器 客 戶 端L A 客 戶 端參 與 者業(yè) 務 系 統(tǒng) 者業(yè) 務 系 統(tǒng) 1密 押 服 務 器簽 名 服 務 器29 計算機方案：混合平臺方案 間連參與者 間 連 M B F 庫 服 務 器支 付 報 文 傳 輸 平 臺參 與 者 接 入 端 服 務 器管 理 客 戶 端L A 客 戶 端間 連 M B F 服 務 器可 合 并 部 署密 押 服 務 器簽 名 服 務 器30 選擇混合結構的考慮 充分利用大型主機的高安全性，將關鍵業(yè)務邏輯部署在主機平臺，只有經過主機應用才能修改（增刪改）關鍵業(yè)務數(shù)據(jù)； 充分利用 最大限度提高支付系統(tǒng)核心業(yè)務系統(tǒng)的高可用性?；诖笮椭鳈C實施的上，保證無論是單臺主機還是單臺存儲出現(xiàn)故障時，業(yè)務連續(xù)性均可以得到很好的保證。目前全球各大銀行的關鍵業(yè)務系統(tǒng)大多數(shù)都運行在主機平臺；國內四大商業(yè)銀行目前都已采用該技術保障其核心系統(tǒng)的高可用性。 一代支付系統(tǒng)就是采用的混合結構，積累了相應的軟件開發(fā)、工程實施以及運行維護的經驗；二代支付系統(tǒng)繼續(xù)沿用這一結構（在細節(jié)方面加以優(yōu)化），風險相對可控。 與在主機上部署全部應用功能相比，采用混合結構能較大程度降低建設運維成本和軟件開發(fā)難度。 31 計算機方案：與一代支付系統(tǒng)的主要變化 總體技術路線和一代支付系統(tǒng)基本一致： 關鍵業(yè)務系統(tǒng)擬繼續(xù)采用主機 /開發(fā)系統(tǒng)的混合結構 輔助信息系統(tǒng)全部使用開發(fā)系統(tǒng) 繼續(xù)采用一代中表現(xiàn)穩(wěn)定并積累了豐富開發(fā)運行管理經驗的相關技術和軟硬件產品。 調整數(shù)據(jù)分布和應用分布： 關鍵業(yè)務數(shù)據(jù)全部存放在主機 只允許主機應用訪問這些數(shù)據(jù) 改進數(shù)據(jù)交換方式： 通過交易數(shù)據(jù)鏡像庫簡化子系統(tǒng)之間的數(shù)據(jù)交互 32 計算機方案：與一代支付系統(tǒng)的主要變化 全面增強系統(tǒng)的可用性： 主要通過采取群集負載均衡，盡量少采用主備模式； 具體包括主機上采用并行耦合技術 報文傳輸平臺自行研發(fā)雙機 /多機并行技術并實現(xiàn)自動選擇傳輸路徑等 改進系統(tǒng)的可擴展性： 縱向可擴展和水平可擴展； 通過群集技術可以方便的增加服務器來提升系統(tǒng)的處理能力； 提升系統(tǒng)的可維護性： 建立集中監(jiān)控系統(tǒng)，快速發(fā)現(xiàn)和定位問題； 提供應用監(jiān)測手段并與運維管理系統(tǒng)集成；提供系統(tǒng)的維護窗口和維護手段等 33 網(wǎng)絡方案：與一代支付系統(tǒng)的主要變化 按照信息安全等級保護的相關要求，采用安全域的概念，按照不同的功能分區(qū)劃分安全域，不同的安全域采用不同等級的防護策略； 支持多中心同時在線，多中心之間建立高速通道，支持互相訪問； 提供多種網(wǎng)絡管理手段。 34 第二代支付系統(tǒng)信息安全保障體系 35 安全方案：與一代支付系統(tǒng)的主要變化 強化數(shù)據(jù)傳輸安全，在傳輸平臺中實現(xiàn)對數(shù)據(jù)完整性的檢查； 用戶集中管理，建設統(tǒng)一的用戶認證和授權子系統(tǒng)，實現(xiàn)用戶身份認證、訪問控制以及用戶操作的安全審計； 建立網(wǎng)絡安全體系，建設安全域邊界、網(wǎng)絡邊界；重點保護 接入支付系統(tǒng)進行更為嚴格的控制，確保支付系統(tǒng)邊界的完整性； 注重安全管理，安全審計等，搭建相應的平臺。 36 運維管理 ：設計思路 多中心一體化”的運維管理 一體化的監(jiān)控 一體化的運行 一體化的維護管理 一體化的服務支持 運維監(jiān)控中心與數(shù)據(jù)中心分離 數(shù)據(jù)集中與分級管理相適應 具備良好的可擴展性和可用性 37 運維管理：與一代支付系統(tǒng)的主要變化 運維管理 從未來將形成多中心的格局和提高運維管理和業(yè)務連續(xù)性管理水平的角度考慮，運維監(jiān)控系統(tǒng)的建設依照“多中心一體化（多個物理中心協(xié)同形成一個大的邏輯中心）”的思路進行設計，支持一體化的監(jiān)控、運行、維護等； 支持運維中心和數(shù)據(jù)中心分離；嚴格數(shù)據(jù)中心的管理，只允許系統(tǒng)維護人員進入核心運行區(qū)，運維監(jiān)控的支持、管理和操作人員通過遠程、甚至異地訪問和監(jiān)控系統(tǒng)運行，并執(zhí)行運維管理流程的各項工作支持分級運維； 增加應用監(jiān)控等運維功能，提供客戶服務、技術論壇及服務支持網(wǎng)站等，改進對清算中心和參與者的技術支持 38 第二代支付系統(tǒng)備份系統(tǒng)建設路徑 上海中心投產時的備份系統(tǒng)建設 第二代支付系統(tǒng)在上海中心投產時，支付系統(tǒng)北京中心尚未建成，為確保支付系統(tǒng)的備份能力，應以上海中心作為生產中心，無錫主站作為應急備份中心。 北 京 中 心（ 建 設 中 . . .）北 京 主 站（ 改 造 中 . . .）無 錫 主 站應 急 備 份 中 心異 步 傳 輸上 海 中 心生 產 中 心39 第二代支付系統(tǒng)備份系統(tǒng)建設路徑 北京中心建成后的備份系統(tǒng)建設目標 將生產中心從上海中心切換到北京中心，從而形成北京中心作為生產中心、北京主站作為同城備份中心和上海中心作為遠程備份中心的“兩地三中心”最終格局。 北 京 中 心生 產 中 心北 京 主 站同 城 備 份 中 心同 步 傳 輸異 步 傳 輸上 海 中 心遠 程 備 份 中 心40 備份系統(tǒng)建設方案 兩地三中心方案 主機平臺數(shù)據(jù)備份方案 同 步 P P R C O N 交換 機業(yè) 務 處 理 子 系 統(tǒng) x 處 理 子 系統(tǒng) x 2主 磁 盤陣 列磁 盤 陣列F I C O 機S A 交 換機S A N 交 換機生 產 中 心 同 城 備 份 中 心公 共 管 理 子 系 統(tǒng) x 網(wǎng) 交換 機業(yè) 務 處 理 子 系 統(tǒng) x 處 理 子 系統(tǒng) x 2公 共 管 理 子 系 統(tǒng) x 網(wǎng) 交換 機磁 盤 陣列F I C O 機S A N 交 換機遠 程 備 份 中 心業(yè) 務 處 理 子 系 統(tǒng) x 處 理 子 系統(tǒng) x 2公 共 管 理 子 系 統(tǒng) x 網(wǎng) 交換 機異 步 P P R 份系統(tǒng)建設方案 兩地三中心方案 開放平臺數(shù)據(jù)備份方案 磁 盤 陣 列同 步 P P R 子 系 統(tǒng) x 分 析 子 系 統(tǒng) x 2統(tǒng) 計 分 析 子 系 統(tǒng) x 2 其 他 子 系 統(tǒng) x 中 心同 城 備 份 中 心磁 盤 陣 列統(tǒng) 計 分 析 子 系 統(tǒng) x 2其 他 子 系 統(tǒng) x 備 份 中 心異 步 P P R 陣 列S A N 交 換 機S A N 交 換 機S A N 交 換 機42 備份系統(tǒng)建設方案： 系統(tǒng)備份 M B F E 接 入 端 網(wǎng) 關 區(qū) 域 網(wǎng) 關 C C P C 1接 入 服 務 器 A 接 入 服 務 器 故 障M B F E 接 入 端 網(wǎng) 關 A 區(qū) 域 網(wǎng) 關 P C 2參 與 者43 備份系統(tǒng)建設方案： 數(shù)據(jù)備份 為實現(xiàn) 如每日日終后）通過報文傳遞至 證參與者正常接入。 44 備份系統(tǒng)建設方案： 二代支付系統(tǒng)直連參與者 支持水平擴展方式部署，參與者可通過多臺 一臺 主用 為防范單個 參與者 可 選擇主備 主用 以多臺）與主用 常情況下所有業(yè)務從該組 備用 主用 從備用 45 備份系統(tǒng)建設方案： 一般而言，主用線路接入 用線路宜選擇接入備用 對于主用線路從 可選擇從其備用數(shù)據(jù)中心所在地 對于區(qū)域性的城市商業(yè)銀行或農村信用社，也可以根據(jù)自身實際情況來選擇是否建立備用接入線路，確有需要的，可以選擇從人民銀行當?shù)氐耐寝D接中心建立備用接入線路 46 備份系統(tǒng)：與一代支付系統(tǒng)的主要變化 業(yè)務連續(xù)性 關業(yè)務數(shù)據(jù)全部位于主機平臺，所采用的備份技術相對單一，降低了系統(tǒng)復雜度； 通過應用方式在異地備份了全部報文數(shù)據(jù)，實現(xiàn)了報文數(shù)據(jù)零丟失，方便非計劃切換情況下的數(shù)據(jù)查找和恢復； 降低了 ； 為參與者 47 系統(tǒng)切換方案：基本思路 在二代支付系統(tǒng)開發(fā)建設期間，按照二代應用架構和數(shù)據(jù)架構同步改造一代支付系統(tǒng)對于 現(xiàn)一代 代 數(shù)據(jù)共享的目的。 報文處理邏輯的分離使得開發(fā)過程中交叉環(huán)節(jié)較少，便于系統(tǒng)實現(xiàn)，同時也便于過渡期結束后從二代應用中剝離 而業(yè)務數(shù)據(jù)的集中將更便于實現(xiàn)集中查詢、統(tǒng)計、分析，并方便實施系統(tǒng)高可用性平臺建設和災難備份系統(tǒng)建設。 48 系統(tǒng)切換方案：兼容策略 報文交換 為保證一、二代支付系統(tǒng)過渡期間業(yè)務平滑處理，二代支付系統(tǒng)將向二代參與者發(fā)布“報文目錄”，說明各支付系統(tǒng)參與者支持收發(fā)的一、二代支付系統(tǒng)報文清單。 未完成改造參與者，即一代參與者支持的報文清單默認為所有一代支付系統(tǒng)報文集合。 已完成改造參與者，即二代參與者需根據(jù)自身情況在該“報文目錄”中注冊自己支持的收發(fā)報文清單。 49 系統(tǒng)切換方案：兼容策略 業(yè)務并行處理 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 業(yè) 務 報 文處 理 邏 輯X M L 業(yè) 務 報 文處 理 邏 輯內 部 格 式50 系統(tǒng)切換方案：兼容策略 業(yè)務管理 二代支付系統(tǒng)投產時，應向參與者提供統(tǒng)一的業(yè)務管理界面。此方案下，一代 /二代業(yè)務數(shù)據(jù)的集中存儲更便于實現(xiàn)集中的業(yè)務管理界面。 對于 業(yè)務管理功能均通過訪問 一代支付系統(tǒng)在 51 系統(tǒng)切換方案：切換流程 采用此切換方案，一代 /二代支付系統(tǒng)業(yè)務處理邏輯共用業(yè)務數(shù)據(jù)庫、基礎數(shù)據(jù)和時序控制信息，實質上只有二代支付系統(tǒng)一個業(yè)務系統(tǒng)， 因此該方案下，宜采用一次性投產方案 ，即二代支付系統(tǒng)投產時，同步在 2個 在二代支付系統(tǒng)投產前，可考慮分階段完成 提前準備好二代 52 工程實施計劃 接口規(guī)范 計劃在 2010年 10月發(fā)布。 應用軟件開發(fā) 計劃在 2010年 12月底前完成，包括各業(yè)務系統(tǒng)應用軟件總體設計、概要設計、編碼和單元測試等。 業(yè)務測試 業(yè)務測試從 2011年 1月開始，至 2011年 6月結束，業(yè)務測試的目標是驗證系統(tǒng)的各項功能，確保系統(tǒng)功能可滿足業(yè)務需求。 參與者系統(tǒng)聯(lián)調測試 計劃 2011年 4月份開始，開放系統(tǒng)環(huán)境供參與者聯(lián)調測試，并于 2011年 6月底前完成。 53 工程實施計劃 實環(huán)境測試 2011年 4月 6月，在準生產環(huán)境進行實環(huán)境測試，確保系統(tǒng)各項指標可以達到預計的設計目標，保證系統(tǒng)投產后的安全穩(wěn)定運行。 模擬運行 2011年 7月至 8月，參與者連接至準生產環(huán)境進行模擬運行。 上線運行 上線運行工作量巨大，涉及面十分廣泛。計劃 2011年“十一”期間實現(xiàn)第二代支付系統(tǒng)的上線運行，包括 代 謝謝！