Categories
程式開發

大麥票夾:從工具到服務的技術演進之路


本文基於大麥票夾過去工作以及未來思考總結而成。按基礎電子票功能、行業無紙化、服務化的三個階段闡述了大麥票夾的發展及背後技術架構的變化。希望以此引發大家一起思考:技術架構如何提前佈局以滿足業務在不同階段的要求。

一、背景 – 什麼是票夾

票夾,顧名思義,裝票的小夾子。在大麥 APP 這個曾經工具性很強的應用中,承擔起了電子票收錄和使用的功能。

用戶在大麥購買一張演出票,如果是電子票,出票後用戶就可以在票夾找到這張票,看到票的場次、看台、座位號等基本信息。在入場的時候,可以展示票的二維碼信息給驗票設備,掃碼驗證通過後即可入場。

大麥票夾:從工具到服務的技術演進之路 1

圖 1

從上圖可以看出來,為了方便使用票,所有票是按場次組織在一起的;如果該演出場次可以換紙質票,會有換票點的位置引導;在驗票後會更新票的狀態……

可以說,最初票夾的所有功能和交互設計都是為了方便用戶行使最基本的使用權利。這也是第一階段票夾所做的主要工作。下面從第一階段開始介紹票夾的發展歷程。

二、電子票基本服務

票夾第一階段的重點是實現電子票服務的基本功能和可靠性。

基本功能很好理解,電子票如何加密,在 APP 側的二維碼如何生成;在驗票端如何校驗二維碼是有效的。

為了利用好阿里生態,在大麥 APP 落電子票的同時還向用戶的支付寶卡包中落入電子票,讓用戶不但可以使用大麥 APP 入場,還能使用支付寶卡包入場。

下圖系統的描繪了大麥票夾的電子票基本服務。其核心還是二維碼電子票部分,稍詳細介紹一下。

大麥票夾:從工具到服務的技術演進之路 2

圖 2

  1. 動態二維碼

二維碼電子票分靜態二維碼和動態二維碼。

  • 靜態二維碼就是一個固定的碼,實現簡單,但是安全性較低,如果二維碼被拍照或者截圖,理論上相當於這張票被複製了。
  • 動態二維碼在整個產票落票過程進行了多重簽名和加密,在端上還通過算法結合 APP 環境進行了動態加密生產可變化的二維碼,有效防止票被複製。

目前大麥主流使用動態二維碼模型的電子票,在大麥 APP 和支付寶卡包同樣支持。

  1. 客戶端本地化緩存

在現場驗票的場景下,需要面對一些極端條件,其中之一便是用戶手機的無線網絡。目前4G 網絡已經普及,但是在大型演唱會的時候,場館附近會聚集大量的人,每人一個手機很輕鬆就超過了4G 基站的承載能力,導致現場用戶手機端的網絡很差或者幾乎處於無網狀態。

如果該演唱會採用電子票入場的方式,那就是場災難,大批用戶因為打不開大麥 APP 中的電子票無法驗票入場。針對這種情況,大麥 APP 採用了客戶端本地化緩存的方案。

APP 將請求過的票數據保存在本地數據庫中,只要用戶曾經在 APP 中打開過這個電子票,以後即時沒有網絡,也能從本地數據庫中把票讀取並展示出來。

但是電子票可能並不是下單完成後立刻出票的,也就意味著用戶不一定有機會親手點開電子票,我們採用的方法是在真正落票的時候,給APP 端一個推送消息(通過長連接通道),APP 接收消息後會從後台拉取電子票保存到本地。

  1. 票的狀態實時更新

這其實是用戶體驗的提升點,即在驗票掃碼後,用戶 APP 上的二維碼立刻被打一個“已使用”的戳。

看似很簡單的一個功能,其實需要全鏈路的配合。

首先,驗票端在現場網絡不是那麼穩定的情況下,需要及時的將驗票狀態發送到驗票服務系統;

其次,驗票服務系統需要把狀態更新告訴票夾;

再次,票夾需要通過長鏈接通道將票狀態的變換推送到大麥 APP。

全鏈路整體延遲需要控制在 2 秒左右,再長用戶就沒機會看到實時狀態變換了。

大麥票夾:從工具到服務的技術演進之路 3

圖 3

  1. 轉贈

轉贈服務是推廣電子票特別是動態二維碼形式的電子票必不可少的服務,是紙質票體感在電子票領域的自然延伸。

設想4 個人相約去看一場球賽,其中一個人買了4 張紙質票,因為座位不是連續的,入場時間不同,入場口可能也不一樣,所以需要把票分給每個人,大家各自持票入場。

如果是電子票也存在這個場景,總不能大家先後用同一個人的帳號登錄大麥APP 入場,最自然的做法就是購票人將電子票以轉贈的方式分發給每個人,大家各自持APP 入場。

用戶下單購票的時候,票和訂單是綁定的,但是到轉贈的時候,票和訂單就無關了,只是持有人的信息發生了變換。

這裡票夾維護了當前票和用戶之間的關係,即一張票當前的所有人是哪個用戶。

大麥票夾:從工具到服務的技術演進之路 4

圖 4

三、行業化

整個演出市場的總票量中大麥佔了很大比重,可以將整體演出市場的票分為三大部分:

1)大麥自產的票;

2)大麥的部署給場館方的麥座系統生產的票;

3)其它公司產票系統生產的票。

大麥票夾最初實現的電子票服務只是針對大麥自產票這一部分。但是要成為電子票的先行者,需要對整個行業的無紙化體驗產生足夠影響力。為了實現這個目標,大麥票夾需要具備開放性,能落其他票倉生產的票。

  1. B 端多商戶的支持

對於票夾來說,一個非大麥的商家就是一個入駐商戶,獨立產票,並使用票夾提供的電子票能力,同時又彼此隔離(數據和配置都隔離)。要做到這一點,需要解決很多問題。

1)統一的數據模型和開發接口(OpenAPI)

在面向大麥自產票的時候,因為只有一個用戶,票夾專門設立了一個接入層應用來做票的接入。這個應用監聽交易發出的消息,並查詢產票系統獲取票的詳細信息,同時還查詢場次、場館等信息最終落票。但是在支持多商戶後,票夾不可能針對每個商戶都去了解對方的下單、產票邏輯來做票的接入。可行的辦法是定義一套統一的接口和模型,由商戶自己決定何時落票,自己按票夾的要求組織好相關信息,票夾只做信息完整性的校驗。

大麥票夾:從工具到服務的技術演進之路 5

圖 5

2)商戶間的分銷關係

這里之所以叫商戶而不是租戶,是因為商戶之間是可以有關聯的,並不是簡單的增加一個商戶 ID 做隔離就一切 ok 了。

例如,商戶 A 是產票方,除自己賣票外,還把票賣給商戶 B、商戶 C。大家落票的時候都是各自落入票夾,但是這些票是同一個場次的,商戶B 和商戶C 只需要使用產票商戶A 的場次信息即可,場次相關的配置也可以復用一套。

在行業票夾中就做了這樣的支持,可以讓商戶直接復用產票方的場次數據,從驗票系統的角度,只有一套場次,那就是產票方的場次數據,與驗票相關的信息要與產票方保持一致。

大麥票夾:從工具到服務的技術演進之路 6

圖 6

  1. C 端頁面的複用與隔離

前面提到了,當電子票落入票夾,實際上就和訂單沒太大關係了,票夾主要維護的是用戶和票的關係。而每個商家都是有自己的用戶體系的,商戶的隔離同時也要求 C 端用戶的隔離。

大麥票夾是通過一套定制化的 OAuth 協議完成各商戶的用戶對票夾訪問時的鑑權和數據隔離的。

大麥票夾:從工具到服務的技術演進之路 7

圖 7

四、聚焦服務

  1. 為什麼要聚焦服務

前面介紹的兩個階段,一個是提供基本的電子票服務,另一個是將基本的電子票服務推廣到更多的用戶。雖然對 B 端實現了平台化,但對 C 端始終還沒有脫離一個工具化應用的範疇。

票夾這塊陣地除了是用戶使用票的入口,更是用戶和演出方/場館的連接點,我們的用戶如果僅僅在入場或者換票的時候才進入票夾,那其實是巨大的浪費。

對用戶來說,我們可以通過票夾讓其在觀演前後享受到更貼心的服務;對場館/主辦來說,可以通過票夾觸達用戶、了解用戶、挖掘更多周邊的價值。這兩點如果做好,不但讓我們的用戶更有粘性,而且還會吸引更多非大麥的用戶使用大麥 APP,進而轉化成大麥的用戶。

因此票夾需要從一個工具型的功能模塊進化為一個服務的載體,串聯整個用戶購票、觀演的生命週期,打通阿里生態甚至外部服務。

大麥票夾:從工具到服務的技術演進之路 8

圖 8

  1. 票夾服務週期和對象的拓展

用戶觀演的整個週期並非始於演出開始的那一刻,從用戶有觀演的打算開始,這個週期就開始了,一個用戶可能經歷了想看、決定購票、下單、等待出票、籌劃出行觀演、出行、入場、觀演、觀演後這樣一個漫長的周期,這個週期可能長達一個月甚至幾個月,這是和看電影有巨大區別的地方。

大麥票夾:從工具到服務的技術演進之路 9

圖 9

一個工具化的票夾是服務於“購票後”和“觀演”這兩個階段。而一個服務化的票夾是可以向前和向後拓展的,設想用戶在未下單的時候就可以通過關注等方式為用戶在票夾創建一個場次卡片,雖然還沒有買票,用戶已經可以開始享受服務了。即使用戶沒有選擇在大麥買票,依然可以享受後續的一系列服務。

當票夾服務化之後,就不僅僅滿足提供電子票功能了,購買紙質票的用戶一樣可以在票夾展示一個服務卡片,重點聚焦在服務上。這就對票夾的業務模型和架構提出了新的要求:

  • 從一開始的處處以票為中心進化到以演出卡片為中心,服務開始的起點從落票變為了用戶創建一個場次卡片;
  • 整個服務週期的不同階段,為用戶提供不同的觀演服務。

大麥票夾:從工具到服務的技術演進之路 10

圖 10

  1. 觀演服務組件化

當票夾的服務週期和對像都做了擴展,必然需要引入更多樣化、個性化的服務。票夾在架構上需要支持大量服務的接入能力,同時可以在每個觀演週期動態化、個性化的提供給用戶使用。

我們希望對票夾的觀演服務進行組件化設計,組件化這個概念很大,總體來說是關於軟件模塊的封裝、定制和復用,在不同領域有不同的解釋,這裡不想對組件化展開討論,但是針對票夾有必要思考清楚組件化的內涵和外延。票夾的觀演服務組件化關乎如下幾點:

1)觀演服務的抽象與封裝。

  • 票夾本身並不實現這些服務,而是服務的搬運工,充當整合與橋樑的作用為主。對於整合與橋樑這個目的,我們是可以將五花八門的觀演服務進行抽象和歸類的,這樣票夾可以通過對少數幾種模型的支持來快速接入各種個樣的觀演服務。比如,服務可以抽象為類 banner 跳轉類、信息透出類、三方客戶端 SDK 類等幾種類型。
  • 前後端對每種類型的組件數據定義、展示和邏輯的封裝。

2)每個觀演服務組件是可以跨商家、跨場次、跨場景復用的。

大麥票夾:從工具到服務的技術演進之路 11

圖 11

  • 組件是觀演服務的最小單位,整個票夾平台維護所有支持的服務組件,每個商家可以定制自己支持的服務組件列表。每個觀演服務組件之於一個商家是可以訂製的,可訂製的範圍被明確定義並將操作接口暴露給商家。
  • 每個觀演服務組件之於一個場次是有實例化數據/配置的,這部分數據/配置每個場次都可以不同。
  • 組件在 APP 出現的場景是可以訂製的,可以出現在場次列表,也可以出現在場次詳情;可以出現在觀演前階段,也可以出現在觀演結束之後。

3)服務組件是能夠支持個性化的。

  • 針對不同的用戶類型、推薦不同的觀演服務。端上給用戶展示的觀演服務都有哪些,順序是什麼是可以進行個性化控制的。
  1. 服務的接入

這部分主要是 B 端的範疇,我們的服務提供方可以是大麥(換驗、轉贈這種基本服務),也可以是第三方。第三方又可以進一步分為阿里系的服務提供方和阿里外的服務提供方。

  • 對於第三方的服務,是需要進行入駐管理的,入駐可以限定服務露出的目標組件、人群、項目類型、場館等等條件,甚至可以千人千面;
  • 對於阿里外部的服務提供商,進行服務整合是需要外接的,及彼此接口級的互通。這部分也是可以與三方體系打通,通過統一的外接平台實現服務整合。

五、總結

本文從電子票基本功能展開,拓展到行業無紙化以及未來的服務化,思考和總結了票夾在其中的作用及應具備的技術能力。這些都是基於過去的環境和技術趨勢,而對於未來,隨著大的行業環境的變化以及技術趨勢的改變,需要持續的創新,這裡拋出幾個問題請讀者一起思考一下:

  • 基礎的電子票能力從安全性、可靠性和便利性方面是否還有改進的空間?
  • 行業無紙化的推進過程,如何做到對不同票庫進行電子票能力的輸出?
  • 在行業電子票驗真和票流轉方面,如何形成行業公信力?
  • 圍繞電子票,如何將服務更有效的串聯在一起,為用戶、場館、內容方提供更大的價值?

作者簡介

阿里文娛技術專家 義豪

相關鏈接

10W 座位的大場館究竟是怎麼畫出來的?

10 倍高清不花!大麥端選座SVG 渲染

首次揭秘!看大麥如何掌控超大規模高性能選座搶票

3D/VR 選座技術探索

大麥庫存的高性能及一致性是如何設計的?