十年磨一劍 | 淘寶如何打造承載億級流量的首頁？

阿里妹導讀：手機淘寶做爲整個互聯網領域旗艦 APP 之一，裝機量和用戶訪問量都是名列前茅的。而首頁做爲打開手機淘寶的門面，是淘寶電商領域的主要流量入口和服務消費者的核心陣地，其業務的複雜性之高、系統的穩定性之重都有着極高的要求。首頁承載着很是重要的業務使命，負責整個阿里生態的業務分發和商業策略輸出。隨着淘寶無線化戰略的升級，首頁也從 PC 時代類目導航的導購模式升級爲無線時代個性化推薦的導購產品，從傳統的千人一面走向將來的一人千面，決定了首頁多樣性、創新性、多變性業務特色。

背景

和貓客、飛豬、盒馬、閒魚等APP同樣，首頁不管在哪一個體系下都是主要的流量入口，分發效率一直是咱們追求和解決的核心問題。

如何讓最優的商品和內容高效的觸達消費者側，提高流量價值，一直是咱們追求的目標之一，截止當前咱們進行了不一樣方式的探索，實現和積累了一些策略來解決這個問題。

當前首頁根據不一樣的地域、人羣劃分出「大陸版」、「親情版」、「村淘版」、「海外版」的業務版本，這些版本即傳承手淘首頁的通用能力，同時經過自身運營的自由度和獨立體系，展現本身的垂直區域特點內容，更加高效的觸達自身服務範圍的用戶。

好比「海外版」是針對非大陸用戶之外的香港、臺灣等地區的頁面投放，「村淘版」則是圍繞鄉村地區，實現村淘的業務目標的重要的流量分發渠道。「親情版」則是針對家庭關係用戶進行業務模塊的精準分發。

新的挑戰

隨着首頁總體業務策略的不斷調整以及技術棧的不斷升級，咱們嘗試基於人羣、地域等屬性進行的細粒度的人貨匹配的運營策略。

一方面經過爲不一樣人羣定製差別化的視覺樣式、用戶路徑、貨品供給培養特定的用戶產品心智，另外一方面經過平臺能力快速靈活的進行頁面佈局調整，能讓需求爆炸式增加的同時也能快速的響應。

同時在面對提高分發效率上面不斷演進的運營策略升級，須要咱們技術側提供一套高效穩定的常態化的運營體系對其進行支撐，對咱們技術系統的建設也提出了極高的挑戰，這裏的挑戰既有業務的也有技術的。

多版本隔離運營

這裏面有兩個關鍵字「多版本」和「隔離」，其中「多版本」是基於業務訴求的考量和抽象，面向用戶的基本實體就是頁面，這些頁面主要由頁面佈局、貨品供給、素材渲染幾個因素構成，而針對不一樣目標羣體須要有所差別化的透出，因此就須要在頁面級別、模塊級別和坑位級別針對不一樣人羣、地域進行多版本的搭建運營。

在完成「多版本」運營的業務訴求的一個大前提是基於穩定性的考慮，「隔離」很好的詮釋了在多版本下首要去關注的穩定性要素，一方面要保證不一樣版本的變動所帶來的跨域影響問題，另外一方面是按業務租戶的方式爲不一樣的業務開闢獨立的運營體系，基於以上兩方面考慮咱們總體採起容器化的隔離機制實現業務運營之間的操做帶來的風險規避。

因此在打造運營平臺體系首要考慮的就是如何支持多版本下的隔離運營能力，大陸版、海外版、村淘版、親情版這些獨立的業務版本下如何自由的、穩定的衍生本身的方案投放是咱們首要考慮的問題。以下圖所示，是咱們經歷一場大促不一樣時期首頁須要備戰的方案矩陣。

快速靈活佈局搭建

提及搭建，阿里集團生態體系下不乏有一些優秀的產品，好比天貓 Zebra 系統、淘寶 TMS 系統等，都是在頁面搭建領域具備極高的產品口碑，基於靈活的模塊化機制，致力於讓運營同窗能快速地搭建出符合業務需求的頁面。

手淘首頁的頁面搭建做爲咱們平常工做中一類高頻率的運營操做行爲，須要高效、靈活的平臺化解決方案，才能提高咱們總體的研發模式和產出效率。因此咱們以提高效率爲目標，提高協同效率爲訴求，一方面能夠拉動運營角色參與到手淘首頁體系的平常建設中，另外一方面能夠更加高效的產出不一樣業務場景的頁面佈局。

以下圖就是三套頁面方案的模塊差別。

流量運營閉環建設

在首頁大流量的場景下，任何業務決策的調整就像一把雙刃劍，一方面可讓業務在這樣的體量下快速孵化快速迭代，另外一方任何調整在這樣大流量的衝擊下問題都會被成倍放大，風險和收益共存。

因此首頁缺乏一套從運營策略、數據收集、業務決策的閉環體系來使業務快而穩的奔馳。在過去的時間裏咱們沉澱了不少能力孤島，單看每一個島嶼都是一個完整的生態，可是島嶼間橫跨了無盡的大海，這樣不構成流程化體系化的平臺，不管運營、開發、測試都是相互割裂的實體。

從運營路徑來看，這些單點能力只會讓他們只有輸入沒有輸出，走了一步不知道下一步該怎麼辦，因此咱們要基於科學的運營體系構建流量運營閉環。

組件抽象和複用

何爲組件？

組件（Component）是對數據和方法的簡單封裝，組件能夠將 UI 切分紅一些的獨立的、可複用的區域，這樣你只須要專一於這些單體的邏輯開發。

因此咱們基於組件化協議將整個首頁 layout 進一步拆分紅多個組件，其中每一個組件構成頁面的基本單位，用於渲染單一業務的基本區塊。

首頁的組件渲染是典型的 MVVM 的模式，端側( View )和服務數據( Model )經過組件化協議( ViewModel )進行雙向通訊，一方面經過抽象組件協議解耦兩端的耦合性問題，另外一方面經過實例化組件實體完成了頁面間的複用問題。

那組件協議自己的抽象和定義是咱們首先須要去面對的問題，設計過於複雜、抽象過於碎片會使協議難於維護先後端聯調溝通成本放大，設計的過於精簡、抽象過於大支又起不到解耦的效果，這些都是須要咱們長期思考和解決的問題。

動態化和實時性

前面幾項總結其實都是基於業務上的挑戰，而技術層面真實要面對的主要能夠分爲動態化和實時性的問題，動態化是實現實時性的主要手段，實時性又是動態化的方案考慮首要因素。

首先從業務訴求上面講，首頁是一個典型的中心化業務場景，快速響應是咱們首要面對的問題，平常須要頻繁根據業務策略調整佈局，以從新分配流量，特別是大促態下，調整尤其頻繁，對動態化和實時性的要求極高。

現現在需求量與日俱增，變動迭代速度從過去天級別到如今小時級別，就是在動態化和實時性上面作了不少體系化的建設，其中一方面咱們在端側協議引入了新奧創和 dinamicX 的動態化解決方案，另外一方面服務端上面作了不少諸如 FAAS 化的動態化數據編排的能力，使咱們在實時性上面有着不俗的成績，不管是業務上線、功能迭代仍是異常回滾都是在秒級生效。

關鍵變革

面對諸上不一樣維度的挑戰和難題，若是利用傳統的技術架構和產品體系遠遠不足的，不管是在團隊協做、流量管理、研發流程都存在很大的問題。

因此，咱們須要變革，變革是對事物本質的改變，是對如今不完美的洗牌，是不斷的選擇妥協和修正，這個過程是痛苦的艱難的，可是咱們堅持下來了。

端側協議升級

在咱們體系建設以前端側協議仍是面向場景的單向協議，先後端的耦合度十分高，改動週期按月計算，迭代成本巨大。爲了更好沉澱運營體系，提高效率，咱們客戶端和服務端對協議作了深度的分析和抽象，從兩方面進行了升級和改造。

一方面針對組件協議進行了更高的抽象和升級，完全完成了首頁體系下的組件化的改造，將面向場景的開發模式轉變成面向容器的開發模式，從而下降客戶端和服務端的耦合性，提高了組件的複用性和擴展性。

另外一方面咱們引入了端側兩大動態化解決方案，其一新奧創協議，該協議抽象了數據、事件、佈局、模板的協議結構，核心是以頁面動態化技術做爲支撐，同時將動態化覆蓋到native，h5等場景。另一個是DinamicX的模板化解決方案，DinamicX在組件的粒度實現了佈局的動態化，從而提高了業務總體的迭代效率。

試金石的產品體系建設是就是基於以上組件化協議和端側動態化方案之上，擴展和沉澱了基於導購域特有的上行和下行標準，增長動態分頁、導購域特有事件、 SPI 擴展等內容沉澱的一套面向運營閉環的平臺化產品。

研發模式升級

前言中提到首頁的第一要務是要在巨量 DAU 的挑戰下知足整個阿里生態的業務分發和商業策略輸出，因此勢必決定了首頁是一個典型的中心化開發模式場景，集團幾乎全部的核心業務都須要在首頁進行孵化和表達，在這樣的背景下咱們面臨着兩個主要矛盾：

中心化研發模式與業務需求爆炸增加的矛盾：一方面核心業務在首頁的UI和業務邏輯發生變動的時候，大部分需求都會由首頁技術團隊來拆解和落地，另外一方面首頁產品自身也在快速迭代和創新。當大量的業務創新碰到中心化研發模式時，帶來的必然是需求的堆積與迭代的變緩。而爲了解決這樣的問題，一般解法只有兩個‘排期’和‘簡化’，排期能夠優先保障效果，帶來的條件就是上線時間沒法按時。簡化能夠快速上線，帶來的條件就是效果達不到預期。

業務快速迭代與系統穩定性的矛盾：咱們生活中作事情經常被要求更快更好，然而快和好自己就是矛盾體，經常只作到好或者只作到快。在需求體量到達必定程度以後，資源不夠是一方面，單資源所能投入的精力也是有限的。要保障業務快速迭代，就須要頻繁的變動和實時的生效，頻繁和實時自己就會帶來穩定性方面的問題，並且最爲重要的在首頁這種大流量下一些小問題不易暴露和發現。

涅槃重生

咱們從問題本質出發，找到切實有效的解決方法來應對挑戰和問題，借用一下樑寧老師釘子與洞的類比，用戶須要打孔機，是否是給用戶生產一個打孔機仍是說爲用戶牆上打個洞，因此問題的關鍵是咱們須要提供什麼產品或服務讓用戶的牆上有個洞。

通過團隊成員屢次實踐和嘗試，圍繞着複雜多變的業務場景，基於打破傳統研發模式，構建出基於數據化運營的搭建、流量、資源和數據的閉環，試金石橫空出世。

可視化組件搭建

將首頁的業務形態進行模型抽象，分別抽象出頁面場景、頁面版本、頁面方案三個維度對一個首頁產品體系進行描述，基於這套模型體系進一步將頁面模塊進行組件化抽象，多個組件構建成一個頁面方案，而且和流量運營側進行打通。

可視化組件搭建能力建設核心要素是兩個，一個是組件模型的抽象，上文中提過「設計過於複雜、抽象過於碎片會使協議難於維護先後端聯調溝通成本放大，設計的過於精簡、抽象過於大支又起不到解耦的效果」。

因此咱們使用動態 schema 的方式定製化組件協議，由業務按需設計，既保證了協議標準又能夠支持業務差別化；另外一個要素是可視化能力，咱們藉助 DinamcX 的動態 H5 渲染效果完成可視化的能力建設。

系統化流量運營

首頁核心是解決流量分發效率的，工欲善其事，必先利其器。

提供一套系統化的流量分配運營體系是咱們構建試金石的初衷，也是試金石所能帶給業務的最大價值所在，前文提到首頁做爲流量入口，幾乎全部的核心業務都須要在首頁進行孵化、創新和表達，在這個過程當中不只須要AB實驗的這樣的方案最優化途徑，還須要灰度小流量上線模式，既要保證業務的迭代還要保證系統的穩定性。

咱們主要從三方面建設，分別爲：

• 分流點設計，經過設計可擴展的分流模型，有效的把控流量的走勢；
• 投放規則沉澱，經過原子化的規則設計，保證流量的精細化；
• 數據通路建設，經過進行埋點協議設計並進行數據迴路實時反饋結果。

標準化研發流程

試金石打破首頁中心化的研發模式，重塑多角色使用路徑，將需求迭代變動流程細化抽象，將開發配置流程拆分。

一方面讓鏈路流程標準化，減小人的溝通協做成本。另外一方面將平臺產品化讓更多的角色參與進來，達到提高研發效率的目的。同時接入測試的自動化工具，使業務頻繁變動和系統穩定性達到平衡。

總結

試金石體系具有了搭建、投放、分流、數據四個方面的平臺產品化能力，共同構成一個以數據化驅動的運營體系，支撐了首頁、輕應用產品的快速迭代，可承載業務策略秒級快速上線，承載同時億級用戶的流量衝擊，在雙十一狂歡節期間咱們連接起18萬品牌到6億消費者的流量通道，保障狂歡節期間拿下 2135 億的成交額 。在覈心大促雙12、年貨節、春晚期間爲消費者購物保駕護航，提供穩定如絲滑般購物體驗。

咱們完成了階段性目標，讓運營和研發成本下降了一半、讓運營能夠參與到頁面搭建、流量分配中來，使中心化的模式得以釋放，提高了首頁的總體的研發效率，後面還有不少優化和功能的迭代等着咱們，還有更多的場景須要咱們去支持，咱們有信心咱們有理由相信試金石會更好！

最後，淘系技術部基礎鏈路技術研發團隊，致力於經過構建高流量、高併發的分佈式系統架構支撐業務先贏，經過有挑戰性的技術攻關提升技術先進性，經過科學嚴謹的方法提高業務迭代效率，成爲淘系業務發展的新引擎,歡迎熱愛技術，對業務有好奇心，有合做精神的同窗一塊兒工做、成長，簡歷可投郵箱：qingyuan.ygw@alibaba-inc.com。

---

本文做者：卓雪寅（寅清）

閱讀原文

本文來自雲棲社區合做夥伴「阿里技術」，如需轉載請聯繫原做者。