持續迭代的電商可視化運營頁面生成系統

上個月在前端早讀課作了一次關於「可視化運營頁面生成系統」的live，本篇文章是此次live的文字記錄。

在電商領域，活動運營扮演着極爲重要的角色，一場成功的運營活動甚至能夠爲公司創造數千億的成交額。因此，服務好運營同窗，是技術團隊必需要作好的重中之重。縱觀轉轉發展的幾年時間內，隨着公司規模增加，運營團隊成員呈現急速擴充趨勢。相對的，技術側資源緊張的弊端則日益凸顯，如何用極少的人力hold住大量的運營需求，相信不止轉轉，每個高速增加中企業都有着相似的訴求。

而本場live中，咱們將會從運營活動的基本特性出發, 透過實際應用案例，推斷出活動頁面生成系統的核心需求，最後引伸出一套維護成本低，可持續"自我進化「的活動頁面生成系統，由於這個叫法過於拗口，因此下面咱們將簡稱爲可視化系統

首先明確一點，這套系統是服務於公司內的運營同窗幫助他們提升產出效率的工具。注意，「公司內」這一點很是之重要，由於他給定了一個子集。

• 你們看第一條，類比於你們都熟悉的標準的運營模型AAARR(獲取用戶, 提升活躍度, 提升留存率，獲取收入，自傳播)，由於咱們做爲一個逐漸打磨產品的創業公司，現階段運營實際上是用戶獲取，激發活躍，提升轉化率這三個方面的，這就是咱們的子集，換言之裂變玩法，自傳播這塊就暫時不須要投入太多精力去作。
• 第二點，最快速度，最低成本，質量尚可，衆所衆知，大部分運營活動常常卡某個時間點上線或者追熱點，並且持續時間很短，因此投入太多資源打磨產品是沒有必要也不現實的。
• 第三點，多端投放，渠道投放進行引流，因此其實這種需求對於運營這塊快速兼容各類app是有很高要求的，由於瞬時峯值很大，因此結構要設計的儘量簡單，這點我們放在後面的部分詳細談。
• 而後第四點，也是最重要的部分，公司方向慢變量，運營效果快變量。借用何帆老師在變量裏面提到的變量的觀點，快變量很好理解啊，今天咱們發放了一筆優惠券，4毛100塊，過了兩天發現運營搞得特別好，全國人民都知道這事了，可是花的錢太多了，怎麼辦？動態的須要調整。金額，中獎概率，法律條款，文案，甚至圖片顏色，一位富有經驗的運營同窗須要時時的監控數據的變化並進行快速調整，並且經常半夜守在公司，因此你們在碰到運營汪低聲下氣的求着改文案的時候，也千萬要體諒一下他們。
  公司發展慢變量，這個就厲害了，他是指公司戰略層面進行調整， 持續增加，變現能力，一切經營活動都是緊扣一個主題進行的。若是想在一個階段內支撐好某個旋律，就必定要有快速跟進甚至打好提早量的思惟。有人說這個是否是太虛了。好，讓咱們來看一組數據。

左邊的圖是週末統計出來的咱們可視化平臺上面的組件使用狀況，最內圈上面的兩種顏色是我特別追加上去的，較淺的表明2017-2018年上半年紅包發放組件佔總體活動頁面的比例，大概是40%-50%之間，而18年下半年急降至不足20%，相反，對於商品展現流組件的需求大大提高。這是因爲公司戰略由拉新用戶逐漸傾斜於訂單轉化率的大格局致使的，若是前瞻性的定製了大量紅包組件的功能，最後的結果多是很糟的，中臺面臨的最尷尬問題，辛辛苦苦作出來東西可是沒人用。這種滋味並很差受。

眼尖的同窗已經注意到了，除了說明公司大戰略變化對於可視化平臺組件需求的影響，這張圖片還有幾個更有趣的數據，紅包組件，圖片組件，商品組件在該平臺的使用率分別達到了79%， 71%和20%。而這三個高頻組件組織在一塊兒使用率高達72%。換言之，這三個組件提供了可視化平臺3/4的能力。若是您是一個小型電商公司，開發好這三種組件混搭佈局的方案足以解放大半研發成本。
仍是想象不出來？讓咱們看下實際樣例。

看着各類花哨的頁面，但其實本質上面就是三種組件組合成的專題頁面，看吧，在電商領域，作好了這三個組件，你的可視化系統已經可以生存下來了。

好，講了一些業務層面的東西，如今足以支撐起咱們作技術上的選型與判斷了，咱們思考一個最核心的問題，可視化系統的技術難點究竟在哪？像axure同樣的自由佈局方案？事件流編輯器？組件的協同工做？談到可視化編輯你們第一反應必定是上面印象。可是相對的，複雜的技術對於研發投入，維護成本彷佛不低。甚至對使用者來講門檻也顯得比較高，借用業界的一句靈魂拷問來講：不會寫前端的人就會用sketch了嗎？。並且，並且業務迭代頻繁，接口不統一，各類問題都會讓狀況變的複雜。公司在變，時代在變，設計一套系統以不變應萬變，難。

因此，咱們決定作的簡單一點，作一個專一於頁面生成發佈，組件粗粒度編輯器（就像前面提到的三種組件），同時，經過持續迭代和自定義組件賦予她無窮的可能性。面向運營，也擁抱開發者。

生存還遠遠不夠，回顧一下標題，持續迭代的的電商可視化運營頁面生成系統。是的，咱們不但要生存下去，還要迭代，發展起來。因此咱們提出了在這三大組件上面的漸進式開發策略，下沉到各個業務線上，一步一步的迭代出各類垂類組件。仍是有點抽象？不要緊，我們再具體一點。

左邊是咱們的雙十一預熱抽獎頁面，這是一個典型的與業務同窗一同混合開發專題活動，在第一次迭代過程應用了圖片組件，商品流組件和自制抽獎。然後分別定製了推薦組件和秒殺組件進行替換。抽獎組件最開始是所有內容接口寫死的，但隨着以後的活動咱們開發了接口的配置項，獎項配置，皮膚配置等等。這個過程是全程持續交付的。運營同窗能夠經過咱們的可視化編輯器隨時調整，因此在咱們的方案裏，可視化平臺的核心也是一個組件化交付平臺。

下面開始基本就是乾貨了，我將重點講一下咱們的可視化平臺魔方系統，工做原理及架構圖，可視化仿真器以及插件系統。

首先來看下咱們的主界面，分紅預覽區域和編輯區域兩部分。魔方的特點在於左側預覽區域採用了「仿真器」的設計結構，可以作到邏輯，樣式100%與發佈後的專題保持一致，而且不須要額外的代碼，並且最重要的一點在於，她不借助與任何後端服務。
而後編輯區域則是中規中矩的組件樹，頁面級別設置，和組件設置。

說完了主界面，讓咱們看下總體的架構，其實這套系統和編譯器結構稍稍有點相似，簡單的能夠劃分紅預覽編輯層，頁面生成層和組件層三個部分。每一個專題在編輯時會生成一個json文件用以描述該專題的配置信息，而後生成層讀入這個json文件，經過webpack打包成一個完整的靜態頁面，是的，魔方系統從穩定性方面考慮，並無藉助任何ssr或後端模板技術，純粹是經過webpack進行打包構建的。組件層則是經過npm安裝在服務器上，供動態加載器和專題生成器調用，這兩塊咱們一會再詳細說。而最下層的核心技術棧則提供了總體的編譯腳本和統一版本的第三方依賴。

好，讓咱們看下仿真器這塊，說仿真以前，其實咱們須要先解釋一下頁面生成了什麼、第一段代碼其實就是生成器的核心渲染邏輯簡化版，返回一個組件列表而且注入相應的數據。在生成層的邏輯中，咱們以在生成模板執行構建命令，利用環境變量將專題json讀入，經過分析生成下面左側的代碼，經過宏替換注入模板，最後經過webpack構建打包成最終產物。

而仿真器則是在一個iframe中內置了一個空的模板, 經過父層向iframe注入js(動態加載庫)，並修改全局widgetsMap，右下所示。最後經過setState從新渲染頁面。整個過程是無需後端參與的。

關於動態加載庫，能夠類比code split技術想象成須要哪一個組件就請求哪段代碼，這裏篇幅有限，暫時不展開談論，感興趣的能夠關注大轉轉FE進行互動討論。

對於分享及其餘native拓展能力來講，各個app提供的API並不相同，甚至在某些容器中沒有相應的功能，爲了讓模擬器正常工做，咱們須要一種抹平多端差別的公共庫，使得各端不會拋出錯誤。

說完了模擬器，咱們想聊一下組件系統，前文說過，可視化平臺的核心也是一個組件化交付平臺。若是開發一個組件的門檻太高就會致使開發者拋棄這套系統。因此咱們設計的一個組件將是下面的樣子。

咱們的組件分紅兩個部分，即組件實體和配置項，在最初的組件開發過程當中，不須要任何配置項，魔方組件就是一個普通的react組件，上手的成本很是低。而隨着版本迭代，愈來愈多的配置項進去，咱們提供了一套簡潔的api用於快速增長配置項。關於配置項這裏，咱們也嘗試過採用json來描述，最後從靈活性上面來看略微不知足需求。並且可拓展性不足。

魔方提供了一套內置的api用以輕鬆的完成某些動做，我總結了一下大概如上6類。

爲了讓開發人員方便的進行定製組件的調試，咱們又設計了一套組件開發的sdk工具集，大概包括下面四個方面，第一：第三方庫集合，包含所有魔方組件依賴的第三方庫，在初始化一次後，任何組件編譯過程當中不會從新安裝。第二，面向開發者透明的構建腳本生成器，用以進行組件的本地化測試構建。第三，一個簡易的編輯模擬器，用於開發時測試Config到Preview的數據流動。最後，還有一個用於快速建立項目的組件腳手架。

在組件管理這塊，咱們採用monorepo+安裝時構建的策略來處理組件包的。組件管理的最讓人頭疼的地方在於組件所依賴的其餘第三方npm包的管理，利用monorepo來組織代碼可使結構更加清晰，權限明確，所有組件共享構建腳本使得底層優化更加可控，安裝時構建更能夠確保第三方組件不會重複或多版本引用。

關於第三方的依賴的打包，咱們採用一種多層的優化策略，按重要程度劃分紅4個類型，金字塔最上面的是必要且穩定的一類，好比react，antd，這種是經過dllplugin打包成一個js，全部的專題均引用這一個js。其次是部分組件依賴的，組件構建時extrenal掉，當專題生成時打包進專題內，好比無限滾動插件。還有一種會頻繁更新，採用外鏈直接引用的方式，而其餘未知組件，是禁止添加到項目源碼中的。

說了這麼多實現細節，再說點咱們的夢想，從最開始的架構圖其實能夠看出，魔方的本質是可視化生成json，而後讀取json生成靜態頁面，實際經過描述甚至能夠組裝成native頁面，微信小城序，產出存在着各類的可能。咱們也會陸續嘗試向這個方向探索，而後回顧一下咱們的仿真器，我認爲能夠在生成頁面時進行預渲染提高速度，最後就是隨着公司規模擴大如今看起來單機構建效率不足，因此咱們會考慮利用分佈式構建來提高效率。

好了，總結一下本次live的觀點：

1. 運營活動有不少特徵，好比咱們的電商公司：圖片，商品流和紅包是運營的核心要素。
2. 運營活動變幻無窮，以不變應萬變很難，因此讓可視化系統保持生命力的關鍵是持續迭代和支持插件。
3. 魔方的工做方式是經過可視化編輯器生成json，經過json注入模板生成靜態頁面。
4. 開放插件及定製能力須要完善的配套系統。
5. 插件系統棘手的難點在於第三方依賴的管理。