天天看點

移動極速傳遞體系

在雲栖techday活動第二十八期上,淘寶無線技術專家子之講述了如何快速建構一套用于支撐營銷類型産品的快速傳遞體系。他提出具體的解決方案是通過不同複用類型的活動解決方案的組合,以最快的效率達成業務上的訴求。

業務特征

營銷活動形式多樣,且經常在雙十一這樣的焦點事件中。

移動極速傳遞體系

上圖很好地反應了營銷類業務特色:以雙十一為分界點,在此之前手淘使用者線上整體流量比較平穩;但在雙十一之後,整個模型發生突變,呈過山車式,流量在前一分鐘激,在下一分鐘又會下降;在這種業務特色下,開發團隊面臨着巨大的挑戰:首先是超大規模流量,峰值達到百萬,這對系統的性能、靈活性、穩定性都有很高的要求;其次,這類活動通常線上周期短,但活動頻次由特别高,會面臨很多活動臨時疊加功能等各類問題。

無論是阿裡這類的成熟公司還是小型創業公司,對于營銷活動而言,都面臨着共同的境遇:一是傳統工程模式笨重、耗時,跟不上業務前進的腳步;二是營銷活動在開展過程中,有很多事情單靠前端無法完成,還需要多個服務端、用戶端配合;很多情況下都是拼體力、重複勞動,缺乏技術積累。

極速傳遞模式

經曆了一系列痛苦之後,在2014年初,提出來釋放生産力,規模化地快速解決此類問題的方案——極速傳遞模式。

移動極速傳遞體系

從宏觀上看,所有的公司擁有的資源和面臨的環境都是一緻的。是以,可以把活動進行分級,将業務和團隊業務做了分開,其中一部分業務稱之為模闆,可以直接快速配置完成此類業務開發;還有一部分是插件組裝業務,需要提前進行積累;剩下的業務就是真正需要研發的業務,每一級别的業務都對應着不同的解決方案。其中對于高複用類型的部分需要模闆化,使得可以通過配置直接完成;部分複用的共性功能插件化,以便于快速組裝;對于真正需要研發參與的業務,要做到提速不可複用類型活動的研發。

<b>模闆化</b>

移動極速傳遞體系

在模闆化方面,首先需要将需求進行梳理,之後再将其輸出到前後端的模闆上,通過在該模闆上添加一份資料配置生成活動。換句話說就是将活動拆為模闆和資料配置兩部分,線上所有活動都是由n個模闆和m份資料配置生成nxm份活動。

模闆基本上作為活動原型,需要通過平台進行執行個體化去生成活動,然後再通過資料配置完成差異化和素材内容的填充,最終生成線上活動,整個過程開發人員不參于。

移動極速傳遞體系

在模闆方面,對淘系業務而言,相對較為單純,早期無非是各類流,如圖檔流、卡片流等。其中圖檔流失通過圖檔+連結可以完整表達所有資訊,具體實作是将頁面切成很多行,每一行都是一個小區塊,在前端代碼處理上,每一行内的圖檔會根據上傳時的尺寸自動布局分割。

除了前端模闆化之外,還向後端進行了延伸,在服務端進行模闆化,首先将業務進行抽象,之後再利用服務加資料的方式生成對應的活動接口。通過服務端模闆化,手淘團隊也沉澱了一些互動系統,如抽獎系統、排行榜、淘密碼服務、活動評價等等。

<b>插件化</b>

移動極速傳遞體系

模闆化看起來是解決了很多重複性工作,但對于差異化的部分,模闆是無法滿足需求的。是以,手淘團隊将這部分差異化的東西元件化,如淘長圖、雲中轉之類,可以通過配置化的方式讓被人将各個元件去合成最終的業務。

移動極速傳遞體系

這其中的核心點在于通過系統增加上資料配置,一般營運人員是不懂技術的,為了便于營運人員使用,開發了mt頁面服務。在mt中,資料定義分為面相開發者和營運人員兩類。

開發和營運人員操作完成後,如何将這套服務提供出去呢?實際上,資料平台本身作為一個獨立的服務,該服務共分為幾塊,一塊是小二背景,它隻完成兩件事情:資料的定義個資料的填充。小二平台做完後會把這些資料送給資料服務子產品,資料服務子產品将資料存儲下來,并通過cdn、mtop以及其他服務提供給他人使用,最終通過cdn或者其他安裝服務,讓用戶端、h5頁面都能夠直接使用。   

<b>研發提速</b>  

對于buy+這類産品,是沒有任何元件可以利用的,屬于一個全新的項目,能夠做的就是研發提速:首先在服務端上化繁為簡,進而使得用戶端更加靈活和自由;同時希望前端互動開發更輕松一點,效率更高一些;還希望能夠和業務公共成長,有一個資料看闆即時回報結果,能夠在業務上做一些判斷。

<b>服務端上化繁為簡</b>

移動極速傳遞體系

在服務端的接口層面抽象,将所有的api統一成一類api,這一類api分為三種:普通不可登入接口、普通登入接口、安全登入接口。在入參上面,将參數分為兩種,第一種是活動辨別;第二種是活動入口的參數。基于這個模型,把所有的api歸納成一個統一的api,前端隻用這類api即可。這類api 沉澱為aplatfform平台,該平台使用groovy作為開發語言,工程成本較低,内置了測試工具,可以快速完成api測試、腳本管理以及釋出管理等等事情。

<b>用戶端更加靈活和自由</b>

服務端問題解決後來看一下用戶端問題。用戶端的核心問題比服務端更嚴重,首先用戶端上線以及下線的節奏會難上很多倍,通常而言服務端代碼寫完之後,還可以進行流量測試,判斷哪些功能被使用,然後再進行相應的功能删減;但用戶端不行,因為用戶端不知道誰再用,也不可能把所有的使用者日志全部記錄下來,隻能采用抽樣的方式,去抽取一些核心名額。是以,一旦新功能上線之後,在用戶端功能是不敢輕易下線的,進而導緻手淘安裝包的大小一直在增長。該怎麼解決呢?我們通過額外的東西實作在不增加手淘版本的情況下完成對ui和api功能的擴充,對應的産品分别是poplayer和slience,現在來重點介紹下slience(poplayer在其他分享中會重點介紹)。

移動極速傳遞體系

silence項目是在2016年雙十一之前啟動的,之是以叫做silence是因為它完全不需要使用者主動更新,是一個純靜态的行為。silence設計用來在無需發版的情況下,動态加載腳本來擴充用戶端api功能;服務端通過配置下發腳本到用戶端,用戶端通過hotpatch/dexloader機制動态加載類,h5調用統一的jsbridge,通過路由調用具體的方法。silence的好處是可以随時随地擴充用戶端功能,而且不增加用戶端安裝包大小;下線後删除腳本不堆積在用戶端,對于增加性能消耗的功能,隻在腳本運作期間産生額外開銷。當然,也存在不足之處,silence是基于腳本設計的,它都c層的api幾乎完全無力支援,并且性能會比原生更低點,不适合做太複雜的運算邏輯。

移動極速傳遞體系

那麼silence是如何建構的呢?在server端,通過在雲端完成整個腳本的釋出和打包,加密後再發送到cdn上,将cdn作為下載下傳的入口;腳本準備好之後,同時再通過orance推一份配置給到用戶端;orance會告知腳本管理系統需要下載下傳所需的腳本,下載下傳的前提示腳本要足夠的小,在幾十k到一兩百k之間;對業務來講,大部分是通過h5或poplayer這兩個入口進入,這兩個入口通過jsbridge api調用silence子產品,然後該子產品會根據活動辨別判斷是否存在此類活動,如果有此類活動,則會将該活動加載起來,這裡可能會出現兩個意外,一是沒有得到配置,也就是腳本上不存在該配置,此時需要去服務端主動查詢是否有該活動;第二是配置上有,但腳本不一定有,如果沒有腳本會嘗試下載下傳腳本并且運作,通過這種方式可以非常靜默的讓手淘版本快速獲得native的功能。

互動常用的動畫開發模式

移動極速傳遞體系

在前端開發時遇到一個嚴重的問題,當在開發互動項目時,營運人員不斷提需求,希望動畫效果更加炫酷,有更多的互動。傳統的方式需要設計人員先進行設計,之後再将設計成品導成視訊檔案或flsh,便于技術人員使用。也就是說,在沒有一個完整的動畫解決方案之前,大概需要一個專家級别的工程師耗費一天才能完成這一個動畫的制作,耗時耗力。

移動極速傳遞體系

為了降低動畫開發成本,我們提出了aft解決方案,希望通過aft解決方案,将動畫描述變成一個api接口,降低開發成本;同時使得動畫元件積累可複用,同時降低與設計師的溝通成本。

移動極速傳遞體系

基于aft開發模式,我們希望在建構動畫這件事情上有所積累,讓技術同學真正從體力活中解脫出來,與設計師處于一個相對自然順暢的溝通模式,讓一線的施工者轉變為設計者。是以,需要配合者整個設計工具和設計體系與工程師一道通過ae/ac等動畫工具,去導出aft可以消化成品。是以會将其進一步向dsl和解釋器方向發展,最終的目是能夠像做模闆一樣,将重複的簡單耗體力的事情快速解決。

移動極速傳遞體系

經過上述優化,目前可以做到産品5分鐘上線,但是該産品的效果如何,并不可知,該怎麼辦呢?通過将上述系統所有資料結合,打通業務與行為資料,形成統一的報表,定義出在互動領域的模型;再通過該模型進行一些基礎的資料分析;再加上實時的名額進行彙總。在整個過程中,資料埋點與收集全部自動化進行,開發與業務可以不用關心,可以通過資料看闆即時檢視回報結果。

移動營銷極速傳遞體系

移動極速傳遞體系

上圖是移動營銷極速傳遞體系的技術層面的大概框圖。根據需求進行模闆化、插件化、測試支撐、投放支撐以及資料看闆等等,形成了較為完整的解決方案。除了技術層面之外,也進行了其他層次的探索,例如根據前端和native能力進行webgl、webvr、ar、3d等探索,旨在為未來應用降低成本,快速上下線。

移動極速傳遞體系

最後來看一個經典的極速傳遞實踐案例。雙十一期間紅包項目發送總金額有九千萬左右,這九千萬分三天發放,每天幾千萬,雙十一當天是六千萬左右。整個項目是通過poplayer提供的火山彈出管道,在會場和首頁彈出紅包火山,在開發時首頁和會場頁都不知道紅包火山的存在。

在整個過程中,slience提供了與首頁的關聯能力,能夠從首頁滾動到底部;流量方面,利用aplatform承擔流量中心,能承受瞬間百萬量的級别;抽獎采用wlp承擔,同時采用aft制作動畫,加快了項目研發效率,可以說整個項目中幾乎用到了所有的基礎技術。

在雙十一快結束時,交易額已經突破一千億,當時老闆希望整個交易額能夠湊個整數,需要再發紅包。老闆的決策是在11點下達的,從需求到上線最終隻用不到半個小時。如果采用傳統的方式根本不可能完成,但通過poplayer和投放系統合作,将紅包火山再彈多次;其次在搜尋中又添加了其他指令,瞬間完成任務。

總結來看,之前做營銷活動,更多的是煎熬,是在拼體力;但是有了今天這些解決方案之後,創造了很多不可能。将精力從上線、釋出、測試中解決出來集中于攻克技術難題,提高使用者體驗以及業務邏輯的完整性。