阿里妹導讀：手機淘寶作為整個互聯網領域旗艦 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 億的成交額 。在核心大促雙十二、年貨節、春晚期間為消費者購物保駕護航，提供穩定如絲滑般購物體驗。
我們完成了階段性目標，讓運營和研發成本降低了一半、讓運營可以參與到頁面搭建、流量分配中來，使中心化的模式得以釋放，提升了首頁的整體的研發效率，後面還有很多優化和功能的迭代等著我們，還有更多的場景需要我們去支持，我們有信心我們有理由相信試金石會更好！
最後，淘系技術部基礎鏈路技術研發團隊，致力於通過構建高流量、高併發的分佈式系統架構支撐業務先贏，通過有挑戰性的技術攻關提高技術先進性，通過科學嚴謹的方法提升業務迭代效率，成為淘系業務發展的新引擎,歡迎熱愛技術，對業務有好奇心，有合作精神的同學一起工作、成長，簡歷可投郵箱：[email protected]。
閱讀更多 阿里技術 的文章
