《商業(yè)銀行支付系統(tǒng)技術總體方案》由會員分享，可在線閱讀，更多相關《商業(yè)銀行支付系統(tǒng)技術總體方案（54頁珍藏版）》請在裝配圖網上搜索。

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)網 上 支 付跨 行 清 算 系 統(tǒng)本次不改造 7 第二代支付系統(tǒng)需求概述：非功能性需求 ? 業(yè)務容量需求 – 2016年日均 446萬筆，峰值 128萬筆 /小時 – 2016年日均 1148萬筆，峰值 242萬筆 /小時 ? 約合 328萬包 /日，峰值業(yè)務量為 82萬包 /小時 – 2011年日均 300萬筆，峰值 75萬筆 /小時 – 合計的峰值軋差處理需求為 157萬次 /小時 ? 小額按包進行軋差處理、網銀按筆進行軋差處理 ? 可靠性要求 – 系統(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)（大額，小額，網銀）； – 支付賬務處理子系統(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)網 上 支 付 跨 行 清 算 系 統(tǒng)清 算 賬 戶 管 理 系 統(tǒng)公 共 管 理 系 統(tǒng). . . . . 17 應用系統(tǒng)設計：支付報文傳輸 ? 業(yè)務功能： – 傳輸安全 – 報文校驗 – 智能路由 ? 主要特性 ： – 與業(yè)務系統(tǒng)無關 – 兼容多種報文格式 – 高可用性 18 應用系統(tǒng)設計：支付報文傳輸部署 ? 集中交換網關 – 支持水平擴展方式部署，單臺服務器宕機不會影響到報文傳輸平臺的連續(xù)運行 – 對經過的報文同時進行本地和異地集中存儲，確保災難情況下支付報文傳輸平臺業(yè)務數(shù)據(jù)的完整性 ? 區(qū)域接入網關 – 區(qū)域匯聚、安全檢查 – 智能路由和報文轉發(fā) – 支持水平擴展方式部署 ? 參與者接入端 – 負責接收商業(yè)銀行行內系統(tǒng)向支付報文傳輸平臺提交的各類報文 – 負責接收區(qū)域接入網關向本接入點發(fā)送的報文，并轉發(fā)至參與者行內系統(tǒng) – 支持采用水平群集方式部署，同一接入點的報文傳輸平臺接入服務器可并行工作，單臺服務器失效，不影響該接入點其它服務器的繼續(xù)運行 – 支持 19 應用系統(tǒng)設計：應用功能分布 ? 國家處理中心 支付業(yè)務處理子系統(tǒ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) – 集中交換網關子系統(tǒng) ? 城市處理中心 區(qū)域接入網關子系統(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)（含大額、小額、網銀）和賬務處理子系統(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ī)定的接口要求導出為 過網絡將歸檔文件送給歸檔與檢索系統(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ù)、網銀業(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 網絡方案：與一代支付系統(tǒng)的主要變化 ? 按照信息安全等級保護的相關要求，采用安全域的概念，按照不同的功能分區(qū)劃分安全域，不同的安全域采用不同等級的防護策略； ? 支持多中心同時在線，多中心之間建立高速通道，支持互相訪問； ? 提供多種網絡管理手段。 34 第二代支付系統(tǒng)信息安全保障體系 35 安全方案：與一代支付系統(tǒng)的主要變化 ? 強化數(shù)據(jù)傳輸安全，在傳輸平臺中實現(xiàn)對數(shù)據(jù)完整性的檢查； ? 用戶集中管理，建設統(tǒng)一的用戶認證和授權子系統(tǒng)，實現(xiàn)用戶身份認證、訪問控制以及用戶操作的安全審計； ? 建立網絡安全體系，建設安全域邊界、網絡邊界；重點保護 接入支付系統(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)控等運維功能，提供客戶服務、技術論壇及服務支持網站等，改進對清算中心和參與者的技術支持 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 網 交換 機業(yè) 務 處 理 子 系 統(tǒng) x 處 理 子 系統(tǒng) x 2公 共 管 理 子 系 統(tǒng) x 網 交換 機磁 盤 陣列F I C O 機S A N 交 換機遠 程 備 份 中 心業(yè) 務 處 理 子 系 統(tǒng) x 處 理 子 系統(tǒng) x 2公 共 管 理 子 系 統(tǒng) x 網 交換 機異 步 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 接 入 端 網 關 區(qū) 域 網 關 C C P C 1接 入 服 務 器 A 接 入 服 務 器 故 障M B F E 接 入 端 網 關 A 區(qū) 域 網 關 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)的上線運行，包括 代 謝謝！