一 票务平台业务需求

去电影院看电影，大家应该都经历过。以前看电影前需要在电影院门前的售票窗口买票，然后持票进入影厅。如果是热门电影，则需要提前排队买票，这非常不方便。

现在电影票的购票形式便捷且多样：既可以在美团、猫眼、淘票票、豆瓣等网站直接购买，也可以在各家影院的App上购买，还可以在电影院窗口购买或是在自助售票机上购买。

电影院、影厅、影片还有电影票是如何管理的呢？这需要一套完整的电影院综合票务管理平台来实现上述各项内容的管理工作。

一套完整的电影院综合票务管理平台包含多个业务子系统，同时会涉及很多用户，分别是观众、电影院售票员、影院经理、院线管理人员、网络代售人员等。图2-51简单描述了票务管理平台的用户和操作用例。

图2-51 票务管理平台用户和操作用例

二 票务平台行业规范

作为一个系统分析师，想要实现一套完整的电影院综合票务管理平台，首先要非常清楚地了解关于电影院票务平台的行业规范，这是实现这个系统的必要前提。

在做其他系统的时候也如此，如银行系统、电信系统、石油系统、广电系统、航天系统、烟草系统等，每个业务系统都有自己所属的行业，也都有国家关于这个行业的统一规范要求。

2013年12月31日，国家新闻出版广电总局发布了《电影院票务管理系统技术要求和测量方法》，下面摘取部分核心内容来帮助大家了解如何实现整个票务平台。

图2-52所示是电影院综合票务管理平台的整体框架图，下面简单说明各部分的含义。

图2-52 电影院票务管理平台整体框架图

（1）“电影院票务管理系统服务器1～n”是指院线的票务系统服务器，中国有很多院线，如“万达电影”“大地院线”“联合院线”“中影南方新干线”“星美院线”“时代院线”“中影数字”等。

影片播放的权利主要在院线，即电影拍好后，投资方会和院线合作，由院线安排上映时间。

（2）“售票终端1～n”主要指电影院前台售票窗口。每个电影院都有所属的院线，一般为加盟店形式。电影院通过售票终端（App或Web站点）连接院线的服务器，实现售票操作。

（3）“自助取票机”连接院线服务器，打印当前电影院的影票。

（4）“授权管理机构电影票务数据平台”是当时国家新闻出版广电总局搭设的数据中心，所有影片信息必须在数据平台先登记，才能在票务系统中看到。售票终端的出票信息，也要及时传递给数据平台进行统一监管。

（5）“网络代售终端”指的就是猫眼、豆瓣、美团这些网络售票代理机构，它们需要和院线合作，网络代理和院线是多对多的关系，即一个院线可以由多家网络代理；而一个网络代理也可以同时和多家院线合作。

注：本节案例仅为了学习架构设计技术，如与现行规范、平台不一致，读者设计时可自行调整相关内容即可。

1．适用范围

本标准规定了用于电影院票务管理系统中的电影院编码、影片编码、基本功能及数据交换方式等内容。

本标准只对与电影院票务管理系统相关的功能及数据接口提出了基本要求和测量方法。

本标准适用于放映电影的电影院（含影剧院、俱乐部等场所）票务管理系统和与其进行数据交换的其他系统。

2．术语和定义

·　授权管理机构电影票务数据平台：由国家电影行政主管部门授权管理机构对电影院票务数据和电影院票务管理系统进行管理的软件平台。

·　电影院票务管理系统：能够完成电影院票务管理的售票系统。

· 电影票网络代售：除电影院现场售票外通过网络向观众出售电影票。

·　电影票网络代售终端：所有使用本标准附录A网络代售接口通过网络连接电影院票务管理系统进行售票的系统，统称为电影票网络代售终端。

·　影片编码：由12位具有特定含义的数字字符组成。一组数字字符的组合所特指的影片具有唯一性。影片编码由授权管理机构提供并通过授权管理机构电影票务数据平台获取。

·　电影院编码：由8位数字字符组成，它所代表的电影院在全国范围内是唯一的。由授权管理机构提供。

·　电影票编码：由16位数字字符组成，唯一标识一张电影票。

·　电影票信息码：记录了一张电影票相关信息的二维码。

·　电影票价：观众支付的观看电影的直接费用。

·　影厅：单块银幕的固定电影放映场地。

·　电影院：由一个或多个影厅组成的场所。

·　电影票：观众进入电影院观看电影的凭证。

· 座位：单座：单人座位。双座：双人座位，统计时按2人计，售票时，出2张票。包厢：2人（包括2人）以上的多人座位，按人统计，按人出票。

·　影片：供观众当场观看的内容。

·　营业日期：指电影院的实际工作日。

·　场次：一部影片在一个影厅的一次完整放映过程。

· 放映计划：电影院根据需要，确定、安排拟放映的影片名称、时间、影厅以及票价等项目。

·　分账比例：与影片发行各方就票房收入进行分配的比例，此处指票房收入中需要上缴各方百分比之和。

· 连场：在同一个放映厅内，凭单张票可连续观看多部影片的特殊电影场次。

·　售票：电影院对观众观看电影的销售行为，电影票为收费凭证。

·　预售：电影院向观众销售未来营业日电影票的行为。

·　自助取票机：通过验证观众提供的二维码或特定的数字凭证自助打印电影票的设备。

·　优惠票：票价低于影院公开挂牌零售票价的电影票。

·　售票原始数据：一张电影票票面所包含的数据。

·　退票：因为某种原因取消观看电影而引起的退还票款行为。

· 补登：电影院由于机器故障等意外原因导致不能使用电影院票务管理系统售票，在系统修复前使用手工出售代用票，在系统恢复后将票务信息补录到电影院票务管理系统中的行为。

·　统计数据上报：将票务数据以营业日为统计单位依照本标准规定的格式传送到授权管理机构电影票务数据平台的行为。

·　原始数据上报：将售票原始数据依照本标准规定的格式传送到授权管理机构电影票务数据平台的行为。

·　票务监管：授权管理机构电影票务数据平台通过现场或网络登录方式进入电影院票务管理系统取得指定票务数据的行为。

·　营业状态：指电影放映场所进行电影放映经营活动的状态。

·　营业零票房：指电影院在单个营业日的正常营业中未产生票房。

·　电影院公钥：是指在电影院票务管理系统中非对称加密算法密钥对中的公开密钥。

·　电影院私钥：是指在电影院票务管理系统中非对称加密算法密钥对中电影院使用的非公开密钥。

·　数字签名：以电子形式存在于数据信息之中的，或作为其附件的或逻辑上与之有联系的数据，可用于辨别数据签署人的身份，并表明签署人对数据信息中包含的信息的认可。

3．缩略语

·　HTTP超文本传输协议（Hypertext Transfer Protocol）。

· HTTPS安全超文本传输协议（Hypertext Transfer Protocol overSecure Socket Layer）。

·　IP互联网协议（Internet Protocol）。

·　LSB最低有效字节优先（Least Significant Byte）。

·　MD5信息摘要算法5（Message Digest Algorithm 5）。

·　MSB最高有效位优先（Most Significant Bit）。

·　PKCS公钥加密标准（Public-Key Cryptography Standards）。

· RSA一种以三个发明人名字命名的非对称加密算法（Ron Rivest、Adi Shamir和Leonard Adleman）。

·　SHA1安全哈希标准1（Secure Hash Standard）。

·　SOAP简单对象访问协议（Simple Object Access Protocol）。

·　TCP传输控制协议（Transfer Control Protocol）。

·　TLS传输层安全协议（Transport Layer Security）。

·　TMS影院管理系统（Theater Management System）。

·　XML可扩展标记语言（Extensible Markup Language）。

·　XSD XML结构定义（XML Schemas Definition）。

4．基本业务规则

·　场次计数规则：1部影片放映1次计1个场次。

·　出票规则：电影院票务管理系统根据电影院座位数，实行1人1票的出票规则。

·　观众计数规则：计观众人次。1名观众看1场电影计1人次，1名观众看3场电影计3人次，以此类推。

·　影片编码规则：影片编码规则应符合本标准附录B的要求。

·　电影院编码规则：电影院编码规则应符合本标准附录C的要求。

·　营业日期：电影院的营业日期用于统计上报时限定每日的统计时间段，特指定为当日上午6点至次日上午6点（不含次日上午6点）。

其他规则略。

三 票务平台整体架构设计

图2-53所示是电影院票务系统与外部系统之间的接口设计架构图。

图2-53 电影院票务系统与外部系统的接口

（1）“电影院票务管理系统”是各大院线独立搭建的业务系统，核心功能有影院信息管理、影片信息管理、放映计划管理、售票、退票、补登、验票、数据处理等。

（2）“授权管理机构电影票务数据平台”是官方授权的院线统一管理中心，各大院线的影厅信息、出票信息、影片信息等都需要统一登记在授权中心。

（3）“影院管理系统”是指电影院工作人员使用的业务系统，主要功能有影厅设置、座位设置、票价设置、出票、退票、出票统计等。

（4）“网络代售终端”为猫眼、美团、淘票票等网络代理。

（5）“自助取票机”一般放置在各电影院门前。

电影院综合票务管理平台的整体开发架构如图2-54所示。这里面主要有三大业务系统，分别为院线票务系统、网络代售系统、授权管理平台。注意：这三大业务系统由各个不同的团队独立开发部署，但是三大业务系统的数据需要实时交互，因此彼此之间需要经常沟通具体接口调用方式。

图2-54 电影院综合票务管理平台整体开发架构

简单估算，全国共有院线50多家，电影院12 000家。2018年全国观影人次为17.16亿人次，2019年为17.27亿人次。2020年受疫情影响，总观影人次为5.41亿，累计场次达5654万次，票房收入200多亿元。

通过全国购票次数统计，可以知道这三大业务系统每天都需要面对很大的并发压力，因此服务层使用Dubbo集群（比Spring Cloud集群有更好的性能优势）；院线票务系统和网络代售之间在公网交互，设计为MOM消息通知或URL回调通知方式；院线票务系统与授权管理平台使用Web服务或TCP接口调用。

四 院线票务系统架构设计

院线票务系统的开发架构如图2-55所示。

（1）服务层为Dubbo服务器集群，所有核心的票务处理逻辑都在这个模块实现。

（2）图中的前台Web-Server是院线提供的订票系统，普通用户可以直接访问这个系统进行订票，它是Dubbo服务的客户端，通过调用院线的Dubbo服务实现网上订票。

（3）图中的后台Web-Server影院管理系统，院线管理人员和电影院工作人员通过影院管理系统调用Dubbo服务，完成影厅设置、座位设置、票价设置、统计分析等功能。

（4）不同院线的票务系统开发架构不同，但是所有院线系统都必须满足《电影院票务管理系统技术要求和测量方法》中的规范要求。

（5）院线票务系统接收到授权管理平台的影片上线信息后，通过消息中间件或URL回调方式通知网络代售系统（一个院线会签约多家网络代售）。

网络代售接收到院线的消息通知后，主动调用图2-55中的Web服务接口，读取需要的数据。

图2-55 院线票务系统开发架构

（6）院线票务系统与其他系统的接口描述在后面详解。院线票务系统之间完全独立，没有任何交互。

五 网络代售系统架构设计

如图2-56所示为网络代售的开发架构参考，服务层仍然推荐使用Dubbo集群，也可以考虑使用Spring Cloud集群。

像猫眼、美团等网络代售，会同时签约多家院线。院线影片上线，会及时发送消息通知网络代售，不同的院线消息通知方式不同。

网络代售接到消息通知后，调用院线的Web服务接口进行数据更新。

网络代售前台服务器：猫眼、美团等网络代售平台的会员或注册用户，登录前台服务器，然后下单订票。

图2-56 网络代售开发架构

网络代售后台服务器：网络代售管理人员，登录后台服务器，然后调用Dubbo服务完成订票、退票等业务信息的统计与查询。

六 院线票务系统与授权管理平台接口设计

院线票务系统与授权管理平台之间的接口分为两部分，分别为“信息数据接口”和“票房数据统计上报接口”，架构如图2-53所示。

院线票务系统通过调用“信息数据接口”上传影院、影厅、上映计划、售票、退票等信息，同时调用“信息数据接口”获得影片详细信息。

院线票务系统通过调用“票房数据统计上报接口”，要求所有电影院以营业日为统计单位，把每天的营业数据上报给授权管理机构、院线及影片的特定发行商。

1．信息数据接口设计

信息数据接口是“院线票务管理系统”与“授权管理机构电影票务数据平台”之间进行数据通信的接口。

在信息数据接口中规定授权管理机构电影票务数据平台作为服务器端，电影院票务管理系统作为客户端。由服务端发送、客户端接收的报文称作服务端报文，由客户端发送、服务端接收的报文称作客户端报文。

电影院使用专线、光纤或ADSL等方式接入互联网后，通过互联网连接“授权管理机构电影票务数据平台”。

在网络层应采用符合RFC791标准的IP。在传输层应采用符合RFC793标准的TCP，使用8000端口号。链路安全采用符合RFC2246的TLS1.0版本双向验证方式。在一般情况下采用长连接方式，当连接断开后重新连接应重新进行身份认证。

报文通信采用停等机制，如果报文发送后30s无响应报文，发送端重发报文，超过3次无响应则认为链路断开，报文发送失败。

客户端与服务器的交互模式设计为基于TCP/IP的Socket通信方式，因此需要规定数据交互的报文结构。具体报文的结构设计如表2-2所示。

表2-2 院线与授权管理平台的报文结构

对表2-2中数据说明如下。

sync_tag：同步标记，内容固定为十六进制<0xAA 0x55>。

version：版本，描述协议版本，当前版本为<0x01>。

packet_length：报文总长度，从sync_tag第一字节开始到CRC16的最后一字节结束的长度。

payload_id：协议体标识，标识报文中协议体内容数据结构类型，取值如表2-3所示。

表2-3 协议体标识取值范围

注：具体报文数据结构，参见“电影院计算机票务管理系统软件技术规范”。

服务端报文：指授权管理平台发给院线票务系统的报文，主要有影院信息数据结构回应、影片信息数据结构回应、影厅信息查询、影厅座位信息查询、放映计划查询、售票原始数据查询、票房统计上报数据查询等。

客户端报文：指院线票务系统发给授权管理平台的报文，主要有影院信息请求、影片信息下载请求、影厅信息数据结构回应、影厅座位信息数据结构回应、放映计划信息数据结构回应、售票原始数据上报、售票原始数据结构回应、票房统计上报数据结构回应等。

2．票房数据统计上报接口设计

“票房数据统计上报接口”是指电影院以营业日为统计单位，把每天的营业数据上报给授权管理机构、院线及影片的特定发行商。

电影院可以使用专线、光纤或ADSL等方式接入互联网后，通过互联网连接数据接收端。

在网络层应采用符合RFC791的IP。在传输层应采用符合RFC793的TCP，使用7000端口号。安全链路采用符合RFC2246的TLS1.0双向验证方式，在安全链路基础上使用符合RFC2818的HTTPS协议。

票房数据统计上报一般由发送端（即影院端）发起连接，接收端（即授权管理机构、院线或影片特定发行商）在建立连接的过程中确认发送端身份。

连接建立之后发送端使用post方法提交票房数据，接收端在处理之后返回数据接收状态。完成之后由发送端断开连接，此外特别情况下接收端可以在任何时间主动断开连接，例如：服务器负载过大、客户端有攻击服务器的嫌疑时。

报文通信采用停等机制，如果报文发送后60s无响应报文，发送端重发报文，超过3次无响应则认为链路断开，数据上报失败。

票房数据统计上报通信协议由XML数据格式进行组织，包括两条协议报文，分别是票房数据上报和数据接收状态。

“授权管理平台”与“院线票务系统”是在公网交互，而且“票房数据统计上报接口”的数据格式为XML，因此“票房数据统计上报接口”的代码实现可以采用Web Service，具体操作需要与“授权管理平台”进行协商。

七 院线票务系统与影院管理系统接口设计

影院管理系统（TMS）与院线票务系统的接口简称TMS数据接口，架构示意如图2-53所示。

TMS数据接口应是符合GY/T 247—2011附录A票务管理系统SOAP通信协议要求的数据接口。附录中定义的数据交换文件格式为SOAP，基于XML的数据格式。

XML数据格式使用命名空间来定义XML中元素的作用空间。SOAP中定义的数据交换格式，使用的命名空间为。

由于Web Service支持多种语言平台，因此在进行接口定义时需要使用WSDL规范的XML格式。

1．getFilms命令定义

电影院通过TMS数据接口读取所有的影片信息，接口描述如下。

getFilms命令的返回值定义如下。

2．getSchedules命令定义

电影院通过TMS数据接口，读取指定电影院在某段时间内的影片播放计划，接口描述如下。

getSchedules包含TheatreCode、BeginDate、EndDate 3个参数。

getSchedules 中 的 TheatreCode 参 数 用 来 描 述 影 院 的 编 码 ， 类 型 为string。

getSchedules中的BeginDate参数用来描述放映计划的开始时间，类型为string。

getSchedules中的EndDate参数用来描述放映计划的结束时间，类型为string。

getSchedules命令的返回值定义如下。

八 院线票务系统与网络代售系统接口设计

网络代售系统接口是院线票务系统的一个网络服务，网络电影票务运营商的网络代售终端可通过该接口实现影院、影厅、座位、影片、放映计划和订单等信息的查询，并支持锁定、售票和退票等票务操作功能。

接口采用符合W3C的SOAP Version 1.2协议，数据格式为XML。SOAP请求采用HTTPS POST，使用9000端口。

1．QueryCinema接口定义

查询影院基础信息的代码为：<QueryCinema CinemaCode="影院编码"Id= "ID_QueryCinema"/>，它有如下两个参数。

· CinemaCode属性描述了电影院编码，是必要属性，字符串类型，格式为8位定长字符串。

· Id属性是QueryCinema元素的标识，是必要属性，字符串类型，Id属性值固定为ID_QueryCinema，用于在Signature签名元素中标识对QueryCinema元素进行签名。

QueryCinema的返回数据为QueryCinemaReply元素，返回数据的格式参考如下。

2．QuerySeat接口定义

查询影院某影厅的座位信息的代码为：<QuerySeat CinemaCode="影院编码" ScreenCode="影厅编码" Id="ID_QuerySeat"/>，QuerySeat共有如下三个参数。

· CinemaCode属性描述了电影院编码，是必要属性，字符串类型，格式为8位定长字符串。

· ScreenCode属性描述了影厅编码，是必要属性，字符串类型，格式为16位定长字符串。

· Id属性是QuerySeat元素的标识，是必要属性，字符串类型，Id属性值 固 定 为 ID_QuerySeat ， 用 于 在 Signature 签 名 元 素 中 标 识 对QuerySeat元素进行签名。

QuerySeat返回QuerySeatReply元素，返回的XML格式示例如下。

网络代售系统与院线票务系统的其他接口参考GY/T 276—2013规范描述。

3．QueryFilm接口定义

查 询 电 影 院 在 一 段 时 期 中 上 映 的 影 片 信 息 的 代 码 为 ： <QueryFilmStartDate=" 开 始 日 期 "EndDate=" 结 束 日 期 " Id="ID_QueryFilm"/> ，QueryFilm元素有如下三个属性。

· StartDate属性描述了公映日期查询开始日期，是必要属性，日期类型。

· EndDate属性描述了公映日期查询结束日期，是必要属性，日期类型。

· Id属性是QueryFilm元素的标识，是必要属性，字符串类型，Id属性值 固 定 为 ID_QueryFilm ， 用 于 在 Signature 签 名 元 素 中 标 识 对QueryFilm元素进行签名。

QueryFilm返回的XML数据示例如下。

4．QuerySession接口定义

查询电影院的放映计划信息的代码为：<QuerySession CinemaCode="影院 编 码 " StartDate= " 开 始 日 期 " EndDate=" 结 束 日 期 "Id="ID_QuerySession"/>，QuerySession元素有如下四个属性。

· CinemaCode属性描述了电影院编码，是必要属性，字符串类型，格式为8位定长字符串。

· StartDate属性描述了开始日期，是必要属性，日期类型，格式：yyyy-MM-dd，以自然日为准。

· EndDate属性描述了结束日期，是必要属性，日期类型，格式：yyyy-MM-dd，以自然日为准。

· Id属性是QuerySession元素的标识，是必要属性，字符串类型，Id属性值固定为ID_QuerySession，用于在Signature签名元素中标识对QuerySession元素进行签名。

QuerySession返回的结果XML数据格式如下。

5．QuerySessionSeat接口定义

查 询 某 放 映 计 划 的 座 位 状 态 信 息 的 代 码 为 ： <QuerySessionSeatCinemaCode="影院编码"SessionCode="放映计划编码" Status="座位售出状态" Id="ID_QuerySessionSeat"/>，QuerySessionSeat有如下四个。

· CinemaCode属性描述了电影院编码，是必要属性，字符串类型，格式为8位定长字符串。

· SessionCode属性描述了放映计划编码，是必要属性，字符串类型，格式为16位定长字符串。

· Status属性描述了座位售出状态，其值为基于字符串的枚举类型，取值为：All，所有；Available，可售出；Locked，已锁定；Sold，已售出；Booked，已预订；Unavailable，不可用。

· Id属性是QuerySessionSeat元素的标识，是必要属性，字符串类型，Id属性值固定为ID_QuerySessionSeat，用于在Signature签名元素中标识对QuerySessionSeat元素进行签名。

QuerySessionSeat返回的结果数据格式如下。

6．LockSeat接口定义

座位锁定后只有锁定该座位的终端可以对该座位进行出票操作。

LockSeat元素有两个属性，一个子元素。

· CinemaCode属性描述了电影院编码，是必要属性，字符串类型，格式为8位定长字符串。

· Id属性是LockSeat元素的标识，是必要属性，字符串类型，Id属性值 固 定 为 ID_LockSeat ， 用 于 在 Signature 签 名 元 素 中 标 识 对LockSeat元素进行签名。

· Order是LockSeat元素的子元素，描述了订单信息，一个LockSeat元素只包含一个Order元素。SessionCode属性描述了放映计划编码，是必要属性，字符串类型，格式为16位定长字符串。Count属性描述了锁定座位数量，是必要属性，整型数据类型。

· Seat元素是Order元素的子元素，描述了一个特定场次的一组座位集合，一个Order元素至少包含一个Seat元素。SeatCode属性描述了座位编码，字符串类型，格式为16位定长字符串，座位编码在电影院内是唯一的。

LockSeat返回的LockSeatReply元素格式如下。

7．ReleaseSeat接口定义

释放由网络代售接口锁定的座位。

返回的ReleaseSeatReply元素格式如下。

8．SubmitOrder接口定义

提交已锁定的订单，完成交易。交易成功后，返回取票序号和取票验证码。

返回的SubmitOrderReply元素格式如下。

9．QueryPrint接口定义

查询订单打印出票的状态。

QueryPrintReply返回的XML示例如下。

10．RefundTicke接口

将已交易成功并且未出票的订单做退票处理。

RefundTicketReply返回的XML示例如下。

11．QueryOrde接口定义

根据订单编号查询订单详情。

返回的QueryOrderReply元素格式如下。

九 院线票务系统消息通知设计

院线票务系统通过“信息数据接口”从授权管理平台获取影片信息后，做出排片计划，然后通知网络代售和影院管理系统，如图2-54所示。

消息通知的方式可以采用两种方式：其一为MOM消息通知；其二为URL回调方式。

1．MOM消息通知

排片计划生成后，院线票务系统发送消息给MOM，网络代售监听MOM的消息通知。通知使用文本信息，消息格式如下。

“院线编号-消息编号-消息内容”

网络代售接收到MOM的消息通知后，通过2.12.8节设计的Web服务接口，主动调用获取详细的拍片信息。

2．URL回调通知

网络代售发布用于接收通知的微服务接口（多家网络代售的对外接口应该保持一致）。通过配置文件，统一管理和院线合作的网络代售的微服务接口，格式示例如下。

当院线拍片计划生成后，根据配置文件，分别调用网络代售的微服务接口发送消息通知。根据网络代售微服务接口的返回值，记录消息发送的日志。

十 自动取票接口设计

自助取票接口是电影院票务管理系统与自助取票机交互的通信接口。这里定义电影院票务管理系统为服务器端，自助取票机为客户端。

在网络层应采用符合RFC791标准的IP。在传输层应采用符合RFC793标准的TCP，使用8500端口号。一般情况下采用长连接方式，当连接断开后重新连接应重新进行身份认证。

自助取票报文结构如表2-4所示，其中，sync_tag为同步标记，内容固定为十六进制<0xAA 0x55>；version为版本，描述协议版本，当前版本为<0x01>；packet_length为报文总长度，从sync_tag第一字节开始到CRC16的最后一字节结束的长度；payload_id为协议体标识，标识报文中协议体内容数据结构类型。

表2-4 自助取票报文结构