伴魚運營活動前端配置化實踐

前言

波塞冬，是伴魚活動運營解決方案的總稱，包含活動規(guī)則體系、h5 可視化開發(fā)平臺等，名稱來源于古希臘神話，波塞冬是海洋和所有水系的管理者，寓意為 palfish 發(fā)展提供超能力。

目前的問題

隨著伴魚業(yè)務(wù)的高速發(fā)展，大量促增長的活動接踵而來， 原有的研發(fā)模式暴漏出一系列問題，如后端邏輯混雜、復(fù)用度低、維護成本高，前端靈活性差、效率低，為了提升公司運營效率，我們急需探索一套符合公司現(xiàn)狀的技術(shù)體系，為公司的業(yè)務(wù)高速發(fā)展提供平臺支撐。

萬物終有源，要解決掉面臨的問題，我們從整個研發(fā)、運營鏈路出發(fā)尋找答案。研發(fā)鏈路上在前后端分離的技術(shù)大背景下，我們的目標是要最大化的實現(xiàn)后端服務(wù)復(fù)用、前端頁面復(fù)用，對運營而言是能夠快速靈活的對活動策略、展示作出修改，來查驗各種活動對業(yè)務(wù)的作用效果，基于以上思考，我們抽象了波塞冬平臺的業(yè)務(wù)模型。

平臺概覽

波塞冬平臺主要分為三大部分：

• 基礎(chǔ)服務(wù)規(guī)則：
  如消息通知、用戶畫像等服務(wù)。
• 各種業(yè)務(wù)類型規(guī)則：
  例如拼團、簽到、任務(wù)等類型的規(guī)則服務(wù)，在業(yè)務(wù)層面集成基礎(chǔ)規(guī)則服務(wù)。
• h5 可視化管理平臺：
  集成業(yè)務(wù)規(guī)則層邏輯，完成輸出給 c 端用戶。

為什么要這樣分呢？我們結(jié)合現(xiàn)在運營場景進行簡述。運營的呈現(xiàn)宣傳方式以分為線下，線上兩種方式，這里我們只談線上。每一場運營活動都需要一些通用的服務(wù)，比如活動需要發(fā)送消息（微信、短信、站內(nèi)信等），來增加活動的曝光，對于不同特征的用戶我們希望展示不同的分流策略，這里有些用戶特征是不區(qū)別業(yè)務(wù)線的，比如用戶基礎(chǔ)信息（性別、年齡等）；有些跟業(yè)務(wù)線強耦合，比如繪本的會員，少兒一對一的購買等，這些我們在應(yīng)用層都統(tǒng)一成畫像規(guī)則，最后由各業(yè)務(wù)畫像規(guī)則引擎解析提供給下游消費，此類的基礎(chǔ)能力我們統(tǒng)稱為基礎(chǔ)服務(wù)規(guī)則。

在基礎(chǔ)服務(wù)之外還會有各種類型的活動，比如業(yè)務(wù)常用的任務(wù)玩法（錄制繪本、去分享），簽到玩法、拼團玩法等此類的玩法在服務(wù)層是可高度固化的，形式標準的 FaaS 服務(wù)（函數(shù)即服務(wù)），同樣為了對運營友好使用，我們做成標準的業(yè)務(wù)規(guī)則模版，在業(yè)務(wù)規(guī)則層面通常會結(jié)合基礎(chǔ)服務(wù)，比如一個拼團活動需要對新老客發(fā)送不同的獎勵，對任務(wù)中的用戶來發(fā)送通知提醒，督促用戶來成活動。這樣每一次的規(guī)則相互解耦，又可以靈活組合，從而達到服務(wù)高度復(fù)用，效率提升的目標。以上兩層主要解決了服務(wù)端的復(fù)用。

對于 c 端我們應(yīng)該如何復(fù)用？答案當然是組件化能力建設(shè)、可視化能力建設(shè)的范疇了，鑒于當前主推的運營場景是 h5 活動，下面我們會重點介紹一下 h5 可視化平臺的建設(shè)。以上就是對三大模塊拆分的場景

h5 可視化開發(fā)的部分

可視化開發(fā)一直是前端開發(fā)的熱點話題，幾乎所有大的公司都有自己的可視化配置平臺，我們在建設(shè)可視化平臺之前也做了充分的調(diào)研，下面以平臺對比和總結(jié)的方式介紹。

業(yè)界對比

h5可視化平臺的建設(shè)我們也調(diào)研了很多業(yè)界很多相關(guān)的資料，下面做了簡單的匯總。

總結(jié)要點

通過對業(yè)界的總結(jié)，我們需要尋找出符合公司技術(shù)現(xiàn)狀的方案。這里先描述一下 h5 活動開發(fā)的現(xiàn)狀，現(xiàn)在每個業(yè)務(wù)線的 h5 活動都放在各自代碼倉庫，由于活動的性質(zhì)（周期短，頻次高）造成了代碼倉庫的不斷膨脹，且很多活動都是經(jīng)過多次迭代，代碼經(jīng)手多人，代碼邏輯不清晰，長時間會造成很多冗余代碼，導(dǎo)致的結(jié)果就是維護成本上升，研發(fā)效率降低。

此外活動的變更也是比較頻繁的，其中很多就是文字描述、背景圖片等，這些改動不管是提測中，還是上線后都在發(fā)生，每次小的改動都需要走代碼提交，發(fā)布的流程，且每次小的變更都需要全量發(fā)布，(比如多個活動同步進行，一些將要發(fā)布的代碼已經(jīng)合并到 master，而小的變更急需發(fā)布）產(chǎn)生一定項目風(fēng)險。

基于上述的描述總結(jié)一下問題：

• 代碼倉庫龐大，長期代碼冗余加劇，維護成本高，導(dǎo)致代碼質(zhì)量、研發(fā)效率降低。
• 對運營的支撐不靈活，小的發(fā)版對整體項目造成安全隱患。

因此基于質(zhì)量、效率、安全的緯度，我將 h5 可視化平臺劃分為三個模塊

• 組件開發(fā)腳手架：
  我們提供了腳手架讓開發(fā)高效、規(guī)范化的進行組的開發(fā)與發(fā)布
• 可視化編輯器：
  提供將組件拼裝成頁面的能力。
• 管理后臺：
  人員、組件、頁面等緯度的權(quán)限與版本管理能力。

組件開發(fā)

該模塊我們要從代碼源頭把握研發(fā)的質(zhì)量與效率，因此腳手架提供了統(tǒng)一的組件開發(fā)模版，且每個組件在發(fā)布時候都需要關(guān)聯(lián)到 git 源代碼管理的倉庫，這樣就將原有龐大的代碼倉庫，以研發(fā)組件緯度進行了倉庫解耦，到這里你可能會有疑問，解耦之后我的通用模塊如何調(diào)用？比如橋功能，接口調(diào)用，這里我們結(jié)合 webpack 的生態(tài)能力，在研發(fā)模式下，我們將通用能力的以 externals 的形式在組件中調(diào)用，同時在打包發(fā)布階段只發(fā)布組件本身的內(nèi)容，從而減少了組件代碼體積。當然影響研發(fā)效率的問題還有很多，比如 h5 開發(fā)通常用到橋的能力，本地預(yù)覽的能力，屬性編輯的能力等這里我們都研發(fā)對應(yīng)的模擬橋工具，動態(tài)表單，iframe 等模式來解決上面的問題。

除了去研發(fā)模式的思考，基于業(yè)務(wù)我們也將組件進行了劃分，方便對業(yè)務(wù)進行有力的支撐，以下是我們的組件模塊劃分。

• 業(yè)務(wù)組件：
  顧名思義就是我們之前整理好各種常用業(yè)務(wù)規(guī)則所開發(fā)的組件，為特定業(yè)務(wù)所服務(wù)，比如我在業(yè)務(wù)規(guī)則服務(wù)劃分的時候有拼團、簽到等服務(wù)模塊，對應(yīng)的展示層我們一些通用的組件方便類似業(yè)務(wù)的直接使用。
• 基礎(chǔ)組件：
  基礎(chǔ)組件是我們常用的基本 ui 組件，比如按鈕，文本、圖片等，達到基礎(chǔ)的視圖要求。
• 功能組件（待討論）
  這個是我們比較特殊的一個組件類型，業(yè)務(wù)組件與基礎(chǔ)組件都有一些通用的行為，比如我點擊按鈕彈出橋分享的能力以及對組件統(tǒng)計曝光的能力，此類的組件沒有 ui 的作用，僅提為組件注入通用的交互行為。

下面以圖文的形式大家作下展示

這是我們組件開發(fā)的界面，為了可以更好的給開發(fā)者提供開發(fā)環(huán)境，我們集成了編輯器的所有功能，從而保證展示效果是一致的。

功能

組件作為整個波塞冬重要的部分，在設(shè)計的時候我們考慮集成了以下大功能：

配置數(shù)據(jù)

對頁面的可編輯部分，需要準確描述可編輯部分所需的配置數(shù)據(jù); 配置數(shù)據(jù)是異構(gòu)的，不同頁面、不同區(qū)塊的配置數(shù)據(jù)各不相同。所以需要對不同頁面、不同區(qū)塊定義各自配置數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)和字段類型。
最理想的配置數(shù)據(jù)格式為 JSON，因為其格式靈活，前端友好; 最理想的配置數(shù)據(jù)描述是 JSON Schema，因為其支持表單動態(tài)生成和數(shù)據(jù)校驗。

組件交互

上面我們有講到，將所有的組件代碼解耦分布在不同的倉庫，看下圖描述的場景。

我們最終要解決的是不同組件的通信問題，跨組件通信大家都不陌生，比如EventBus等，結(jié)合到業(yè)務(wù)我們需要解決將組件的內(nèi)部的方法暴露給其他組件，并且在指定的綁定事件（點擊、焦點等）中觸發(fā)方法。在實踐中劃分兩部分解決這個問題：

1）組件開發(fā)階段，在組件描述的中定義方法名字，比如我們約定描述屬性名稱為editorMethods，需要對外暴露的方法為goShare，這樣組件就對外提供了方法。

2）組件編輯階段，編輯器內(nèi)部維護了一個存放當前組件中所有對外方法的數(shù)組，以及可以交互的事件，當選中具體組件的時候，可以指定綁定組件的事件方法。下圖為在編輯器中的使用展示。

數(shù)據(jù)總線

數(shù)據(jù)總線主要解決了組件之間數(shù)據(jù)共享問題。同樣結(jié)合下面圖的場景理解，后端接口的數(shù)據(jù)多個組件都會使用到，每個組件中都調(diào)用一次接口會造成性能問題。vuex可以很好的解決這個問題，在編輯器內(nèi)部定義約定Store的對象，不同的接口數(shù)據(jù)設(shè)置不同的Store對象屬性，既可實現(xiàn)數(shù)據(jù)共享的能力。

頁面模板

模板是帶有默認數(shù)據(jù)的頁面; 對于組件化的頁面，模板是從組件庫中選取部分組件，并帶有各個組件的默認數(shù)據(jù)。采用模板生成頁面，只需對模板進行少量編輯即可實現(xiàn)頁面快速生成，比如項目中沉淀了許多海報模版，素材庫模版，直播模版等

頁面編輯器

原有的方式中都是一個代碼倉庫中代碼形式的組件復(fù)用，編輯器讓組件的復(fù)用也可視化的方式，簡單的頁面組裝讓非研發(fā)同學(xué)也可以做頁面。

這是我們波塞冬編輯器的編輯頁面，總共五個部分。頂部主要是我們的頁面設(shè)置部分，提供了頁面的保存發(fā)布預(yù)覽等功能。下部分從左往右依次是：

• 組件列表：
  這里展示我們通過組件工具發(fā)布的所有組件。
• 頁面組件樹：
  頁面組件樹是頁面的骨架，由內(nèi)置的各個組件組成。
• 展示編輯區(qū)域：
  這里主要是進行組件的位置操作，拖拽組件的位置，進行頁面編輯。
• 屬性模塊：
  因為每個組件都有可配置的屬性，這里主要是根據(jù)選中的組件進行配置，比如按鈕組件的顏色大小等，取決于這個組件有什么屬性。

管理后臺

管理后臺是整個可視化的控制樞紐，重點在于對業(yè)務(wù)場景應(yīng)用的管控。做為一個平臺組件可以隨心所欲的發(fā)布，但不可發(fā)布的組件并不能都生效，因此平臺要對發(fā)布組件做質(zhì)量檢查，通過審核后才能在可視化編輯區(qū)使用；同樣頁面可以隨意的創(chuàng)建，但是不能讓別人輕易動我創(chuàng)建的頁面，比如 a 業(yè)務(wù)的同學(xué)，編輯并發(fā)布了 b 業(yè)務(wù)的頁面，因此在頁面上層我們劃分了項目團隊的概念，只有項目中的成員可以修改歸屬于項目的頁面?，F(xiàn)在我們發(fā)布頁面方便了，原有代碼部署的方式發(fā)現(xiàn)錯誤我們可以快速回滾，這里我們同樣提供了頁面回滾的能力，每次的編輯器內(nèi)發(fā)布的內(nèi)容都會有一條 content 內(nèi)容發(fā)布記錄，方便回滾歷史提交，以上就是對后臺的介紹。

展望

目前波塞冬平臺體系還處于建設(shè)的初級階段，可視化部分承載了目前業(yè)務(wù)內(nèi)的所有海報生成工作以及部分活動頁面，在互聯(lián)網(wǎng)已經(jīng)進入下半場輿論下，用戶運營已經(jīng)成為各大公司的重中之重，能夠?qū)τ脩糇龅骄毣倪\營，對公司成本、效率越來越重要，做為技術(shù)人員我們以技術(shù)驅(qū)動產(chǎn)生平臺，用平臺支撐業(yè)務(wù)發(fā)展，從而使公司變得更大更強，未來我們期待波塞冬體系能夠成為建設(shè)完成，成為真正的海神。

參考文獻

• 頁面可視化搭建工具前生今世
• 美團樂高
• godspen

最后

• 歡迎加我微信(winty230)，拉你進技術(shù)群，長期交流學(xué)習(xí)...
  

• 歡迎關(guān)注「前端Q」,認真學(xué)前端，做個專業(yè)的技術(shù)人...

點個在看支持我吧