天貓雙11晚會和狂歡城的互動技術方案

4月21日，天貓互動的技術專家 鄧紅春（續彬） 在 QCon北京2016 分享了《天貓雙11晚會和狂歡城的互動技術方案》。2015年天貓聯合湖南衛視聯合打造了一場最互聯網的雙11晚會互動，如此大流量的直播互動需要重點考慮的是系統的穩定性，盡可能減少依賴，并且要做非常多的容錯容災機制。憑借著5年的狂歡城開發經驗，今年則是大膽突破和敢于創新，使用了場景編輯器、智能加載、多模式渲染等措施，體驗和性能創了新高。

電商互動業務有三大特點：要足夠吸引人，體驗要足夠好，還要具有商業價值。基于這三大特點，需要開發者勇于創新、敢于挑戰。天貓互動計劃在5月份啟動“ 天貓電商互動創意大賽 ”，來鼓勵擁有創新思維和技術的團隊把他們的產品和天貓的業務結合起來，發揮出工程師們的最大價值。這個大賽除了豐厚獎金，獲勝者可以跟天貓進行長期合作。

鄧紅春（續彬），天貓技術專家。目前在天貓互動技術團隊，從事互動業務的技術架構設計和團隊管理方面工作，負責過雙11狂歡城、雙11晚會、紅包裂變、互動開放、3D和AR、 Hilo 、 TidaSDK 等項目，專注于電商互動營銷相關的技術領域。2012年加入阿里巴巴，花名續彬，曾負責過天貓無線的前端開發和hybrid框架設計。此前曾在騰訊財付通工作過，主要從事于支付類產品開發。

以下內容根據演講材料整理而成。演講幻燈片 下載 。

天貓雙11晚會和狂歡城的互動技術方案

今天要分享的話題是“天貓雙11晚會和狂歡城的互動技術方案”，這兩個項目都屬于天貓雙11核心業務，希望能帶給大家一些技術上的思路。

先從業務開始說起。什么叫做電商的互動業務呢？作為技術同學，千萬不能把自己當做資源，上面來了需求做完了就可以了，我們要深刻了解業務的目標是什么，需要做到什么樣的程度，這樣能夠最大化發揮我們技術同學自身的價值。

我們的理解，所謂互動就是能夠發掘出多方的主動性，讓多方都能夠主動動起來。電商場景中的多方，一方是消費者，另一方是企業，商家也好，平臺也好，都是企業。那么怎么去創作一些場景，讓他們能夠有一些共同的利益點，能夠聚在一起，能夠緊緊結合在一起，最終達到多方共贏的結果呢？我們創造出來這種場景就稱為互動業務。

天貓近一兩年來做的互動項目非常多，里面用了很多3D、AR、視頻之類技術。互動技術在電商當中運用非常廣泛，而且取得了非常好的業務效果和數據。

互動項目特點

就剛才所說到的互動項目，我們總結為三個特點，它們會帶來一定的技術挑戰，接下來的很多技術架構的設計都是圍繞這些特點展開的。

首先，互動的業務需要足夠吸引人，剛剛大家看到的晚會場景具有一定的明星效應和一定的媒體影響力，有些時候可能會有一定的話題性和傳播性，不管通過什么因素，首先要把人吸引過來，吸引人越多流量越大，而且很多互動項目流量時間點是非常集中的，會在某一個時間點里爆發出來，QPS非常高。“吸引人”這個特點對系統的挑戰是高并發。

第二個特點，體驗要非常好。我們把人吸引過來之后，如果體驗做得不好，很容易引起流量的流失，在體驗方面涉及到性能要足夠快，動畫要足夠酷炫，交互方式要簡單明了，或者有比較潮的交互方式，讓消費者舍不得走，一直在這個互動頁面。所以要把人留下來，體驗方面就一定要非常好，一個優秀互動項目的成功，肯定離不開一個體驗很好的頁面。

第三個也是至關重要的一點，它要有一定的商業價值，把人引來了，也留下了，怎么沉淀這些用戶，怎么讓它更有商業價值？都是要思考的。

所以說一個好的互動項目是一定有數據沉淀的，就要做好相關數據監控和數據埋點的工作。

挑戰與解決之道

我要分享兩個項目，晚會和狂歡城，為什么結合這兩個項目說呢？雙11晚會特點在于流量非常大，狂歡城特點是素材會比較多，對前端的極致體驗，交互流暢度挑戰會非常高。所以我會結合這兩個項目來嘗試我們怎么解決這兩個問題。

雙11晚會主要挑戰還是在后端的穩定性，不能出任何的問題。因為當時馬老師去了，：） 不能在他面前丟臉。狂歡城主要挑戰在于前端，前端怎么面對這么大的頁面，這么多的素材快速渲染。

9月底接到這個需求，離雙11一個月多一點，要把需求討論和視覺設計、開發、測試、預演全部做完，感覺時間還是挺緊的。但是因為聽到馮導指導，很多大明星，又是湖南衛視金牌制作團隊和主持團隊，是傾注了娛樂圈很多力量在，我們雖然感覺時間很緊，但是心里還是蠻有成就感的，而且很有信心做好。就是感覺自己被時代選中，出人頭地的時候到了。

當時需求是這樣，主要是分三大塊，一個是PK環節，兩組明星，主持人組織他們玩游戲，玩游戲之前所有電視機前觀眾打開手機天貓押寶，根據現場產生游戲結果，押對人會有抽獎機會。第二個是明星表演，很多明星都是天貓商家請來的代言人，明星開始表演的時間，表演結束的時間也是現場產生的，沒有準確的時間。第三大塊晚會也會中間插播硬廣，比如20秒鐘廣告，每一輪將近四五分鐘，電視上播什么廣告，手機分秒不差切換什么廣告。

我們當時的設計是后臺設置時間表，前端拿到時間表之后按照這個時間表切換頁面。覺得這個事情就是應該這么解決，而且應該沒什么問題。當時我們這么想也沒錯，因為我們畢竟年輕，想得不會特別復雜。

9月28號去長沙和導演聊這個事情，到了長沙之后整個心情就變得很沉重了。業務方要求時間不能有任何誤差，不能上面切廣告，下面過幾秒才出現，這種情況不能出現的。和導演組開會聽到最多的詞就是不確定性，比如明星出場順序不確定，游戲PK結果不確定，節目時長不確定，這樣一想又是直播，是不是每秒鐘都必須后臺請求最新的時間表，流量這么大，這樣挑戰就非常大了，系統可能扛不住。所以整個心情非常崩潰，那怎么辦呢？加上導演說這次晚會陣容比跨年演唱會還要強大，收視率肯定會高過跨年演唱會，流量下來了，問題下來了，思想壓力就很大。

討論過程當中發現一個救命稻草，就是1分鐘時間，就是現場到電視信號延遲1分鐘，開會時間反復問執行導演，說這1分鐘會不會變。他都有點被我問得不耐煩了，他說不會變，那我就放心了，不會變的1分鐘就是我們的救命稻草，可以圍繞它做架構上的設計。至少留給我們一分鐘的緩沖時間，后面很多技術設計都圍繞這1分鐘展開。

以明星PK環節為例。

整個這個環節時間軸是這樣展開的，上面這條線是現場情況，下面是電視機前的情況。大家都能看到，向上豎起來的箭頭都是關鍵節點，根據主持人的口播來確定的，開啟押寶通道，開始介紹游戲規則的時候，明星開始游戲的時候主持人會說關閉押寶通道，所以根據主持人的口播需要往后臺寫一個數據。比如說10點52分05秒主持人說開啟押寶通過，需要10點53分05秒，1分鐘之后時間寫到后臺，前端拿到這個時間，一到達這個時間做一些行動，手機上頁面和電視上就可以保持同步了。我們要在1分鐘之內把最新的時間數據傳輸到所有用戶手機上面。

技術選型

了解完需求之后，下面就是技術選型。

涉及到兩點。

第一點，怎么進入頁面，做技術同學要學會克制，我覺得我們在這個項目里就克制得非常好，并沒有用高大上的技術，因為每個高大上的技術看起來都很酷炫，但是都存在不穩定的因素，比如聲紋識別，在嘈雜環境中可能會有失敗概率。識別臺標，這些技術在臺網互動都用過，就是因為踩過很多坑，所以在大型的直播晚會就不能冒險，還要依賴第三方系統，如果出現問題整個項目就崩潰了。

第二點，進入頁面之后，前端怎么跟后端進行數據傳輸。聽得比較多的就是長連接，這塊在有些互動游戲當中也用過，但是沒有大面積使用，因為在阿里集團暫時沒有找到適合我們業務而且穩定的長鏈接服務能夠支撐這樣的流量。

考慮到現場直播，不能出現任何問題，也沒有任何時間來解決bug，抱著穩定壓倒一切的原則，我們選擇了簡單有效的方法。

首先是用戶進入，通過搖一搖，不做任何判斷直接進入互動頁面。這就是保證簡單有效的時候了。第二點，采用了HTTP輪詢，對前后端改造成本都是用最有信心的一套方式。確實第一次出來做這種事情難免會緊張一點，如果放縱的話得到下次。

這就是整體架構的鳥瞰圖，最大的架構圖。為了能讓大家看得更清晰一點，我盡量進行最大程度的簡化，留下關鍵部分。黃色部分是電視機前觀眾的鏈路，通過手機天貓搖一搖進入，前端每40秒輪詢獲得數據。最關鍵是下面藍色部分，現場在水立方值班的技術同學，會有控制臺實時切換很多開關，管理后臺頁面是后臺開發自己寫的頁面。后端同學比較了解開關的東西，所以以他最熟悉的方式做很簡單的頁面，即使開關很多，但是他自己能夠把握住，而且里面有任何問題能夠馬上解決，不需要依賴前端同學各種麻煩的協作。他在水立方值班的時候，會把最新數據寫到管理后臺，把數據寫入應用服務器。

40秒的時間是怎么來的

根據預估的QPS，收視率會有多少人收看節目，大概百分之多少人進入頁面，根據數據再來權衡服務器的能力，看一下這個時間40秒能不能扛得住。而且剛剛說到一分鐘的緩沖時間，去掉40秒，還有20秒，就是留給網絡的消耗，還有其它的異常。40秒應該是可以的，所以預設了這樣的時間。

應用服務器

從頁面說起，前前后后涉及到的頁面非常多，比如搶票、門票、預熱傳播，最核心的一個頁面就是通過搖一搖進入的互動頁面。所有的頁面都是通過天貓統一搭建平臺進行搭建，是基于模板和數據分離，前端代碼只管邏輯，數據這塊會根據運營輸入商品坑位，還有廣告的數據，從另外一個系統輸進去，再把模板數據結合起來用基于Node.js的渲染引擎靜態化到CDN集群，手淘和天貓就可以提前幾天預加載文件，緩存客戶端，用戶搖一搖就可以很快進入到頁面了。

現在主要說一下互動頁面，其它頁面不講了，和常規頁面沒有多大區別。互動頁面是把所有環節功能都集成在這個頁面來，只要用戶進來不會做任何頁面跳轉，不管游戲PK，還是看廣告或購買商品。這樣我們也希望用戶有非常順滑的體驗，但是這么多功能集成在一個文件里勢必會引發前端開發協作問題，這個頁面前端開發有4個同學，可以看到頭部和尾部模塊是相對獨立的，和中間核心模塊沒有多大關系。所以這兩個模塊是一位新同學開發的，給他鍛煉的機會。中間核心部分用核心同學做。前端整個代碼結構是這樣，兩個綠色是新同學完成，對整個互動流程不會受什么影響，前端模塊分成四個，中間Ticker是心跳模塊，每分鐘執行一次，它在拿到時間表模塊，每秒計算一次，看下當前這一秒應該做什么。它判斷為應該切出寶箱，就會調用模塊秀事件，完成靠事件驅動調派廣告模塊和PK模塊之間的協作，分工非常清晰，這樣的話代碼之間耦合不會特別強，事件驅動。

有兩個模塊和后臺服務器有交互，一個是PLAN，一個是PK，都會向后端服務器進行數據傳輸。廣告和PK模塊有幾個事件。

重點講下后端架構是怎么扛住大流量的。

這張圖和剛剛看到那張圖有點類似，只不過進行了細化，把里面東西剖解開了。上面綠色部分其實就是觀眾端整體鏈路，下面一大半是后臺操作人員，技術同學操作鏈路，消費者端有兩條通道，這兩個通道都是阿里統一的定制的加密長鏈，會有比較好的性能和安全性。但是它會有什么區別呢？區別就是比如A server網關基于spdy，給pk模塊調用，有過載保護。它的特點是性能、安全性和穩定性都比較高，所以說抽獎環節和PK環節是這個。

第二個通道是HTTPS統一接入層，它的特點是易擴展，易切換，而且鏈路非常簡單，沒有任何篩選的狀態，也沒有任何系統依賴，所以它來做這個事情非常合適，而且非常靈活。準備了兩個雙通道來適配不同的接口。

根據雙通道就可以到達我們整個最核心的互動服務，這一塊內容就是我們團隊開發的一個東西，包括版本自檢、押寶情況、時間表、抽獎引擎等等。從后端開發同學的角度看，從晚會控制臺，他坐在水立方比較高的位置，有很多控制器的地方，能看到晚會所有場景情況，根據晚會情況會在晚會控制臺上做開關切換，比如第一輪PK開始就按開關，結果出來了是黑隊贏還是紅隊贏，黑隊贏就按黑隊開關。通過阿里內部的管理配置中間件往應用服務器直接寫內存的。一個應用涉及機器可能會非常多，這個管理中間件作用就是往這些機器同步推送數據，這也是經過了其它項目的考驗，非常可靠。

我們的后臺同學通過這樣的管理后臺往內存里寫數據，互動服務的應用程序從內存里直接讀取數據。為什么要用應用服務器內存，不用高性能緩存？因為高性能緩存跨機器訪問會有一定的網絡開銷。

優化經驗總結

這樣的技術架構，有幾點優化是非常值得參考的。

第一個是數據分離，公共實時數據（ 比如時間表 ）走高性能輪詢接口。用戶實時數據通過其它通道低頻訪問，按需訪問，把這些數據分離起來就能夠根據不同情況請求不一樣的接口，而不是把所有的數據都羅列在一起。

第二個是內存緩存，不用跨機器訪問。

第三個是輪詢時間可調，剛才說的40秒，那40秒只不過是一開始預估出來的，但是現場可能有很多突發情況，出錯時后臺有一個開關可以直接調節這個時間，比如通過這個時間表的返回告訴前端下一次請求是什么時候，比如后端扛不住了，就告訴它下次來晚一點。

第四個是精準控制時間，因為這個時間是非常重要，要把后端給你的時間點和當前服務器時間對比當前在干什么，每一次輪詢回來的數據都會取當前最新服務器時間。但是40秒之間的時間是需要JS前端自己計算的，這過程當中使用了本地時間差做判斷，每一秒加一秒。為什么不用本地絕對時間判斷呢？就是因為在iOS還有很多手機下面，滑動手機JS會中斷，很多動畫也會中斷，用時間差方式實時計算當前服務器時間是比較靠譜的一種方式。

容災設計

很多情況完全無法預估。再安全的車，上車一樣要系安全帶。下面談談我們是怎么做容災的。

第一，預防措施，輪詢時間接口40秒鐘輪詢后臺應用服務器，等它掛了或者扛不住怎么辦？我們準備了第二通道，把數據同步一份到阿里CDN集群作為backup，最后沒有用過，因為后臺扛住了這次壓力。對于前端來說，會有智能判斷，比如操作100秒如果還沒有獲取到最新的數據，可能會提示用戶你已掉線，請刷新再試的容錯。提前預防好之后，怎么做線上及時發現問題，發現任何異常情況第一時間處理。我們有數據大盤，押注情況，獎品大盤，一旦有異常會有預警，會發短信給開發學，或者釘釘也會有報警。

一旦發生了突發情況該怎么辦呢？剛剛說沒有解決bug的時間，但是我們還是要想一些措施。比如說后臺配置，剛剛說到中間件，雖然經歷了很多實際項目的鍛煉，覺得它很可靠，但是一旦功能上出現問題，如果有一個發布直接讓你東西寫不了內存怎么辦，后臺同學也準備好了直接命令行方式，調用接口，直接推送到服務器內存。對于前端來說，時間表輪詢接口上會發布如果有hot.js地址，我們會加載，類似于緊急補丁的方式。這是沒有辦法的辦法，我們還是想好了一條后路，萬不得已情況下只能用它了，如果發了新代碼上去，要把整個頁面代碼修改了，等用戶刷新頁面才能感受到了，基本來不及了。如果后臺有一個東西要處理，所有用戶即使不刷新手機情況下一樣能夠做事情，比如刷新頁面，或者提示都可以做。

上場的時候怎么接受住考驗的？提前將近十幾天到達北京，每隔兩天都會去一次水立方，熟悉環境，比如到時候坐在哪里，視角是什么樣的，洗手間怎么走。比如網絡狀態，我們對于網絡依賴非常強，所以讓阿里集團IT部門準備了有線給我們，絕對不依賴無線。還包括設備，要一臺電視監聽觀眾看到情況是什么樣的，包括所有彩排過程都需要技術同學參加。因為彩排過程當中會發現一些問題，哪怕細小的問題也會帶來災難。比如彩排過程當中發現黑隊和紅隊電視大屏和我們頁面是相反的，我們發現了這個細節，及時改過來了。把環境熟悉好之后怎么進行人員部署，在杭州的團隊怎么支持我們北京的團隊，我們會有遠程視頻，要客服協助，或者其它團隊協助，杭州團隊能夠實時通過視頻會議的方式及時傳遞給他們。包括操作的時候，每個開關都是要有觀察、執行、監督，至少三個人配合做這個事情。測試就是雖然有監控系統能夠及時發現問題，但是還是需要發動團隊的力量，比如他在使用的時候要有一個人押黑對，一個人押紅隊，一個什么人都不押，線上項目也必須分派任務給到團隊同學不斷感受現場是什么樣的。

跨團隊協作

跨團隊協作的事情，集團性項目涉及到非常多的團隊協作。

要做這樣直播類型很強的互動，我們做的那場晚會基本是空前的，每個環節都保持和手機同步，要提前跟導演組溝通。我們去長沙好幾次，去一次發現郵件當中溝通都有出入，這時候就不能懶惰，一定要提前溝通，越早越好。

再就是UED，這塊非常重要。因為互聯網的項目迭代非常快，上線前一天晚上都有可能讓你全部重新做頁面，或者要有很多素材。前端同學和UED同學成為非常好的朋友，彼此了解，我們這次項目在北京這幾天前端和UED是睡在同一個房間的。就會溝通怎么改才能產生最好的東西，這種平衡成本和效果的事情需要雙方溝通，而不能是上下游的關系。這些經驗我總結為一點，互聯網的項目千萬不能用傳統軟件開發習慣來開發，上下游的方式是不行的。因為像這樣迭代非常快的項目，需要技術同學忘記自己的角色，大膽走出一步，這樣所有人都會變得更出色。

包括和測試同學，會給我們的bug進行分類，高優先，低優先，適配問題還是什么，分得很細。很快定位到問題。做這種項目雖然精神壓力很大，但是臺下臺上要膽大心細，有條不紊。

狂歡城

狂歡城是天貓歷史悠久的項目，這是近三年來狂歡城的截圖，每一個界面都有七八屏的滾動，有達到3000-4000像素的場景，所以頁面是非常龐大的。

它面臨的挑戰首先它是素材非常多，場景很大，有很多兼容性問題，動畫也多。

因為一個狂歡城里面涵蓋了上百個品牌在面，海爾是海爾兄弟，會有動畫在里面，所有品牌動畫加起來一起動的時候頁面一般團隊開發出來都沒法跑起來。那怎么解決渲染很流暢呢？也是三步走，第一步資源處理，盡量減少圖片的大小，通過重復利用的小圖片拼接大背景，這樣減少圖片的數量。第二地圖編輯器，UED想改任何圖片，只要在編輯器里進行上傳和替換，就不需要開發介入了。

第二個加載控制。加載限流很多瀏覽器加載資源的時候是不會做限流的，有的時候同時加載20個，有時候同時加載10幾個。通過程序方式一次最多加載4個文件，排隊加載，用戶滑動就不會很卡，內存就會優化比較好。

加載下來之后剩下渲染過程，我們也做了很多優化，比如視窗內渲染，存在canvas cache上面，第二次滑再找出來，不會做重復渲染。所有步驟，資源處理和加載控制和渲染過程都考慮到了終端的適配，講究因地制宜，不但在終端跑起來，一定要發揮終端最佳優勢。比如App上面就可以做到本地緩存，以及預加載拉文件下來。在高端手機里可以用canvas，再別的就可以flash。

做了這么多優化，前端工程師很難得能夠把經驗沉淀下來，任何好的方法和實踐都需要工具化。只有把它工具化包裝起來才能夠讓更多人享受到開發效率的提升，才能夠影響更多團隊，我們也是沉淀下來了Hilo引擎，能夠提供給兄弟單位，比如阿里媽媽，他們就不用做這樣事情，簡單用一些接口只關心業務就行了。渲染，包括加載，都交給Hilo做。

Hilo組織結構非常簡單，只有幾個核心對象，主要是有事件系統，渲染系統，擴展的方法在里面。

Hilo是用什么原則沉淀的呢？首先核心要非常非常簡單，因為市面上其實有很多動畫引擎，有很多游戲引擎。但是他們都是為游戲而生的，我們有很多場景也和游戲很相似，但是又不同在于電商互動營銷要非常快，比如一周要產生一個項目，要學習成本非常低，而且你的代碼要非常極簡，所以在這塊盡量降低學習成本，只有非常簡單的幾個核心結構，不會有太多的復雜東西。能夠讓你快速上手。

第二渲染模式開發者可以不用關心渲染模式，Hilo可以很智能判斷什么終端下采用什么渲染模式，只要你把這個業務層面東西做好就可以了。拓展工具這塊不講了，如果核心模塊滿足不了需求，可以很方便擴展自己的一些工具，比如基于Flash，通過Flash IDE快速生成H5的代碼。

Hilo已經正式對外開源，有興趣的可以了解一下。

來自： http://www.infoq.com/cn/articles/tianmao-interaction-solutions