二维码电子票业务系统建设方案设计V20.docx
《二维码电子票业务系统建设方案设计V20.docx》由会员分享，可在线阅读，更多相关《二维码电子票业务系统建设方案设计V20.docx（37页珍藏版）》请在冰豆网上搜索。
二维码电子票业务系统建设方案设计V20
江门移动二维码电子票业务竞赛文件
系统建设方案
2006年11月29日
文档说明
本文档所涉及到的文字和图表，仅限广州市**信息技术有限公司和广东移动内部使用，未经广州市**信息技术有限公司的书面许可，请勿扩散到任何第三方。
附图目录
表格目录
1概述
1.1项目背景
随着移动通信技术的发展和增值业务服务的丰富，移动手机已经跨越了传统的通信工具这一角色定位，逐渐成为人们日常生活必不可少的生活工具。
为提高广大手机用户移动信息化生活的质量，将移动增值业务与人们的日常生活更加紧密的联系起来，广东移动已经先后推出了手机支付和条码凭证回执两类全新的移动应用技术。
为此，江门移动计划使用相应的接口（即手机钱包及条码凭证回执接口）开发二维码电子票业务系统。
会以实现与江门汽运集团合作开展客运手机购票业务为当前目标。
将来可以使用同样的技术扩展到其他的商业合作伙伴。
1.2建设目标
◆开展手机购票业务的应用，提高江门汽运购票业务的市场渗透率；
◆拓展手机小额支付、条码凭证电子回执应用。
提升手机支付、条码凭证的业务应用收入；
◆丰富移动用户的信息化生活，培养用户的手机消费习惯，为下一代移动通信变革巩固基础。
◆实现手机支付进行购买指定线路的汽车票、下发二维码到验证乘车的闭环流程
江门移动“二维码电子票业务”本期项目的主要建设目标包括以下方面：
◆与江门移动手机支付平台进行接口通信，实现话费账户、专用账户和银行账户的在线支付和对账等手机支付功能；
◆与条码凭证平台进行接口通信，实现条码凭证下载和条码凭证验证等功能；
◆与江门汽运售票系统的接口通信，实现最新班次的查询，购票以及数据同步。
◆短信网关的接口通信。
◆支持短信、WAP、WEB方式的最终用户访问，用户可使用任何一种方式，方便灵活的实现二维码电子车票的查询，购买。
◆支持对手机支付和条码凭证业务的灵活数据统计分析。
1.3系统规模
表格1.系统用户数规模
二维码点子票出票量
具体情况
二维码电子票出票数量暂时设定为10万/小时
系统初步的设计10万/小时的出票量。
应该可以满足实际的应用需求。
（经初步压力测试，本地数据库查询同步线程在100的情况下，系统正常稳定。
考虑的与多个接口的数据同步稳定。
系统目前按30个同步线程估算出暂定的出票数量。
）
1.4项目范围
本方案所描述的“二维码电子票业务”业务平台项目建设范围包括以下几个方面：
1.根据第2章所描述的系统网络架构和软硬件体系结构，搭建“二维码电子票业务”业务平台；
2.按照第3章所描述的系统功能，设计和开发“二维码电子票业务”业务平台；
1.5用户特征
根据**公司对“二维码电子票业务”业务平台的理解，系统用户主要分为以下两大类：
3.系统管理员/移动管理员，通过内网访问系统，在“二维码电子票业务”业务平台上负责系统业务管理及日常维护。
4.普通消费者，通过手机sms,wap或者web查询，购买指定线路的班次。
实现手机支付和条码凭证下载等功能。
2系统架构
2.1系统网络架构
2.1.1应用环境
“二维码电子票业务”将部署在江门移动内部网中。
用户对“二维码电子票业务”平台的访问以外网接入为主，通过WEB网站、WAP网站、短信渠道访问系统。
另平台接口服务器与江门汽运售票系统的通信，完全通过接口协议交互同步的数据报文。
并且设有IP限制及防火墙过滤。
系统的安全性和数据的保密性将得到有效的管理及控制。
2.1.2网络架构
根据“二维码电子票业务”平台应用场合要求，建议网络架构如下：
附图1.平台网络结构图
“二维码电子票业务”业务平台由数据库服务器、WEB/WAP应用服务器、接口机服务器构成。
WEB/WAP应用服务器用于部署平台的WEB应用服务和WAP应用服务，为手机移动用户、移动内部员工提供对系统的访问途径。
通过防火墙，确保系统内部设备不受外部系统的侵扰。
应用服务器上部署系统各类业务组件和业务生成引擎，负责所有核心业务的处理。
应用服务器采用PCServer，可以根据业务的开展情况灵活扩展。
数据库服务器负责对平台数据的存取管理工作，采用PC服务器。
接口机服务器用于部署各类接口应用程序，可实现与汽运售票平台等外部系统数据通信，同时也可实现与手机支付业务平台，条码凭证业务平台等内部系统数据通信，也可实现与SMSC,WAP网关等网关系统数据通信。
接口机服务器同时也用作系统数据的冷备份。
2.2硬件配置建议
2.2.1配置依据
2.2.1.1预期用户数
综合考虑客运高峰期并发出票较高的需求以及与各个接口数据同步的安全稳定。
系统暂定10万/小时的出票数量。
2.2.1.2硬件配置要求
从硬件配置的角度，“二维码电子票业务”业务平台需要重点考虑的主要硬件设备包括数据库服务器和WEB/WAP服务器。
5.CPU配置要求
◆数据服务
系统数据服务可以根据峰值用户处理业务的情况来估算。
假设峰值时100人同时在向系统发出请求（假设每个请求的平均响应速度为1秒），系统每秒需处理的事务数则约为100。
考虑到数据服务器CPU25%的冗余和10%用于操作系统运行，则数据处理占用65%的CPU资源。
系统所需TPM-C值（TPM-C值为每分钟处理的事务数）为：
100×60/0.65=9,231。
可见，系统的数据服务器对TPMC值的要求为大于9,231。
主流PC服务器的TPMC值均大于20000，一台主流PC服务器作为数据库服务器应可满足上述计算的需求。
◆WEB/WAP服务
在考虑到应用服务器性能时，我们参考服务器的Specweb99性能参数。
Specweb99是SPEC（StandardPerformanceEvaluationCorporation，公开网址为www.spec.org）组织（非盈利第三方计算机研究评测组织）研发出的一套评测基准程序。
该评测基准主要用来衡量计算机系统在WebServer环境下，所能支持的最大并发连接数，是在保证一定的持续时间、低于一定的错误率等情况下所记录下的最大连接数。
该指标考察的是硬件系统平台、操作系统、WebServer软件等综合各部分的计算机整体系统对Internet并发连接的处理能力。
而测试中的仿真终端具有一定的随机性，可模拟对图标、图片乃至大文件的访问，较为贴近实际应用情况。
由于Specweb99的评测环境虽不等同于本系统的实际业务环境，但可作为相似的参考。
系统并发100个连接用户占用65%的计算能力（考虑到服务器CPU25%的冗余和10%用于操作系统运行），则要求WebServer主机具有的Specweb99值应当大于：
100/0.65=154。
主流品牌1G以上CPU的PC服务器的Specweb99一般都大于1000，可以满足目前的性能需求。
也就是说，系统的应用服务器采用一般主流的PC服务器即可满足需要。
6.服务器内存
和CPU一样，内存的利用也和用户工作量的支持有关，可以参考厂家提供的对应CPU的标准内存配置采购。
系统需要具备快速海量查询的能力，应考虑更大的冗余和更好的性能，采用4G内存容量可以满足数据库服务器的性能需求，而应用服务器则可以采用2G内存容量。
7.服务器硬盘空间
按平台的需求情况，流程处理的数据量应较少，但资料、档案等所占磁盘空间则可能较大。
根据我们平台建设经验，系统业务数据占用的硬盘空间建议不小于72G，操作系统、应用软件和基础业务数据的大小约10G，再考虑25%的空间冗余，即数据库服务器的可用硬盘空间不小于110G。
2.2.2配置建议
根据上节的配置依据，建议为“二维码电子票业务”业务平台配置以下软硬件系统：
表格2.系统软硬件配置
序号
服务器名称
配置描述
数量
1
数据库服务器
配置：
IBMX346，CPU3.0GHZ*2/RAM4G/HD4*73GBRaid5
操作系统：
WindowsServer2003标准版
DBMS：
Oracle9i
1
2
接口机服务器
配置：
CPU3.0GHZ/RAM2GB/HD2*73GBRaid0
操作系统：
WindowsServer2003标准版
DBMS：
Oracle9i
1
3
应用服务器
配置：
CPU3.0GHZ*2/RAM2GB/HD2*73GBRaid0
操作系统：
WindowsServer2003标准版
WEB/WAP应用：
TOMCAT5.0,JDK1.4
1
2.3软件体系架构
软件体系构架为如下图所示的：
附图2.系统软件结构图
“二维码电子票业务”业务平台从设计到开发将完全采用面向对象的技术，并大量采用多种包括Servlet,JSP,JavaBean,JDBC,XML等在内的Java技术。
整体的架构完全遵循Sun公司建议的MVC模式，使得整个体系架构符合e时代企业应用的发展趋势。
采用MVC的方式有许多优点：
8.将表示层（View）和逻辑层（Model）分开的一个优越性，在于容易在某种数据的基础上，增加多种表现或者改变某种形式；
9.逻辑层（Model）以及表示层（View）分开以后，使得它们各自能够独立的变化。
进而使得可维护性，可以扩展性，可测试性方面得到很大的改善；
10.将控制层（Control）和表示层（View）分开，可以动态的决定表示的形式；
11.将控制层（Control）和逻辑层（Model）分开，使得用户的输入和数据处理之间的关系可以灵活决定。
3系统功能说明
3.1系统功能概述
“二维码电子票业务”业务平台功能结构如下图：
附图3.应用功能框架图
系统分为三大主要构成部分：
◆应用功能
平台的应用功能构建于系统核心模块上，由相对独立组件构成。
主要包括手机短信查询购票业务，手机wap查询购票业务，web查询购票业务，以及相应的web后台管理支持系统。
◆基础平台
提供系统底层核心管理功能，包括相应的业务处理模块、数据存储模块、系统管理与监控、报表统计等基础功能。
◆数据接口
实现与内、外部系统的接口通信，完成与内、外部系统的数据交互。
3.2应用功能
3.2.1短信查询购票
用户通过发送指定查询订票信息到指定端口。
或者在系统设计的导航菜单交互的情况下，完成手机短信的查询，订票流程。
最终会通过手机支付接口扣减相应的费用。
通过条码凭证接口下发相应的二维码电子车票至用户手机。
3.2.2Wap查询购票
用户通过手机wap的方式访问相应wap查询订票网站。
在系统设计的导航功能下完成车票的查询购买流程。
最终会通过手机支付接口扣减相应的费用。
通过条码凭证接口下发相应的二维码电子车票至用户手机。
3.2.3Web查询购票
用户通过web的方式访问相应web查询订票网站。
在系统设计的导航功能下完成车票的查询购买流程。
最终会通过手机支付接口扣减相应的费用。
通过条码凭证接口下发相应的二维码电子车票至用户手机。
3.2.4Web后台管理系统
Web后台管理系统主要实现对二维码电子票业务平台运营情况的实时查询，管理功能，包括查看系统当前运行的实际情况，按条件查询用户的具体购票情况。
对指定号码进行重发二维码，短信，察看系统日志，以及各类报表的统计等管理功能。
3.3基础平台
3.3.1业务处理模块
该功能主要完成用户实际使用系统中的各种业务逻辑方面的处理。
包括短信查询购票流程，wap查询购票流程，web查询购票流程。
3.3.1.1短信查询购票模块
该模块完成用户短信查询购票的完整业务逻辑。
用户通过发送指定查询订票信息到指定端口。
或者在系统设计的导航菜单交互的情况下，完成手机短信的查询，订票流程。
最终会通过手机支付接口扣减相应的费用。
通过条码凭证接口下发相应的二维码电子车票至用户手机。
该模块最终完成处会调用手机支付业务接口及条码凭证接口。
3.3.1.2短信购票业务流程图
附图4.购票处理流程图
3.3.1.3短信购票业务事件流
汽运手机购票业务处理事件流如下：
A、用户通过手机编辑具体购票短信指令发送到具体的购票短信端口；
B、移动手机售票前台接收到用户的购票短信指令后，判断购票指令的合法性；
⏹如果购票指令不合法，通过菜单选择的方式引导用户订票；
⏹如果购票指令合法，则通过数据接口向汽运售票系统发送购票请求数据；
C、汽运售票系统根据接收的请求数据包处理购票业务，并响应业务处理结果；
D、移动手机售票前台根据接收的业务处理结果，进行下一步业务操作；
⏹如果购票处理不成功，通过短信方式回复用户购票失败信息，业务操作结束；
⏹如果购票处理成功，进行手机支付合法性校验，如果合法性校验成功，则下发扣费短信确认，如果合法性校验失败，向用户下发扣费失败短信通知并向汽运售票系统请求取消购票操作，业务操作结束；
E、当扣费合法性校验成功后，用户收到扣费短信确认通知后，回复扣费短信确认；
F、移动手机售票前台接收到用户同意扣费的短信确认后，进行手机在线扣费并下发条码凭证到购票用户手机上；
G、用户接收到购票条码凭证后，到车站兑票；
H、汽运售票系统对用户提供的条码凭证做数据检验，校验通过给用户兑现车票；
I、业务流程结束。
相应的，平台除了在连接的手机支付业务接口高效、稳定方面，平台还提供了如下处理机制：
◆接口重连接机制；
当接口出现网络故障时，引擎自动启动重连接处理机制，确保支付过程的畅通。
◆多线程处理机制；
实现多线程处理，提高通信效率，保证数据交互的顺畅。
◆高效缓冲机制；
提供高效缓冲机制，即减少业务繁忙时数据丢失，缓解了高期期接口通信压力。
◆安全性鉴权机制
提供业务接入的账户、密码、接入IP鉴权。
◆按优先级别排队处理机制
提供按预设定的业务接入优先级别对具体业务调用接口的排队机制。
◆用户每次支付金额的上限额度控制机制
提供每次付款金额上限额度控制。
◆同一用户每天支付金额的上限额度机制
提供同一用户每天付款金额上限额度控制。
◆短信提醒功能机制
提供支付过程中的短信提醒功能。
◆处理异常，事务的回滚机制
提供支付异常时，事务回滚机制，确保交易数据的正确性。
3.3.1.4Wap查询购票模块
该模块完成用户Wap上网方式的查询购票的完整业务逻辑。
用户通过Wap登录指定网站，通过系统导航，完成手机短信的查询，订票流程。
最终会通过手机支付接口扣减相应的费用。
通过条码凭证接口下发相应的二维码电子车票至用户手机。
该模块最终完成处会调用手机支付业务接口及条码凭证接口。
相应的，平台除了在连接的手机支付业务接口高效、稳定方面，平台还提供了如下处理机制：
◆接口重连接机制；
当接口出现网络故障时，引擎自动启动重连接处理机制，确保支付过程的畅通。
◆多线程处理机制；
实现多线程处理，提高通信效率，保证数据交互的顺畅。
◆高效缓冲机制；
提供高效缓冲机制，即减少业务繁忙时数据丢失，缓解了高期期接口通信压力。
◆安全性鉴权机制
提供业务接入的账户、密码、接入IP鉴权。
◆按优先级别排队处理机制
提供按预设定的业务接入优先级别对具体业务调用接口的排队机制。
◆用户每次支付金额的上限额度控制机制
提供每次付款金额上限额度控制。
◆同一用户每天支付金额的上限额度机制
提供同一用户每天付款金额上限额度控制。
◆短信提醒功能机制
提供支付过程中的短信提醒功能。
◆处理异常，事务的回滚机制
提供支付异常时，事务回滚机制，确保交易数据的正确性。
3.3.1.5Web查询购票模块
该模块完成用户通过普通WEB上网方式的查询购票的完整业务逻辑。
用户通过WEB登录指定网站，通过系统导航，在通过手机校验码的校验后。
完成手机短信的查询，订票流程。
最终会通过手机支付接口扣减相应的费用。
通过条码凭证接口下发相应的二维码电子车票至用户手机。
该模块最终完成处会调用手机支付业务接口及条码凭证接口。
相应的，平台除了在连接的手机支付业务接口高效、稳定方面，平台还提供了如下处理机制：
◆接口重连接机制；
当接口出现网络故障时，引擎自动启动重连接处理机制，确保支付过程的畅通。
◆多线程处理机制；
实现多线程处理，提高通信效率，保证数据交互的顺畅。
◆高效缓冲机制；
提供高效缓冲机制，即减少业务繁忙时数据丢失，缓解了高期期接口通信压力。
◆安全性鉴权机制
提供业务接入的账户、密码、接入IP鉴权。
◆按优先级别排队处理机制
提供按预设定的业务接入优先级别对具体业务调用接口的排队机制。
◆用户每次支付金额的上限额度控制机制
提供每次付款金额上限额度控制。
◆同一用户每天支付金额的上限额度机制
提供同一用户每天付款金额上限额度控制。
◆短信提醒功能机制
提供支付过程中的短信提醒功能。
◆处理异常，事务的回滚机制
提供支付异常时，事务回滚机制，确保交易数据的正确性。
3.3.2数据存储模块
数据存储模块会记录用户的所有上下行记录，以及相关的手机支付，条码凭证等各个应用环节的完整数据，方便今后的查询，核对。
具体包括以下一些方面
●业务运营具体信息
●交易数据明细（手机支付信息/条码凭证信息）
●系统运行信息
3.3.2.1业务运营具体信息
包括在业务运营过程中用户的具体操作记录，如短信操作的查询/订票过程中的所有上下行互动记录。
以及wap/web查询购票过程中的详细的互动操作记录等。
3.3.2.2交易数据明细
详细完整的记录用户在购票过程的互动记录。
同时包括手机支付信息，条码凭证信息的完整周详记录。
用于后面统计模块的报表统计及后期的数据查询核对。
3.3.2.3系统运行信息
详细完整系统运行日志模块。
后期可以对系统流量，用户操作习惯等进行分析。
用于之后的系统优化及各个具体环节的完善。
3.3.3系统管理与监控
提供“二维码电子票业务”的运营监控管理。
3.3.3.1系统实时票务查询
后台提供二维码电子票业务的实时运行状态。
管理员也可立即实时查询指定用户的使用情况。
一种用途是客服通过查询该系统知道客户查询订票的实际情况。
根据具体情况进行补发二维码彩信或短信等具体操作。
3.3.3.2业务异常监控
提供“二维码电子票业务”业务平台上所接入合作业务处理异常的日志查询，数据监控分析。
3.3.3.3业务高峰期监控
通过分析“二维码电子票业务”业务平台所接入合作业务受理事务日志和系统运行日志，监控各类合作业务高峰期运行情况，并可设置预警。
协助系统管理员及时解决故障。
3.3.3.4运行日志管理
系统管理员可对业务运行日志进行分类管理、查询、导出。
3.3.4统计分析
提供固定格式的统计报表，实现对系统数据查询、统计的后台处理功能，在此基础上实现对业务数据的查询和统计分析。
3.3.4.1统计报表
用户的所有短信，wap购票数据的详细信息都已完整记录入数据库。
前期会提供以下一些基本的关键统计报表（实际情况可根据客户需求增加其他方式的统计报表）：
◆平台业务明细统计（按时间段，始发站等具体条件）；
◆系统总运行情况统计（按时间段统计各接入业务信息传递流量。
）；
3.3.4.2查询引擎
查询功能的内部核心组件，解释查询条件与业务数据等系统数据源之间的关系，从而实现对系统数据的查询和统计功能。
3.4数据接口
3.4.1接口情况概述
本期项目“二维码电子票业务”业务平台所需接入的主要业务接口如下：
◆手机支付业务平台接口
◆条码凭证业务平台接口
◆短信网关接口
◆江门汽运售票系统接口
3.4.2手机支付业务平台接口
“二维码电子票业务”业务平台与手机支付业务平台通过数据接口实现手机在线支付功能。
◆交易步骤：
1.在得到用户确认的情况下，通过HTTPPOST提交交易请求数据，发送到MPS交易处理系统。
2.MPS处理交易请求，并回复处理结果。
3.SP接收MPS回复结果，并解析结果作相应的交易处理。
3.4.3条码凭证业务平台接口
“二维码电子票业务”业务平台与条码凭证平台通过数据接口实现条码凭证下载功能。
◆交互步骤：
1.“二维码电子票业务”业务平台向条码凭证业务平台发送条码凭证下载请求。
2.条码凭证业务平台接收到“二维码电子票业务”业务平台的请求消息后，进行信息反馈，并通过彩信方式下载条码凭证彩信给目标用户。
3.“二维码电子票业务”业务平台对记录条码凭证业务平台反馈回来的业务信息，为条码凭证兑现过程中与特约商户进行条码凭证合法性校验做准备。
4.短信网关接口
3.4.4短信网关接口
通过移动CMPP协议，以移动互联网短信网关通信，实现用户在指定端口的短信的上下行短信的交互。
3.4.5江门汽运售票系统接口
“通过之前与江门汽运确立的交互报文，实现查询，订票数据的交互与同步。
该接口支持短信，wap，web三种查询方式。
4系统设计原则
4.1设计特点
12.面向对象设计
在系统设计方面，采用先进的面向对象设计方法（OOD），借助强大的面向对象的可视化分析、设计建模工具，对系统需求、业务处理过程、企业运作所必备的商业对象、软件组件、系统结构和对象进行可视化建模，使应用更贴近实际业务需求。
13.参数化驱动
移动业务系统要求具有较高的灵活性，以适应业务多变的特点。
设计时采用参数化驱动的实现方法，将可能变化的因素统一参数化管理和维护，当参数变化时只维护这些参数表而无需更改应用软件，并且系统将在不停机情况下动态地调整这些参数。
保证较短的时间内，响应业务需求经常变化的要求。
4.2安全性
系统具有良好的安全性和可靠性，通过权限管理机制保证数据不被非法盗用和修改，保证数据的一致性；对非法登录或系统故障能采取多种检查和处理手段；采用故障检查、告警和处理机制，保证数据不因意外情况丢失和损坏。
系统具有良好的安全管理功能，数据存储、检索、提取、发布和管理等各个层面和角度都须具有相应的安全机制，并确保达到以下要求：
◆可分级进行权限管理；
◆能设置角色权限，可以定义角色以及角色对应的权限；
◆提供完整的操作日志，提供数据库存储日志接口/功能；
◆系统本身稳定；
◆用户活动的可审计性，提供良好的事后追查能力；
◆符合移动IT安全策略和标准；
◆系统具备访问权限的识别和控制功能，提供多级密码口令或使用硬件钥匙等选择和保护措施；
◆系统提供操作日志记录功能，以便即时掌握运行状况；
4.3可靠性
系统运行具有极高的可靠性和良好的容错性能，因软件系统自身原因（排除硬件、网络、数据库、中间件故障）导致系统局部功能短暂不可用的次数每月平均不超过1次；应用系统MTBF（平均失效间隔时间）部低于2000小时（不包括因网络、主机硬件、数据库、中间件故障导致系统不可用导致的系统失效）。
4.4易用性
◆提供丰富的联机帮助提示和上下文有关的在线帮助；
◆系统应易于使用，具有良好的客户操作界面、详细的帮助信息，适合具有计算机基本知识或操作能力的用户的需要；
◆系统安装部署简单方便；
◆系统确保良好的兼容性，不需要或较少补丁包；
◆界面布局及内容符合使用人员的思维习惯，容易理解，容易学习；
◆更新操作有反馈，系统将提供各类操作提示；
◆危险操作有警告提示，除告警之外，系统将通过完善的权限管理确保数据的安全性；
◆系统易于管理，系统参数的维护与管理通过操作界面实现。
4.5可扩展性
系统采用模板的方式处理数据，可以灵活的适应业务的变化，此外，系统还将满意以下的扩展性要求：
◆易于版本升级，新的功能和模块能够加入；
◆易于增加功能；系统扩展新的功能时，不会影响到其他功能模块。
4.6可维护性
◆有标准日志文件，数据可备份、恢复；
◆能
升级会员 