一种基于微服务的统一票务管理系统

黄 凯,罗 陈

(上海科技馆 上海 200127)

0 引言

传统票务系统不同模块采用不同技术架构进行搭建,单个模块升级迭代都会影响到其他模块业务和数据,模块不方便独立设计和上线,使用起来十分烦琐,开发和运维的工作量大。为了降低用户使用难度,提高平台集群化管理能力,因此需要对老旧系统进行改造[1]。

系统软件架构的设计不仅关系到系统能否正确运行,同时也决定系统未来新功能迭代过程是否顺利。历史票务系统多采用集中式架构设计,虽然设计简单,但是难以满足时代发展需求,随着信息技术更新迭代的出现,弊端逐渐显现。因此,本文在微服务的系统架构下,设计了一套基于微服务的统一票务集群管理系统,此系统便于项目进行快速迭代和上线,不仅符合数字化管理需求的,而且有助于提升系统的总体性能[2]。

1 研究背景和目的

针对现有的展馆票务业务流程及运营难点进行研究,发现各票务模块采用不同的技术架构进行模块建设,本文所述系统通过构建统一微服务票务管理框架,提供全面技术支撑和安全保障。由于老旧系统改造的工作量巨大,因此采取分布改造的方案[3]。现有场馆底层业务继续采用原有BS架构或者CS架构,构建成一套独立服务对业务进行抽象封装,并对外提供接口能力,保证和满足用户实际使用需求,后续再进行内部重构和优化,且不影响系统总体运行。

对于集群化运营的不同场馆之间的管理需求,该系统提供统一平台、分层授权、属地化运营管控的票务管理,只需要在系统后台进行统一管理设置,同时该系统也支持各展馆按照自身运营实际情况,设置本馆自身的业务参数规则、票务产品信息等一系列运营管理规则,为各个展馆保留了完整而独立的业务管理功能[4]。系统在主馆通过统一互联网出口提供公众服务,在遇到馆间网络中断的情况下,采用属地化应急备份系统来代替,需要保证不影响游客的购票、取票及检票入馆和观看电影。

整个系统采用分布式架构设计,任意一个系统节点的中断都不会导致多场馆的业务中断。单场馆票务核心部署在各自展馆的本地机房中,通过中间机房,最终构建一个统一的一体化票务平台,实现对内统一管理和对外统一服务的目的[5]。整个系统采用统一服务对数据进行集中式处理和分布式部署,针对用户采用分层授权策略来保证系统数据

2 系统总体应用架构设计

本文所研究的一种基于微服务的统一票务管理系统利用微服务技术进行系统构建,多场馆系统统一采用管理架构和集群化运行机制。针对各个展馆的不同展出内容、游客动线、业务细节的不同,各个展馆运营部门需要按照自身运营实际情况进行管理,系统需要支持各展馆自行设置本馆业务参数规则、票务产品信息等一系列运营管理规则,因此各个展馆保留自身完整而独立的业务管理功能是重要需求。根据以上需求进行系统架构设计,系统主要由四层进行构建,即应用层、服务层、数据层和系统层。系统的总体架构设计图,如图1所示。

图1 系统总体架构图

从图1可知,应用层主要对用户提供多渠道小程序、Web和PC等主流前端交互页面。业务分别应用部署在取票机系统、闸机系统和业务前端业务等用户交互场景中。应用层统一采用Nginx进行反向代理服务设置。服务层主要针对业务系统和通用系统进行服务能力封装并且进行业务能力输出,业务系统主要是指票券业务、供应商业务和终端业务等等[6]。通用业务主要是OTA服务、支付系统、监控系统和日志系统等等。数据层主要负责系统中数据业务相关处理,系统数据库采用主流的MySQL和MongoDB进行设计,数据中间件采用Redis、Kafka和Zookeeper等,主要用于处理经常需要读取而不是写入的数据并缓存在Redis中,如场馆场地信息、票务信息、场次信息等,以此加快系统的处理效率。

该票务系统为了防止库存超卖的分布式事务锁、配置数据的同步等操作交给Zookeeper。数据存储及中间件主要由数据库、中间件、大数据三部分组成,是系统所有的核心数据所在,且为将来大数据挖掘和分析提供数据基础。另外系统还集成大数据处理能力,后期可以进行数据分析和利用数据预估场馆流量等分析内容[7]。大数据主要使用Hadoop和Spark主流框架进行构建。系统层是直接和硬件服务进行交互的,硬件底层需要保证系统的稳定性、安全性、通用性和易维护性的要求,统一采用JAVA开源开发环境,运行在Ubuntu或Centos等Linux操作系统环境下,采用开源软件保证后续系统的安全运行。

3 系统模块设计

本文所研究的一种基于微服务的统一票务管理系统采用微服务技术对票务系统进行模块化设计,在保证多系统平稳运行的情况下,保证系统可以进行业务快速迭代开发,并且兼顾满足不同场馆票务个性化要求。

3.1 系统核心功能模块

多场馆票务系统之间架构连接主要由网售系统、数据中心系统、后端支撑系统和用户中心系统组成,相关的应用统一部署在主馆的机房,这也是从安全角度出发,毕竟外网的安全级别低、容易受到攻击,内网的安全级别要求高,因此提供统一的对外网络出口以及对内服务,有效保护各馆底层票务系统的安全[8]。具体部署的应用还包括自营票务业务、OTA渠道售票应用和自营分销渠道售票应用、公共服务系统等等。具体的系统多场馆应用架构,如图2所示。

图2 系统多场馆应用架构图

主馆所需的票务核心系统均部署在主馆机房,包括票务系统、票检系统、本馆结算系统等,本地的所有票务硬件设备通过局域网与相应的系统进行联通,保证安全稳定,同时在馆间网络故障时仍然能支持本地化现场票务服务[9]。具体的系统模块应用关系图,如图3所示。分馆也需要在本馆部署相关备份系统业务,同时为保证数据安全,数据库设置预定备份策略并进行本地备份,有条件可做异地备份。数据访问严格按用户级别授权对数据进行访问,关键数据的修改记录应记录详细的操作日志,以备后续追查。数据传输与关键的敏感数据存放进行一定的加密处理,以防用户误操作和介质失效而造成的数据损失。

图3 系统模块应用关系图

3.2 系统技术架构

系统核心技术架构主要由三部分进行组成,分别是网络接入、中间件和大数据。具体的系统技术架构,如图4所示。票务系统的网络接入主要选择LVS和Nginx作为负载均衡服务,保证更大的访问并发量。中间件主要使用分布式文件系统,对文件进行管理,功能包括存储、同步和访问等,解决大容量存储和负载均衡的问题。票务系统把处理频繁和经常需要读取而不是写入的数据缓存在Redis中,如场馆场地信息、票务信息、场次信息等,以此加快系统的处理效率。大数据层需要保证数据高可靠性、高性能的结构化数据分布式存储系统,Hbase 随着数据量增多可以通过节点扩展进行支撑[10]。因此票务系统把HBase当做存历史数据的平台,业务流程上除了订单数据库外,还有其他交易相关的数据库,它们都有同一个问题,容量很容易爆满,为了将HBase发挥更大的用处,在特定的场景下,比如几个月前的历史数据,就会先从HBase查寻,将其写入MySQL,核心的交易流程和支付流程直接在MySQL做,这样对业务的影响最小,方便业务操作,提升总体数据处理效率[11]。

图4 系统技术架构示意图

4 统一票务系统应用

和传统票务系统相比,统一票务系统接入了主流渠道“小程序”应用,提升了游客购票的便捷度与友好度,用户无需下载App应用进行即可使用。另外系统采用图形验证码、统一账号管理、检票直接使用身份证验证,限制了黄牛运用刷票软件刷票、倒票的行为。系统的购票全流程都可以在线上进行,实现了预约、下单、出票全程无纸化操作,业务管理工作人员直接使用电脑或平板设备来进行现场游客信息确认,极大地提高了工作效率。同时系统后台可以查询和报表实时知晓现场的进馆情况。为了打通用户的支付渠道,系统支持多种支付渠道,包括但不限于微信、支付宝、云闪付等常见支付方式,有助于改善游客购票付款的使用体验,并减轻了财务每日在后台需要进行多账户人工对账的工作量[12]。具体的统一票务实际小程序使用效果图,如图5所示。

图5 统一票务实际使用效果图

与传统的票务系统比较,多场馆票务资源的整合可以给用户的使用体验方面带来质的提升,用户无需进行多系统注册,使用一个账号即可完成多场馆购票服务。为了保证安全和公平,购票统一使用实名制购票,对票务进行统一限制,同时系统还会对用户特殊证件进行校验,保证不同证件类型用户可以享受自有的权益。另外,游客在进馆时使用身份证或者小程序中的票据二维码在闸机检验,用户系统进行身份核验和场馆人员记录管理,系统所记录和统计的场馆内游客数量可以供管理人员进行场馆管理和采取相对应的服务预案,根据游客数量进行流量控制,保证场馆运行安全和游客的安全。

5 结语

针对传统票务业务冗余,更新复杂的问题,本系统采用微服务即使,搭建了四层整体架构设计。其中应用层用来给用户提供各种交互入口,不同的交互入口彼此独立对应不同的数据库和系统层。这些数据层经由服务层进行统一封装,搭建成为统一的入口,入口内包含不同的模块界面,为用户提供多种交互。该系统实现有助于为用户提供统一业务平台,减少业务冗余,便于后期升级。该系统目前已经在上海科技馆上线使用,上线至今为数十万用户提供便利。