鐵路客運電子支付投訴問題處理系統研究與設計

賈成強，劉婷婷，賈 靜，馮 焱

（中國鐵道科學研究院集團有限公司 電子計算技術研究所，北京 100081）

2011年鐵路客票系統在車站售票窗口和自動售票機（TVM）[1-3]實現電子支付，鐵路客運支付業務正式進入電子支付[4]時代，隨著鐵路12306[5]互聯網售票系統的全面實行，電子支付數量和比例不斷提高，鐵路電子支付平臺[6]并發交易不斷增大，為旅客購票提供更大的支付便利同時，也帶來了新的問題，當網絡中斷、系統故障、運輸組織調整或其他不可抗力等情況時，可能造成旅客重復支付、支付后未出票、銀行退款失敗等問題，造成旅客投訴，給鐵路客運形象造成負面影響。

目前，為了保證鐵路資金安全，電子支付類投訴業務的受理流程為多單位反復核查、確認、報批、審核最終完成投訴辦理。依照此辦理退款過程，解決了大量的投訴問題，但仍然存在人工核查，工作量大且效率不高，同時由于存在多部門審核辦法不同，流程復雜，造成審核時間較長的現象。

隨著虛擬化、內存數據庫和分布式集群[7-9]等技術的不斷發展和成熟，在很多業務系統中得到很好的應用，結合鐵路客運電子支付業務的特點，研究設計客運電子支付投訴問題處理系統，通過系統進行協同工作，提高電子支付投訴業務數據審核、處理的自動化能力，提高電子支付投訴處置的能力與水平，縮短退款時間。

1 設計目標及原則

1.1 設計目標

（1）實現鐵路12306客戶服務中心對旅客電子支付投訴信息統一平臺的查詢、核查、辦理的功能，整個流程可控。（2）實現電子支付相關技術支持單位，在統一系統平臺下對電子支付投訴信息進行核查工作。（3）實現電子支付相關業務管理單位，在統一系統平臺下對電子支付投訴信息進行審批工作。

1.2 設計原則

（1）易用性

整個系統的各種軟件、硬件均應符合相關的國際、國內標準，要求界面直觀、簡潔；菜單要求功能清晰，具有層次感，各個功能鍵的定義要合理、規范。

（2）先進性與成熟性

應符合鐵路信息化建設的規劃，符合信息技術發展趨勢，充分考慮未來發展的需要，借鑒互聯網、云計算、大數據等先進技術，在實用性的要求下，既要體現先進性，也要保證成熟性。

（3）開放性

采用開放的體系結構、技術標準和規范、產品選擇、技術路線以及開放的應用設計，能夠與外部系統進行信息的交互和共享。

（4）高可靠性

系統運行應穩定可靠，為鐵路客運電子支付投訴辦理提供可靠的服務，系統設計應在主機、存儲、網絡等核心層面避免單點故障、加強對外接口的安全監控、加強對資源的保護以及建立應急備份機制。

（5）可擴展性

系統設計必須遵循擴展性原則，保證系統架構和功能具有擴展性和靈活性，能滿足延伸服務業務擴展帶來的數據量增長、用戶增長以及業務增長的需求。

（6）安全性

系統面向鐵路電子支付投訴處理相關各部門提供服務，應該充分考慮整個系統運行的安全策略和機制，可以根據不同的業務要求和應用處理，建立不同的安全措施；系統需采用多種手段，確保數據安全，應符合現有的鐵路安全設計規范要求，確保系統核心數據不泄密，和系統基礎數據不被盜取。

2 系統需求分析

2.1 業務需求

鐵路客運電子支付投訴問題處理系統的用戶范圍廣泛，包括鐵路客戶服務中心、鐵科院集團公司、網絡公司、鐵路總公司運輸局客運處、鐵路總公司資金中心等用戶，根據投訴處理的業務流程，每類用戶在使用平臺時，有不同的權限。

系統能夠提供投訴退款記錄的信息化管理功能，實現投訴退款信息錄入，業務技術和管理部門分用戶等級查詢、審核和審批，審批后的數據推送到鐵路客票投訴退款處理系統進行退款。各部門可以按照作業流程，在平臺上實現各自業務辦理，系統為退款投訴處理提供了信息化處理手段[10]。同時，業務流程可以實現流程配置，根據流程需求可以實現靈活配置，快速完成流程調整。業務流程分類如下。

（1）投訴退款查詢流程

投訴退款查詢流程是鐵路客戶服務中心處理鐵路電子支付旅客投訴的基礎流程，通過系統可以查詢到旅客業務及交易數據，再確定投訴退款需要如何進行處理。

（2）投訴退款處理流程

投訴退款處理流程是客服在確認需要給旅客辦理電子退款后，根據事由、金額、類型等特辦處理的規則，通過系統發起退款申請，系統按照投訴退款處理流程的設定，將投訴退款處理單在各技術與業務單位流轉核查、審批，并最終完成投訴退款處理。

系統可以對各類問題分類、形成原因、多發時段、多發區域等指標進行統計分析，形成報表及優化建議。

2.2 系統需求

鐵路客運電子支付投訴問題處理系統至少保障100個用戶的并發查詢及辦理業務，在1年內的系統歷史業務數據，不超過5 s內返回查詢結果；超過1年的系統歷史業務數據，不超過20 s內返回查詢結果；系統歷史數據至少保留3年；用戶登陸系統后，無操作狀態超時自動進行清退，實現系統資源釋放。

根據旅客個人信息查詢車票信息和支付數據時，系統通過客票系統和電子支付平臺歷史數據查詢接口，至少在30 s內返回相對應信息數據，要求數據全面完整，可以準確判斷車票信息和支付數據的關系。

3 系統技術方案

3.1 系統架構設計

鐵路客運電子支付投訴問題處理系統采用B/S架構，服務運行在客票網，采用兩級架構。在鐵路總公司一級建立集中數據庫服務器與應用服務器集群，采用負載均衡技術對外提供統一地址服務；各使用單位終端通過鐵路客票網或鐵路內部服務網接入系統。系統架構，如圖1所示。

圖1 體系架構圖

（1）系統網絡由鐵路內部服務網、客票網、客服內網組成，并通過安全平臺相連。

（2）系統由核心系統和前臺瀏覽器兩級構成。

（3）不具備鐵路客票網絡環境的終端可以通過鐵路內部服務網接入系統。

（4）核心系統運行在客票網，主要由投訴問題處理服務（OCS）和Database構成，核心OCS系統服務負責實現業務功能，Database數據庫負責存儲基礎數據及投訴退款業務數據。

（5）Web Service查詢服務運行在客服內網，與支付平臺服務對接，實現電子支付信息查詢。

（6）GemFire分布式內存對象緩存系統，負責存儲客票發售與預定系統（TRS）客票歷史數據，同時提供數據查詢服務。

（7）通過客票退款系統根據投訴退款類型，最終完成投訴退款辦理。

3.2 OCS系統結構

OCS系統核心功能模塊執行流程，如圖2所示。

圖2 OCS系統核心功能模塊執行流程圖

其流程是從前臺XML發送請求給后臺程序，后臺程序通過Action接收前臺的命令請求，Actioin發送給業務處理邏輯BO，BO發送給WebService或數據庫查詢執行器，通過WebService或數據庫操作執行器返回命令結果給Domain進行封裝結果集后返回給BO，BO將結果處理后返回給Action后在前臺XML界面中進行顯示。

（1）Action：其作用是接收前臺頁面的請求，處理請求內容并調用相關業務BO。并將執行結果封裝成XML格式的相應信息并返回給前臺頁面。

（2）BO：主要作用是實現業務功能邏輯。調用Domain與WebService或數據庫操作執行器進行數據交互。

（3）Domain：包含對象屬性及setter和getter方法的對象。

（4）WebService執行器：采用WebService協議查詢客票系統中的交易記錄，并封裝成對象（Domain）返回給BO。

（5）數據庫操作執行器：根據參數調用數據庫存儲過程，并將存儲過程返回結果封裝成對象（Domain）返回給BO。

3.3 業務流程設計

3.3.1 投訴退款查詢流程

鐵路旅客服務中心通過投訴處理系統對電子支付投訴的信息進行查詢，根據查詢到業務、支付信息判斷下一步辦理的業務類型，選擇后續流程：投訴退款處理、相關系統查詢或投訴關閉，如圖3所示。

圖3 投訴退款查詢流程

3.3.2 投訴退款處理流程

投訴退款處理流程是鐵路客戶服務中心通過投訴處理系統對電子支付投訴的進行投訴退款處理流程，是系統業務處理的核心業務流程，涉及的各個相關業務單位，在業務流程的不同階段，參與業務的辦理，如圖4所示。

3.4 系統功能設計

圖4 投訴退款處理流程圖

3.4.1 系統基礎數據維護

系統基礎數據維護由業務類型管理、業務流程管理和流程單位管理功能組成，實現系統核心業務功能的基礎數據支撐，實現業務辦理流程可以動態調整。

（1）業務類型管理

對投訴問題處理的業務類型進行數據定義，具有查詢、增加、刪除、修改的功能。每個業務類型定義包括業務類型編號和業務類型名稱關鍵字段。

（2）業務流程管理

對業務流程進行數據定義，具有查詢、增加、刪除、修改的功能。業務流程每個定義包含業務發起單位、業務流程、流程序號、流程名稱、流程編碼、流程狀態。

（3）流程單位管理

根據具體流程中的業務參與單位進行數據定義，具有查詢、增加、刪除、修改的功能。每個流程單位定義包含流程發起單位、當前執行單位、提交單位、業務類型、流程序號、流程名稱、是否默認。

3.4.2 人員權限管理

人員權限管理由用戶管理和角色管理功能組成，實現平臺的授權管理，各個角色的用戶只能按照平臺規定的權限進行操作，保證平臺的應用安全。平臺的用戶管理采用同級管理模式，由具有平臺維護權限的用戶為各個用戶角色設置一個高級權限用戶，高級權限用戶可以維護管理本角色的其他用戶。

（1）用戶管理

用戶管理完成系統用戶基本信息的維護，具有查詢、增加、刪除、修改、鎖定、解鎖、修改密碼、角色配置、權限查看的功能。系統用戶包括系統管理員、業務操作員，通過角色配置功能實現用戶具體功能權限管理。

（2）角色管理

角色管理完成用戶角色信息的維護功能，以實現對不同操作員相同權限集合的統一管理，具有查詢、增加、刪除、修改、配置用戶、配置權限、配置流程權限的功能。通過配置權限功能實現對操作員使用功能權限的授予、修改和取消；通過配置流程權限功能實現對操作員業務流程中參與業務辦理權限的授予、修改和取消。

（3）密碼管理

密碼管理實現登陸用戶的密碼修改。密碼長度為6～10 bit英文字符或數字，兩次輸入的新密碼必須一致方可更改密碼。

3.4.3 投訴信息管理

投訴信息管理是整個系統的核心功能，提供從投訴信息查詢到投訴辦理的全流程功能服務。用戶通過交易信息查詢功能，可以查詢準確的客票系統相關車票的業務全流程數據、支付平臺的扣款、退款詳細狀態信息以及銀行交易信息。通過投訴退款查詢功能，實現對旅客投訴退款業務的聯合查詢辦理。通過投訴退款辦理功能，實現對旅客投訴退款業務的聯合審批辦理。

（1）線下、線上交易信息查詢

根據乘車日期、證件號、訂單號等組合條件，可以進行線下、線上旅客購票電子支付信息查詢，展示滿足條件的日期、車次、席位、支付等詳細信息。

（2）線下、線上投訴退款查詢

實現線下、線下投訴退款查詢的全流程管理，各單位用戶根據用戶角色，在投訴退款查詢中，可以查詢到本單位負責查詢確認的業務、交易信息。

（3）線下、線上投訴退款辦理

實現線下、線上投訴退款辦理的全流程管理，各單位用戶根據用戶角色，在投訴退款辦理界面中，可以查詢到本單位負責核查、審批的業務、交易信息。

3.4.4 統計分析

投訴問題處理平臺對各類問題的進行分類、形成原因、多發時段、多發區域等指標進行統計分析形成報表及優化建議。統計功能如下：

（1）按投訴日期進行統計分析；

（2）按投訴問題的購票渠道進行統計分析；

（3）按投訴問題的類型進行統計分析；

（4）投訴問題處理的方案進行統計分析；

（5）按投訴問題的鐵路局、車站對線下投訴數據量進行統計分析；

（6）按辦理退款方式（快速處理/審核處理）進行統計分析；

（7）按審核周期統計，分析審核過程中各自耗時長短；

（8）按業務影響因素進行統計分析。

3.4.5 輔助功能

（1）登陸日志查詢

登陸日志查詢功能可以根據條件查詢用戶登陸日志信息，用戶登陸日志包括單位碼、用戶編號、用戶姓名、登陸IP、登陸時間、退出時間。

（2）操作日志查詢

操作日志查詢功能可以根據條件查詢用戶操作日志信息，用戶操作日志包括單位碼、用戶編號、用戶姓名、登陸IP、登陸時間、退操作類型、操作狀態。

（3）消息管理

消息管理功能可以根據定義，提示登陸用戶需要關注和處理的業務信息。

（4）系統幫助

提供系統幫助文檔，提供操作員使用幫助。

3.5 接口設計

（1）客票系統查詢接口

客票系統提供業務數據查詢接口，根據乘車日期、互聯網訂單號、乘車人身份證號等信息，可以查詢旅客全流程業務數據以及交易數據。

（2）電子支付平臺查詢接口

根據業務流水號、銀行流水號，電子支付平臺提供全流程的電子交易數據，以及詳細的銀行交易信息。

（3）客票退款系統數據接口

系統根據客票退款系統數據接口格式，可以推送投訴退款數據給客票退款系統，由客票退款系統完成最終退款業務。

3.6 安全方案

鐵路客運電子支付投訴問題處理系統，系統將存儲大量旅客投訴信息等重要信息，系統和信息安全尤為重要。同時，考慮到客票系統安全4級等保，兩個系統之間的信息傳遞，要滿足客票系統安全體系架構要求。

（1）網絡安全設計

在現有鐵路客票網的網絡體系框架下，實現充分利用現有安全防護措施。對于電子支付投訴問題處理系統與客票系統的數據交互，統一由客票安全平臺實現系統信息安全防護架構。

（2）系統安全設計

為了保證系統使用過程中的用戶信息的安全性保護，系統內部相應功能模塊采用授權使用；對于相關數據的存儲采取加密方式，并通過授權使用的方式進行權限控制。

（3）數據安全設計

為了保證電子支付投訴問題處理系統的信息向客票系統傳輸的安全性，采取基于數字證書簽名加密的方式進行數據交換。

4 關鍵技術

4.1 虛擬化技術

虛擬化是把物理資源轉變為邏輯上可以管理的資源，不受物理限制的約束，以打破物理結構之間的壁壘。通過虛擬化技術實現所有的資源透明地運行在各種各樣的物理平臺上，資源管理按邏輯方式進行，資源自動化分配。目前5種主流虛擬化技術是：CPU虛擬化、網絡虛擬化、服務器虛擬化、存儲虛擬化和應用虛擬化，由于服務器虛擬化發展時間長，應用廣泛，從某種意思上講，可以把服務器虛擬化等同于虛擬化。

服務器虛擬化是在操作系統與硬件之間加入一個虛擬化軟件層虛擬機監控器（VMM，Virtual Machine Monitor），通過空間上的分割、時間上的分時以及模擬，將服務器物理資源抽象成邏輯資源，向上層操作系統提供一個與它原先期待一致的服務器硬件環境虛擬機（VM，Virtual Machine），使得上層操作系統可以直接運行在虛擬環境上，并允許具有不同操作系統的多個虛擬機相互隔離，并發運行在同一臺物理機上，從而提供更高的IT資源利用率和靈活性。

鐵路客運電子支付投訴問題處理系統構建在服務器虛擬化技術之上，通過服務器虛擬化技術，利用虛擬機實時遷移和虛擬機集群中的應用程序高可用性，消除停機并保護數據，確保業務連續性；可以提高整合率、硬件利用率，整合并優化資源，減少硬件使用和降低運營成本；通過集成的備份、恢復和故障切換功能，確保始終可用的運營連續性，提高應用程序質量。

4.2 基于內存的分布式集群技術

基于內存的分布式集群技術是通過云計算平臺虛擬化技術，將若干X86服務器的內存集中起來，組成最高可達數十TB的內存資源池，將全部數據加載到內存中，進行內存計算。計算過程本身不需要讀寫磁盤，只是定期將數據同步或異步方式寫到磁盤中。在分布式集群中保存了多份數據，任何一臺機器故障，在其它機器上還有備份數據，因此不用擔心數據丟失，具有了持續性的數據高可用性和容錯性，將內存數據持久化到各種傳統的關系數據庫、分布式文件系統和其它文件系統中，實現在線數據備份。

系統采用GemFire實現基于內存的分布式集群技術應用，實現了一個位于應用集群和后端數據源之間的高性能、分布式的操作數據管理基礎架構，具有低延遲、高吞吐量的數據共享和事件分發的特點。充分利用網絡中的內存和磁盤資源，形成一個實時的數據網格，同時可以通過增加服務器部署規模，在內存計算的基礎上，線性擴展性能。通過key－value等數據對象和關系存儲，結合Map－Reduce并行查詢，滿足大數據量下高并發的業務查詢效率要求。

5 結束語

根據目前的投訴問題處理業務流程，結合客票系統與電子支付平臺架構的特點，設計了系統的架構與功能，通過系統，各個技術、業務部門可以進行協同工作，既可以提高業務和支付數據查詢、核查的準確性與效率，又可以實現投訴退款處理流程的實時監控，整體提高電子支付投訴處置的能力與水平，更快地解決旅客反映的問題，縮短投訴退款的時間，減少旅客重復投訴，保障鐵路總公司電子支付業務的安全運營，提高投訴退款的效率，提高客運服務水平，提高旅客滿意度，維護鐵路客運服務形象。