活動運營自動化平臺實踐

時間  2019-11-17
標籤 活動 運營 自動化 平臺 實踐 欄目 快樂工作 简体版
原文   原文鏈接

人人貸活動運營平臺，是一個由人人貸大前端團隊進行開發和維護，並用於自動化、可視化構建人人貸常規活動的系統。本文將會分享"人人貸活動運營平臺"的設計思想和部分技術實現，但願對你們有所幫助。javascript

1、背景

人人貸前端團隊在過去的幾年裏，接到了不少來自市場部門的活動開發需求，這些活動主要分爲4大類：css

  • LP活動（Landing Page，引導頁），用於新人註冊的活動頁面，基本都是一個註冊框 + 若干產品卡
  • MGM活動（Members get member），用於好友間邀請拉新的活動頁面，通常包括邀請記錄，邀請排行，分享等功能
  • 常規活動，通常包括抽獎、產品卡、排行榜、分享等功能，用於促進銷量
  • 特殊活動，通常是遊戲頁面，相同的形式基本只會使用一次

1.1 活動開發人力瓶頸和上線週期長

一個普通的活動（包括上述的LP活動、MGM活動、常規活動）開發時間得多久？html

正常狀況下，一個涉及到H5和PC兩端的簡單活動，從產品提出需求開始，設計師須要2人*2天來完成設計工做，開發須要3人*2天（包括H五、PC端頁面、後端接口開發、接口聯調），測試須要2人*2天投入。前端

就這樣，從需求提出到頁面上線，須要一共投入14人*天的人力資源，得 7個工做日 才能完成。java

而遇到比較緊急的活動開發需求，上線週期須要壓縮，你們都得加班來完成。node

另外，因爲公司財務結算的特殊性，不少活動的開始時間通常都是凌晨，開發、測試人員須要確認活動在線上運行正常，才能下班。git

1.2 活動功能重複和反覆修改

隨着公司業務的發展，活動的開發需求愈來愈多。前端團隊有三分之一的人力，長期投入在活動頁面的開發中。github

事實上，我們大部分的普通活動，功能並不複雜，並且大部分的功能比較重複。web

這種功能重複性的頁面開發，對於我的和團隊的成長來講，並無太多的價值。並且活動上線後，常常由於樣式和文案的關係，須要修改代碼，從新上線，致使團隊成員廣泛比較反感這種普通活動的開發。npm

期間，團隊也提出過組件化開發的方式，試圖將不一樣的功能模塊抽取出來，在不一樣的活動頁面上進行引用，以便節省開發時間。但因爲設計方案的不肯定性，以及不一樣開發人員參與，這種抽取的功能模塊複用性不過高，效果不是特別理想。而且不能解決樣式和文案修改，須要從新上線的問題。

總之，普通活動的特色是：頁面功能大同小異、開發時間緊、下線快、技術成長低。

隨着團隊的技術體系日益成熟，咱們終於騰出精力，試圖解決普通活動開發中各項痛點。

2、人人貸活動運營平臺

早在十幾年前，使用Dreamweaver就能可視化地搭建出前端靜態頁面。雖然Dreamweaver已經成爲過去式，可是可視化搭建的思想，卻被普遍使用。

咱們在調研業界經常使用解決方案中發現，不少公司都有本身的活動運營系統，可用來高效、可視化地配置活動，以及監控活動運營數據。咱們但願採用這種活動頁面可視化搭建的思想，由運營人員根據實際的運營需求，自行添加活動，並配置對應的活動頁面。

運營平臺

2.1 總體框架

首先，簡單介紹下人人貸前端的開發模式。

隨着 Node.js 的興起，咱們從2016年開始，將原有基於 JSP 的前端開發模式，改形成使用 Node.js 作中間層，進行先後端分離的模式。

先後端分離

人人貸前端使用的就是圖中所示的先後端分離的開發模式（圖片來自Web 研發模式演變），這種開發模式下，先後端的職責清晰。對於前端來講，兩個UI層各司其職：Front-end UI layer 處理瀏覽器層的展示邏輯，Back-end UI layer 能夠用來處理路由、模板、數據獲取、cookie、服務器端渲染等。

在這種先後端開發模式下，整我的人貸活動運營平臺的架構圖以下：

總體架構圖

整個運營平臺系統分爲四大塊。

一、組件庫。運營平臺採用了業界通用的 組件化 方案，而且選用 React.js 做爲組件的開發庫。下面會詳細介紹組件庫的拆分和開發模式。

二、前端系統。整個運營平臺包括 積木系統 、 rrd-h5 、rrd-pc 三個前端系統。其中 積木系統 是運營建立、編輯、發佈活動頁面的系統，屬於內部系統。而rrd-h5 和 rrd-pc 屬於面向用戶的Back-end UI layer，它們是基於生成的活動配置數據，對活動頁面進行渲染及提供異步接口，以供用戶訪問。

三、後端接口。在後臺服務上，因爲活動並非特別複雜，咱們有較大一部分接口，好比抽獎、記錄收穫地址，只是作一些簡單的存儲或者計算，就直接使用了Node.js實現，也就是上圖中的node-market-service服務。而部分與公司主營業務相關的接口，好比投資返現這類，仍是直接使用後端提供的Java接口。

四、數據層。用於存儲活動配置相關的數據以及部分運營數據。

2.2 組件庫

咱們按照功能模塊，將往期的活動頁面拆分紅了不一樣的組件。

以 移動端的邀請好友頁面 爲例，這個頁面就包括：圖片組件（banner圖）、活動規則組件、邀請記錄組件、戰隊排行榜組件、平臺增信組件和邀請好友按鈕組件等。

組件拆分完成後，咱們就獲得了一個組件庫。

爲了便於對組件庫進行管理，咱們按照所屬的平臺，將組件庫拆分爲 jm-common 、jm-mobile 、jm-pc 三類，分別對應兩端公用組件、H5組件、PC端組件。

如上文所述，咱們的積木系統定位爲 可視化編輯平臺，在對組件進行配置後，須要在編輯頁面實時展現。rrd-h5和 rrd-pc服務也須要根據頁面的配置數據，對組件進行渲染。

這三個系統中都須要使用組件庫，爲了方便組件的開發以及預覽，咱們將組件庫的源碼集成到了積木系統的代碼倉庫中。

積木系統經過項目代碼中的組件庫源碼來加載組件庫，當組件的代碼有修改，積木系統能經過從新編譯，刷新頁面並預覽到新的組件樣式。

組件庫還會經過開發環境判斷，會自動在編輯系統中使用模擬數據，方便了組件開發時的測試。

爲了方便進行版本管理和組件庫接入，當組件開發完成後，咱們會將組件庫發佈在私有的npm倉庫中，同時在rrd-h5和rrd-pc中，更新對應的組件庫版本號，就能加載到新的組件。

2.3 活動配置與頁面配置

在積木系統中，須要先建立活動，而後才能建立該活動對應的移動端、PC端頁面，而不是直接建立活動頁面。

這是由於根據以往的運營經驗，一個活動，是能夠對應多個推廣頁面（至少是H5和PC端兩個頁面），而這些推廣頁面須要共享一些活動配置。

數據存儲上看，咱們新建了 activity 、 page 、 page_record 三張表用於存儲活動配置、頁面配置和組件配置相關的數據。

  • activity 是活動配置表，負責記錄活動名，活動的上下線時間，業務相關的活動配置以及公用活動配置等。其中公用組件配置，是指該活動下的頁面，須要公用的組件配置項。好比領取優惠券組件，會將優惠券的金額、類型、批次等，放到公用組件配置中，這樣能有效避免在多個頁面的組件中分開進行配置時，配置出錯或者不統一的狀況。

  • page 是頁面表。新建頁面時，就會往該表中插入數據。信息會記錄頁面名，頁面所屬的活動id，頁面所屬的平臺（移動端 or PC端），發佈時間等。須要注意的是，該表不會記錄具體的組件配置數據。這是爲了將頁面數據與組件配置數據分離。可是頁面表會記錄線上頁面使用的 online_record_id ，用來關聯查詢線上頁面使用的組件數據。每次發佈頁面後，咱們會將最新的 online_record_id 更新到對應頁面數據中。

  • page_record 是組件配置記錄表，主要負責記錄所屬的頁面id，具體的組件數據，編輯人，發佈時間等。在積木系統的活動頁面編輯中，每一次保存頁面，都會在這個表中插入一條數據，這樣方便查找編輯記錄，同時也方便回滾。

2.4 組件的配置與配置數據解析

按照咱們規劃的操做流程，運營同窗在 積木系統 中新增活動，建立頁面後，須要給頁面添加組件，修改組件配置，配置完成後，保存頁面中的組件配置，最後發佈頁面。

不一樣的組件，須要用到不一樣的配置項。那麼咱們該怎麼在積木系統中，給不一樣的組件提供不一樣的配置項呢？

首先得介紹一下組件的開發模式。

在開發組件前，咱們會提早和產品同事確認該組件所須要的配置，包括組件樣式配置、組件文案配置以及組件業務屬性配置等。

開發組件時，咱們通常會添加三個文件。以圖片組件爲例，咱們添加image.jsx、image.scss、spec.js，分別是組件的具體實現代碼、組件樣式文件、組件的配置文件數據。

在配置某個組件時，積木系統經過讀取該組件下的spec.js文件，提供不一樣的配置彈窗。

如下是圖片組件的spec.js文件內容：

import Image from './image.js';

export default {
    Component: Image,
    type: Image.type,
    _name: '圖片',	//組件列表使用的名稱
    _platform: 'common', //該組件屬於公共組件
    _acceptChild: false, //是否容許嵌套其餘組件
    _dataSchema: {  //組件配置項須要的JSON Schema
        type: "object",
        required: ["src"],
        properties: {
            src: {
                type: "string",
                title: "請填寫圖片地址",
            },
            alt: {
                type: "string",
                title: "圖片沒法加載時的文案",
            },
            title: {
                type: "string",
                title: "鼠標移到圖片上的提示文案",
            }
        }
    },
    data: {  //默認數據
        src: 'https://www.we.com/cms/5864b0d6a24d131067ef7956/jimu/default-img.jpg',
        alt: '',
        title: ''
    },
    style: {  //樣式配置項
        width: '',
        height: '',
        position: 'static',
        display: 'block',
        margin: '',
        padding: ''
    },
    _defaultStyle: {  //默認樣式
        mobile: {
            width: '100%'
        },
        pc: {
            maxWidth: '1080px',
            height: 'auto'
        }
    }
}
複製代碼

以上的配置文件中，有部分屬性是如下劃線_開頭，這部分屬性屬於積木系統專用的屬性，會在給前端頁面傳遞組件配置數據時，過濾掉這些專屬屬性，避免配置數據過多，也避免部份內部數據泄露。

一個活動頁面，通常會添加多個組件，並且組件間還可能存在嵌套關係，頁面上的組件配置數據如何組織、解析，也是必需要解決的問題。

咱們這樣定義頁面上的組件數據：

{
    "dataMap":{
        "id1":{
            "cid":"id1", // 組件id
            "type":"pc_component_1", //組件類型
            "name":"組件一", //組件名
            "platform":"pc", //組件所屬的平臺
            "acceptChild":true, //是否能添加子組件
            "data":{},//組件數據
            "style":{},//組件樣式
            "childs":['id3'] //子組件id
        },
        "id2":{
            "cid":"id2", // 組件id
            "type":"pc_component_2", //組件類型
            "name":"組件二", //組件名
            "platform":"pc", //組件所屬的平臺
            "acceptChild":false, //是否能添加子組件
            "data":{},//組件數據
            "style":{},//組件樣式
            "childs":[] //子組件id
        },
        "id3":{
            "cid":"id3", // 組件id
            "type":"pc_component_3", //組件類型
            "name":"組件三", //組件名
            "platform":"pc", //組件所屬的平臺
            "acceptChild":false, //是否能添加子組件
            "data":{},//組件數據
            "style":{},//組件樣式
            "childs":[] //子組件id
        },
        ...
    },
    "childs": ["id1","id2"] //第一層級的組件id
}
複製代碼

頁面的組件配置數據中有dataMap和childs兩個字段。

在須要經過這些配置的組件數據來渲染頁面時，首先使用配置項中的 main 字段獲取全部第一層級子組件的id，而後在dataMap中，根據組件id來查找對應的具體配置，進行渲染。

若是某個組件配置數據中的 childs 字段不爲空數組，就意味該組件中嵌套了其餘組件，就繼續經過 childs 中的id值，在dataMap中查找對應組件的配置數據，並渲染子組件。

還有，咱們以前提到過的公共組件配置數據，在渲染組件前，也會和dataMap中的對應組件配置進行數據合併。

2.5 rrd-h5 & rrd-pc 中如何渲染？

那麼積木系統中生成的頁面組件配置數據，是如何在 rrd-h5 和 rrd-pc 中，進行渲染的呢？

其實，目前主流的組件渲染方式有三種：

  • 加載全部的組件定義，而後經過活動id和頁面id獲取頁面的配置數據，進而動態渲染出頁面
  • 先經過活動id和頁面id獲取頁面的配置數據，而後按需加載組件，渲染出頁面
  • 服務器經過頁面配置和組件定義，直接在發佈時生成靜態頁面

不一樣的方案各有優劣。rrd-h5 和 rrd-pc 系統中，咱們使用了第一種方案來進行渲染：咱們的線上頁面模板，會默認加載全部的組件。

以rrd-h5爲例，咱們會在活動頁面模板中引用全部的 jm-common(公共組件) 和jm-mobile組件庫代碼。而後使用活動頁面URL中攜帶的活動id和頁面id，經過 node-market-service 服務獲取活動數據和頁面組件配置數據。以後就按上述 2.4 組件的配置與配置數據解析 中介紹的組件配置數據解析方式，渲染出整個活動頁面。

就這樣，用戶就能看到配置的活動頁面。

3、TODO

目前的運營平臺，其實主要以編輯系統爲主，並提供了少許的查詢功能。

咱們將來會繼續迭代，將繼續集成運營監控、報警，自動生成活動數據報表等功能。

同時，爲了提升頁面加載速度，考慮到活動頁面上圖片較多、且切圖廣泛較大的問題，咱們即將在rrd-h5、rrd-pc中引入 webp 、http2、service-worker等。

4、總結

人人貸活動運營平臺在2018年9月上線後，效果極其明顯：

  • 活動運營平臺，可以自動化、可視化地建立活動及活動頁面。
  • 活動運營平臺，讓活動的上線週期，從以往的6天，下降到了2天。設計師切完圖，運營人員就能配置上線。
  • 活動可配置上線和下線時間，開發人員基本不會由於活動的開發而加班。
  • 運營平臺規範了活動功能的形式，同時，設計師也會在組件的可編輯範圍內進行設計，組件可配置項豐富。
  • 活動頁面的樣式和文案的修改，再也不須要從新上線。
  • 釋放出的前、後端開發人員，能將更多的精力投入到對新技術的研究。

因爲篇幅有限，活動運營平臺的不少具體實現細節並無過多描述。若是你們有感興趣的問題，能夠留言進行交流。

最後，歡迎你們star咱們的人人貸大前端團隊博客，全部的文章還會同步更新到知乎專欄 和 掘金帳號，咱們每週都會分享幾篇高質量的大前端技術文章。

參考文章

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程