Categories
程式開發

高並發大流量,大麥搶票的技術涅槃之路


一、大麥搶票背景

大麥網主要的業務範圍為演唱會、音樂會、體育賽事、話劇、展銷會、親子活動等現場類的票務業務,其業務鏈條涵蓋從 B 端生產、C 端銷售、現場換驗的全套流程。大麥網一類典型項目是稀缺的火爆 IP 項目,如演唱會、遊戲體育賽事,這類票務隱含了時間、空間的特殊限制屬性,是需要搶的。大麥搶票是演出行業的雙 11,涉及場景複雜、系統較多、鏈路較長,搶票保障尤為重要。

大麥搶票保障大致經歷了幾個階段:

第一階段:“原始”階段,保障不健全,設施不完善;

第二階段:“彈內化”階段,部分大型搶票順利完成;

第三階段:“體系化”階段,能夠承接所有大型搶票;

第四階段:“常態化”階段,大搶體驗優化升級。

高並發大流量,大麥搶票的技術涅槃之路 1

二、“原始”階段

大搶容易出現限流,體驗不順暢等現象,囧!

  1. 為何會這樣

此階段的大麥還處在原技術團隊和阿里系業務、產品、技術各方都在討論及對焦階段,大部分大型搶票核心系統還在大麥的IDC 機房,技術體系走.net 和java 的混合體系,大麥原體系主要承載此階段的大型搶票任務。

為什麼此體系下,每逢大型搶票就會面臨如此大的壓力和風險呢?分析主要有以下幾點原因:

1)保障設施不健全:大麥 IDC 機房硬件設備、帶寬等均有限制;DB 採用 SQL SERVER 企業版,很多數據庫都是單庫。在應對大型搶票時(特別是選座購買,耗帶寬、耗資源),會面臨嚴峻挑戰;

2)預案/限流待建設:系統在高流量、高壓力下的保護措施待建設,比如:限流和降級,造成系統一旦超過壓力,就直接報警;

3)監控運維零散:定位問題、解決問題耗時較長。

  1. 方案和結果

這階段也採取了一些臨時方案,比如:極簡限流方案、一些點的性能優化、修改應用配置參數、整理搶票預案等等,也緩解了一些問題,但整體上仍未解決大型搶票問題。

三、“彈內化”階段

基於第一階段的諸多問題,產品、技術已經啟動大面積系統改造,直接重構新系統到阿里域內,用新系統建設逐步替代老系統,即空中換引擎方案。

  1. 空中換引擎

要快速將關鍵系統重構到阿里域內,確立了直接遷移、臨時方案或長期重構等步驟,具體方案是:

1)APP 鏈路部分彈內化:技術改造重點放在無線端,所有 APP 用戶調用接口的入口先走到阿里域,再路由到大麥 IDC,讓阿里機房來抵檔大量流量;

2)借助阿里基礎運維能力:由於入口接口入到阿里域,一些限流及降級的事情利用平台就可以做,運維監控也完全可以利用 eagleeye、maieye 等排查工具來做了;此過程中

用戶中心、消息中心等服務開始向阿里域內重構並上線;

3)搶票預案初步建立:在主站的預案平台建立了大麥的大型搶票預案,比如:商品詳情頁增加了tair 緩存,靠tair 在阿里域內扛住流量,減少打到大麥IDC 的請求調用;

  1. 堅定路線不動搖

優化後的熱量搶票項目系統正常,但限流會影響用戶體驗。分析搶票過程中出現的問題,集中在了彈內化範圍、機房的瓶頸、運維經驗不足等。所以,催生了第三階段,大型搶票全鏈路收口進阿里域內。

四、“體系化”階段

針對上階段遺留的問題,業務和技術針對搶票流程和系統做了全體系化升級,確立了完善的搶票流程和搶票保障機制。升級後的大麥能承接住所有大型搶票,且用戶體驗有所提升。

  1. 彈內化全面開花

1)新搜索在阿里域內上線,搜索 response 過大的問題也都解決,不存在對帶寬的影響了;

2)新選座在阿里域內上線,大型搶票的選座流量直接打到阿里域內,利用異步化和類似 ConcurrentHashMap 的機制平衡了對大麥 IDC 選座的調用量及緩存的一致性;

3)新交易在阿里域內上線,將核心的創建事務號接口、下單接口全部都放在了阿里域內,單下單後訂單要同步到大麥機房的進行後續履約服務;

  1. 保障流程建起來

基於搶票活動業務方和技術方信息不一致、或臨時搶票活動準備不充分等情況,由測試方牽頭和各業務方、各技術方針對搶票流程、參與人員、搶票設置各項達成一致,並沉澱出搶票保障流程和方案,相關人為操作建立SOP 保障,優化後的流程為:

高並發大流量,大麥搶票的技術涅槃之路 2

1)【流程建設】搶票階段分為搶票前、搶票中、搶票後:

搶票前重點是由業務方搶票申報,再由技術方確認是否安排預演或壓測,根據業務方和歷史搶票信息判斷搶票級別來決定搶票預案執行範圍和風控級別;

搶票中重點是過程監控和應急處理;

搶票後重點是預案恢復、搶票報表輸出,以及搶票過程中問題复盤;

2)【流程建設】搶票參與角色中:產品、開發、測試、公關

搶票涉及多個業務方,主要業務保障人是 BD、編輯、客服,主要支持角色有開發、測試、客服、公關等相關人員;

搶票過程中相關角色各司其職,共同保障搶票。印像比較深的就是這個階段每逢大搶,一屋子相關搶票人員聚集,在搶票順利完成後,會議室傳出的陣陣歡呼聲!

  1. 預案/預演/容量/Action 專項

搶票保障的每一項操作都需要在業務方明確項目信息後,由測試牽頭拉各方參與人員整體評估和協調執行,不管是搶票前的準備還是搶票後的複盤,每個小的專項都執行到位。

1)【質量保障】項目預演:一般已有成熟流程的項目不會再安排預演,對大型搶票或未搶過的新玩法,測試方會安排模擬搶票。主要由各業務方、技術方和各端測試同學共同參與,提前暴露業務、設置問題或體驗問題;

2)【質量保障】性能容量:技術拉取全鏈路最近類似項目的最新壓測數據,和線上實際容量做評估,分析搶票預估量是否能順利支撐,是否有性能瓶頸或限流情況,提前通知業務方;如項目玩法沒有最近的壓測數據支撐,由測試方安排大搶項目壓測;

3)【技術優化】預案執行:全鏈路涉及的首頁搜索、商品詳情、票務雲選座、交易下單、票務雲庫存、訂單服務、無線端等梳理大搶模式的前置預案和緊急預案。如商品詳情前置預案:對藝人、關注、營銷等降級處理,調整用戶、場館、詳情緩存時長,搶票前 30 分鐘預熱限購服務的 BD 和 tair 等;

4)【質量保障】問題复盤:每次搶票完成後對搶票過程中各方暴露的問題、客服反饋的高諮詢、線上收集的bug、內網帖子吐糟、外部用戶微博或微信轉載等問題,測試方統一收集,組織各方復盤後優化方案落實到action,並跟進action 執行進度;

  1. 搶票監控大盤

除各業務定制的搶票監控項外,搶票期大盤的匯總數據監控,可以為每次搶票更好地提供監控數據支持,方便業務方一目了然 get 到搶票數據,具體信息如下:

高並發大流量,大麥搶票的技術涅槃之路 3

五、“常態化”階段

上階段系統化升級完善後,大家肯定會問,大麥搶票不會出問題了吧?

我們可以很負責地說肯定再不會出現宕機情況,但是在近期超稀缺IP 搶票因為項目太火爆,搶到票的畢竟是少數人,大搶之後出現的二手高價售賣現象、搶票不流暢導致搶不到票等問題,被搶不到票的內網小二、外網用戶瘋狂吐槽。

總結槽點主要集中在搶不到票、商品詳情被限流、下單交互耗時導致搶不到票、搶票異常情況對用戶提示不友好等等,針對這些問題除了產品方案的優化,技術同學也成立了很多搶票專項解決用戶痛點,這些小而美的體驗極致優化,你注意到了嗎?

  1. 為真實用戶護航

此階段磨礪了近一年的大麥新交易系統上線了,新交易和共享星環平台全面融合,核心的渲染接口、下單接口基於星環能力實現了大麥擴展特性;新交易架構圖如下:

高並發大流量,大麥搶票的技術涅槃之路 4

融入共享對大麥來說好處很多,針對搶票流程的貢獻主要有 3 點:

1)【技術優化】依托共享基礎能力

除了可以復用共享能力,還可以參考主站交易的大搶方案,比如限流、系統日誌監控、問題排查平台等等。技術方實現基於星環體系的未支付關單定制,由業務方指定關單時長,有效降低了惡意佔用庫存現象發生。

2)【體驗升級】接入集團風控體系:

服務於線上火爆搶票的三層防控技術體系,實際由大麥用戶風險評分、集團安全 MTEE 人機識別、定制化的策略包組成。在交易流程的渲染、下單以不同維度對非法用戶進行二次攔截,讓真實用戶的搶票體驗更順滑,大大提升了真實用戶的購買率。

高並發大流量,大麥搶票的技術涅槃之路 5

  1. 核心鏈路模型優化

1)【體驗升級】商品詳情無限流:從以往搶票看,商品詳情頁每逢大搶不僅要藉機器還要限流,成為了用戶槽點聚集地。商品詳情主要實現了流量分散策略:

a)策略上減少開搶前並發請求,由於散列控制在較短時間,能夠快速上線快速驗證,但效果不明顯;

b)交互上倒計時結束後用戶點擊替代自動刷新來分散流量,效果明顯

c)流程上減少物理調用,倒計時用戶點擊購買時只調用二級頁,倒計時校驗交給二級頁,效果非常明顯

高並發大流量,大麥搶票的技術涅槃之路 6

改造後詳情頁與彈層頁流量從巨大差距到基本持平再到流量較大反轉,商品詳情搶票再也不用藉機器,且足以支撐目標最高熱門項目搶票,再不會觸發限流!

2)【體驗升級】交易下單擴入口:從以往搶票看,交易下單大流量時容易觸發限流,用戶反饋搶不到票。針對交易下單的主要策略是:

a)放大入口+風控攔截+兜底限流,首先讓真實用戶能夠進到交易,再通過風控過濾掉異常用戶,最後用兜底限流保護下游系統,從而最大限度的保障用戶搶票順滑;

b)對渲染階段的支付方式和支付特權做優化,實現大搶時渲染對支付方式調用降級,降低用戶渲染或異步渲染被流控的風險;

高並發大流量,大麥搶票的技術涅槃之路 7

  1. 性能常態化

為摸清交易鏈路最新性能水位,測試團隊啟動了性能常態化項目。每月定時執行壓測,並結合當月各系統功能發布、性能優化或上下游支持,評估具體的壓測場景和壓測目標,壓測完畢後更新鏈路依賴現狀,為搶票提供最有效數據。

1)【質量保障】常態化執行:如近期的稀缺 IP 項目搶票再次刷新各榜單列表,開發和測試一起根據現有流量重新對系統進行壓測摸高評估。

2)【質量保障】壓測自動化:測試梳理了壓測流程,沉澱了各業務線壓測白皮書。提煉出過程中耗時較多的步驟,實現自動化執行,如原臨時項目生成壓測數據和壓測前設置需要11-12 步耗時半天,現在常態化固定項目生成壓測數據和僅需要3 -4 步3 分鐘即可。

高並發大流量,大麥搶票的技術涅槃之路 8

  1. 預案自動化

之前搶票存在搶票活動頻繁,搶票無統一規範流程(監控、預案、入口),支持人數多,組織搶票會議,耗費人力等問題。

1)【技術優化】搶票控制台:

使BD 或者運營在【搶票開始前】可以設置一些預案,【搶票過程中】提供統一視圖對搶票進行【實時監控】,並且有能力進行【人為的干預和控制】,在【搶票結束後】能夠提供歷次搶票數據以供分析,從而幫助BD 自助完成搶票,實現“無人值守”具體實現流程如下:

高並發大流量,大麥搶票的技術涅槃之路 9

2)【技術優化】商品詳情預案:

詳情頁每次大搶都需要人工降級 6~10 項預案,各項預案設置的值、執行時間等各有差異,在預案設置時還需根據個人經驗做評估調整,人工操作太繁瑣。詳情預案基礎策略是對原降級項實現本地緩存或 tair 緩存,第三方依賴接口限流異常降級補充,優化後僅保留 1 項需手動配置的預案,其他皆已實現自動化。

  1. 常態化成果

通過常態化各專項保障取得明顯成效,近一年支持的搶票項目近千場,其中大型搶票近百場。其中近期熱門「超大搶」項目,商詳/下單渲染/下單均創歷史峰值,系統順利承接;熱門「大搶」項目,特權碼選座和普通選座,特權及選座峰值均創新高,系統順利承接;

高並發大流量,大麥搶票的技術涅槃之路 10

六、結語

大麥搶票經歷了“原始”階段、流程建設、技術優化、專項保障等四個階段建設後系統已穩如磐石,對提升用戶體驗上也在不斷努力。當然可能還是存在或多或少的問題,目前的技術方案也可能不是最優的,比如項目熱度智能分析、風控自動調節等等,也已經在技術優化計劃中,在搶票的路上大麥會秉持初心一​​直奔跑!

作者簡介

阿里文娛測試開發專家 舒琴、阿里文娛測試開發 錦燁

相關鏈接

阿里怎樣守護產品線上質量?大麥用虛擬機器人搞定

大麥交易融入阿里電商平台之路