铁路客运电子支付投诉问题处理系统研究与设计

贾成强，刘婷婷，贾 静，冯 焱

（中国铁道科学研究院集团有限公司 电子计算技术研究所，北京 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 结束语

根据目前的投诉问题处理业务流程，结合客票系统与电子支付平台架构的特点，设计了系统的架构与功能，通过系统，各个技术、业务部门可以进行协同工作，既可以提高业务和支付数据查询、核查的准确性与效率，又可以实现投诉退款处理流程的实时监控，整体提高电子支付投诉处置的能力与水平，更快地解决旅客反映的问题，缩短投诉退款的时间，减少旅客重复投诉，保障铁路总公司电子支付业务的安全运营，提高投诉退款的效率，提高客运服务水平，提高旅客满意度，维护铁路客运服务形象。