大麦票夹：从工具到服务的技术演进之路

本文基于大麦票夹过去工作以及未来思考总结而成。按基础电子票功能、行业无纸化、服务化的三个阶段阐述了大麦票夹的发展及背后技术架构的变化。希望以此引发大家一起思考：技术架构如何提前布局以满足业务在不同阶段的要求。

一、背景 - 什么是票夹

票夹，顾名思义，装票的小夹子。在大麦 APP 这个曾经工具性很强的应用中，承担起了电子票收录和使用的功能。

用户在大麦购买一张演出票，如果是电子票，出票后用户就可以在票夹找到这张票，看到票的场次、看台、座位号等基本信息。在入场的时候，可以展示票的二维码信息给验票设备，扫码验证通过后即可入场。
图 1

从上图可以看出来，为了方便使用票，所有票是按场次组织在一起的；如果该演出场次可以换纸质票，会有换票点的位置引导；在验票后会更新票的状态……

可以说，最初票夹的所有功能和交互设计都是为了方便用户行使最基本的使用权利。这也是第一阶段票夹所做的主要工作。下面从第一阶段开始介绍票夹的发展历程。

二、电子票基本服务

票夹第一阶段的重点是实现电子票服务的基本功能和可靠性。

基本功能很好理解，电子票如何加密，在 APP 侧的二维码如何生成；在验票端如何校验二维码是有效的。

为了利用好阿里生态，在大麦 APP 落电子票的同时还向用户的支付宝卡包中落入电子票，让用户不但可以使用大麦 APP 入场，还能使用支付宝卡包入场。

下图系统的描绘了大麦票夹的电子票基本服务。其核心还是二维码电子票部分，稍详细介绍一下。

图 2

1. 动态二维码

二维码电子票分静态二维码和动态二维码。

静态二维码就是一个固定的码，实现简单，但是安全性较低，如果二维码被拍照或者截图，理论上相当于这张票被复制了。

动态二维码在整个产票落票过程进行了多重签名和加密，在端上还通过算法结合 APP 环境进行了动态加密生产可变化的二维码，有效防止票被复制。

目前大麦主流使用动态二维码模型的电子票，在大麦 APP 和支付宝卡包同样支持。

2. 客户端本地化缓存

在现场验票的场景下，需要面对一些极端条件，其中之一便是用户手机的无线网络。目前 4G 网络已经普及，但是在大型演唱会的时候，场馆附近会聚集大量的人，每人一个手机很轻松就超过了 4G 基站的承载能力，导致现场用户手机端的网络很差或者几乎处于无网状态。

如果该演唱会采用电子票入场的方式，那就是场灾难，大批用户因为打不开大麦 APP 中的电子票无法验票入场。针对这种情况，大麦 APP 采用了客户端本地化缓存的方案。

APP 将请求过的票数据保存在本地数据库中，只要用户曾经在 APP 中打开过这个电子票，以后即时没有网络，也能从本地数据库中把票读取并展示出来。

但是电子票可能并不是下单完成后立刻出票的，也就意味着用户不一定有机会亲手点开电子票，我们采用的方法是在真正落票的时候，给 APP 端一个推送消息（通过长连接通道），APP 接收消息后会从后台拉取电子票保存到本地。

3. 票的状态实时更新

这其实是用户体验的提升点，即在验票扫码后，用户 APP 上的二维码立刻被打一个“已使用”的戳。

看似很简单的一个功能，其实需要全链路的配合。

首先，验票端在现场网络不是那么稳定的情况下，需要及时的将验票状态发送到验票服务系统；

其次，验票服务系统需要把状态更新告诉票夹；

再次，票夹需要通过长链接通道将票状态的变换推送到大麦 APP。

全链路整体延迟需要控制在 2 秒左右，再长用户就没机会看到实时状态变换了。
图 3

4.转赠

转赠服务是推广电子票特别是动态二维码形式的电子票必不可少的服务，是纸质票体感在电子票领域的自然延伸。

设想 4 个人相约去看一场球赛，其中一个人买了 4 张纸质票，因为座位不是连续的，入场时间不同，入场口可能也不一样，所以需要把票分给每个人，大家各自持票入场。

如果是电子票也存在这个场景，总不能大家先后用同一个人的帐号登录大麦 APP 入场，最自然的做法就是购票人将电子票以转赠的方式分发给每个人，大家各自持 APP 入场。

用户下单购票的时候，票和订单是绑定的，但是到转赠的时候，票和订单就无关了，只是持有人的信息发生了变换。

这里票夹维护了当前票和用户之间的关系，即一张票当前的所有人是哪个用户。
图 4

三、行业化

整个演出市场的总票量中大麦占了很大比重，可以将整体演出市场的票分为三大部分：

1）大麦自产的票；

2）大麦的部署给场馆方的麦座系统生产的票；

3）其它公司产票系统生产的票。

大麦票夹最初实现的电子票服务只是针对大麦自产票这一部分。但是要成为电子票的先行者，需要对整个行业的无纸化体验产生足够影响力。为了实现这个目标，大麦票夹需要具备开放性，能落其他票仓生产的票。

1. B 端多商户的支持

对于票夹来说，一个非大麦的商家就是一个入驻商户，独立产票，并使用票夹提供的电子票能力，同时又彼此隔离（数据和配置都隔离）。要做到这一点，需要解决很多问题。

1）统一的数据模型和开发接口（OpenAPI）

在面向大麦自产票的时候，因为只有一个用户，票夹专门设立了一个接入层应用来做票的接入。这个应用监听交易发出的消息，并查询产票系统获取票的详细信息，同时还查询场次、场馆等信息最终落票。但是在支持多商户后，票夹不可能针对每个商户都去了解对方的下单、产票逻辑来做票的接入。可行的办法是定义一套统一的接口和模型，由商户自己决定何时落票，自己按票夹的要求组织好相关信息，票夹只做信息完整性的校验。
图 5

2）商户间的分销关系

这里之所以叫商户而不是租户，是因为商户之间是可以有关联的，并不是简单的增加一个商户 ID 做隔离就一切 ok 了。

例如，商户 A 是产票方，除自己卖票外，还把票卖给商户 B、商户 C。大家落票的时候都是各自落入票夹，但是这些票是同一个场次的，商户 B 和商户 C 只需要使用产票商户 A 的场次信息即可，场次相关的配置也可以复用一套。

在行业票夹中就做了这样的支持，可以让商户直接复用产票方的场次数据，从验票系统的角度，只有一套场次，那就是产票方的场次数据，与验票相关的信息要与产票方保持一致。

图 6

2. C 端页面的复用与隔离

前面提到了，当电子票落入票夹，实际上就和订单没太大关系了，票夹主要维护的是用户和票的关系。而每个商家都是有自己的用户体系的，商户的隔离同时也要求 C 端用户的隔离。

大麦票夹是通过一套定制化的 OAuth 协议完成各商户的用户对票夹访问时的鉴权和数据隔离的。

图 7

四、聚焦服务

1. 为什么要聚焦服务

前面介绍的两个阶段，一个是提供基本的电子票服务，另一个是将基本的电子票服务推广到更多的用户。虽然对 B 端实现了平台化，但对 C 端始终还没有脱离一个工具化应用的范畴。

票夹这块阵地除了是用户使用票的入口，更是用户和演出方 / 场馆的连接点，我们的用户如果仅仅在入场或者换票的时候才进入票夹，那其实是巨大的浪费。

对用户来说，我们可以通过票夹让其在观演前后享受到更贴心的服务；对场馆 / 主办来说，可以通过票夹触达用户、了解用户、挖掘更多周边的价值。这两点如果做好，不但让我们的用户更有粘性，而且还会吸引更多非大麦的用户使用大麦 APP，进而转化成大麦的用户。

因此票夹需要从一个工具型的功能模块进化为一个服务的载体，串联整个用户购票、观演的生命周期，打通阿里生态甚至外部服务。

图 8

2. 票夹服务周期和对象的拓展

用户观演的整个周期并非始于演出开始的那一刻，从用户有观演的打算开始，这个周期就开始了，一个用户可能经历了想看、决定购票、下单、等待出票、筹划出行观演、出行、入场、观演、观演后这样一个漫长的周期，这个周期可能长达一个月甚至几个月，这是和看电影有巨大区别的地方。

图 9

一个工具化的票夹是服务于“购票后”和“观演”这两个阶段。而一个服务化的票夹是可以向前和向后拓展的，设想用户在未下单的时候就可以通过关注等方式为用户在票夹创建一个场次卡片，虽然还没有买票，用户已经可以开始享受服务了。即使用户没有选择在大麦买票，依然可以享受后续的一系列服务。

当票夹服务化之后，就不仅仅满足提供电子票功能了，购买纸质票的用户一样可以在票夹展示一个服务卡片，重点聚焦在服务上。这就对票夹的业务模型和架构提出了新的要求：

从一开始的处处以票为中心进化到以演出卡片为中心，服务开始的起点从落票变为了用户创建一个场次卡片；
整个服务周期的不同阶段，为用户提供不同的观演服务。

图 10

3. 观演服务组件化

当票夹的服务周期和对象都做了扩展，必然需要引入更多样化、个性化的服务。票夹在架构上需要支持大量服务的接入能力，同时可以在每个观演周期动态化、个性化的提供给用户使用。

我们希望对票夹的观演服务进行组件化设计，组件化这个概念很大，总体来说是关于软件模块的封装、定制和复用，在不同领域有不同的解释，这里不想对组件化展开讨论，但是针对票夹有必要思考清楚组件化的内涵和外延。票夹的观演服务组件化关乎如下几点：

1）观演服务的抽象与封装。

票夹本身并不实现这些服务，而是服务的搬运工，充当整合与桥梁的作用为主。对于整合与桥梁这个目的，我们是可以将五花八门的观演服务进行抽象和归类的，这样票夹可以通过对少数几种模型的支持来快速接入各种个样的观演服务。比如，服务可以抽象为类
banner 跳转类、信息透出类、三方客户端 SDK 类等几种类型。
前后端对每种类型的组件数据定义、展示和逻辑的封装。

2）每个观演服务组件是可以跨商家、跨场次、跨场景复用的。

图 11

组件是观演服务的最小单位，整个票夹平台维护所有支持的服务组件，每个商家可以定制自己支持的服务组件列表。每个观演服务组件之于一个商家是可以订制的，可订制的范围被明确定义并将操作接口暴露给商家。
每个观演服务组件之于一个场次是有实例化数据 / 配置的，这部分数据 / 配置每个场次都可以不同。
组件在 APP 出现的场景是可以订制的，可以出现在场次列表，也可以出现在场次详情；可以出现在观演前阶段，也可以出现在观演结束之后。

3）服务组件是能够支持个性化的。

针对不同的用户类型、推荐不同的观演服务。端上给用户展示的观演服务都有哪些，顺序是什么是可以进行个性化控制的。

4. 服务的接入

这部分主要是 B 端的范畴，我们的服务提供方可以是大麦（换验、转赠这种基本服务），也可以是第三方。第三方又可以进一步分为阿里系的服务提供方和阿里外的服务提供方。

对于第三方的服务，是需要进行入驻管理的，入驻可以限定服务露出的目标组件、人群、项目类型、场馆等等条件，甚至可以千人千面；
对于阿里外部的服务提供商，进行服务整合是需要外接的，及彼此接口级的互通。这部分也是可以与三方体系打通，通过统一的外接平台实现服务整合。

五、总结

本文从电子票基本功能展开，拓展到行业无纸化以及未来的服务化，思考和总结了票夹在其中的作用及应具备的技术能力。这些都是基于过去的环境和技术趋势，而对于未来，随着大的行业环境的变化以及技术趋势的改变，需要持续的创新，这里抛出几个问题请读者一起思考一下：

基础的电子票能力从安全性、可靠性和便利性方面是否还有改进的空间？
行业无纸化的推进过程，如何做到对不同票库进行电子票能力的输出？
在行业电子票验真和票流转方面，如何形成行业公信力？
围绕电子票，如何将服务更有效的串联在一起，为用户、场馆、内容方提供更大的价值？

作者简介：

阿里文娱技术专家义豪