vivo智能活動中臺-悟空系統建設之路

作者：來自 vivo 互聯網悟空系統研發團隊

本文根據馮偉、姜野老師在“2023 vivo開發者大會"現場演講內容整理而成。【vivo互聯網技術】公衆號回覆【2023 VDC】獲取互聯網技術分會場議題相關資料。

在AIGC、低代碼等新技術、新基建的技術驅動下，結合vivo互聯網多年沉澱，悟空團隊打造了一個以拖拉拽爲主體、AI能力加持的智能活動中臺。

一、悟空系統的誕生背景

悟空系統的誕生背景是2018年vivo互聯網業務到了運營時代，進入穩定發展期，但各業務缺少有效的運營工具與手段。因此我們設計開發了一套所見即所得的活動可視化編輯系統，只需要通過 拖  - 拉 - 拽， 即可實現活動快速投放。

本次分享將介紹在活動中臺搭建過程中，我們是如何保障千萬級活動中臺的效率和穩定性，運用SaaS+PaaS的基礎架構設計，打造可插拔的適配組件平臺，利用渲染引擎、規則引擎、泛化調用、模型抽象、頁面靜態化等多種技術手段和思維模式，保障活動中臺靈活高效、快速交付。

爲了實現公司內全業務覆蓋，我們通過平臺公共組件+營銷中臺能力提供公共服務。

同時針對業務個性化需求，提供全鏈路開發工具，達到業務低成本開發，全公司複用的效果。

二、悟空系統的前臺設計

悟空系統前臺設計，主要包含 四個部分：

1. 組件開發-可插拔開發套件介紹

2. 界面組裝-活動設計器渲染方案

3. 代碼生成-靜態頁面發佈方案

4. 建站智能化方向探索

2.1 活動頁面生成流程

要實現無需研發，可視化生成活動頁面，流程上主要包含上圖的3個環節。

2.2 可插拔開發套件

組件開發環節讓開發者可以基於平臺的規範和工具，自由的產出業務組件。該環節會提供一套完善的組件開發套件。

界面組裝提供一套活動在線編輯器。設計的重點是統一的渲染引擎，可以實時渲染所有的業務組件並更新配置查看效果。

代碼生成是將運營配置好的組件，打包發佈生成最終的活動頁面，併發布至線上環境。

上圖講述了組件研發流程，爲了實現組件可插拔開發，悟空系統會提供一套標準化解決方案：

通過VScode插件初始化本地項目工程，支持開發者調試自身業務邏輯，達到開發便捷的效果。

通過NPM包託管服務，並實時同步至CDN網絡，提供穩定的代碼託管。

通過開放平臺 + 鑑權中心，保障組件開發協作高效，數據安全。

插件IDE的效果如上圖，它是開發組件的功能入口，目前提供腳手架初始化，組件發佈更新以及開發平臺文檔服務。

2.3 活動設計器渲染方案

組件發佈後，運營可以在列表選擇使用，拖拽至設計區，點擊即可進行活動配置。

在界面組裝環節中，設計上我們通過IFrame實現跨域隔離、靈活嵌套、異步精準加載的效果，研發過程中遇到最大的問題是如何在iframe區域實現數據通信高性能且保障開發體驗不受影響。

我們知道，iframe的傳統通信方案是 基於事件傳遞數據，實現效果如上述左側代碼示例。

父窗口傳遞數據，子窗口接受併合並數據，由於非同一vue實例，需要重新觸發子內部的數據響應式，同時進行數據的全量再賦值，最終達到通信效果。

爲保障父子窗口通信高性能並保留數據響應式，我們設計了unirender加載方案，可以實現: 數據0拷貝，剔除70%通信代碼，內存消耗降低50%。

並且實際的 開發體驗和傳統一致，可以支持vuex方式管理數據，改造後如右邊代碼實例。具體的設計思路如下。

設計上，我們在子窗口定義加載方式，支持傳入來源於父窗口的vue和store實例，加載過程中進行實例初始化並在自身dom中渲染組件。

該方案在架構層面統一了vue和store實例，實現了共享deps依賴和響應式效果，解決了iframe數據通信方式單一 且複雜的短板。

2.4 靜態頁面發佈方案

當界面組裝完成，這時需要實時去生成活動線上運行的代碼，平臺通過基礎框架動態拉取組件資源，並打包生成最終的活動頁面。

動態打包的方案在設計之初遇到兩個性能瓶頸：

1. webpack實時打包非常耗時，需要佔用大量的IO資源。

2. 編譯服務爲單機服務，難以進行更新和擴展。

基於上述的痛點，我們團隊需要對該服務進行應用拆分和微服務調度。

服務拆分的過程如上，我們將單獨的wukong-node拆分爲消費者和服務者，消費者只負責活動信息組裝和請求，服務者包含打包發佈邏輯，並提供集羣能力。

在服務調度上，基於zookeeper註冊信息。當請求發出，根據負載能力動態分配服務地址。同時當服務異常，自動刪除節點信息。最終可以實現發佈服務整體輕量化、高性能，可觀察。

2.5 智能化探索

在智能化探索方向上，有兩個關鍵目標，一個是致力於降低活動搭建門檻，支持將個性化活動頁轉化爲悟空H5，用來保障數據合規，服務量極大的場景。

轉換效果如上圖，支持將三方頁面，自動轉換爲悟空活動頁效果，整個過程需要滿足3大要求：

• 保留頁面的框架和內容 

• 智能識別點擊交互區

• 區域內容自定義

整體的實現流程如下：

首先初始化活動id和基礎信息，同時將傳入的H5地址在無頭瀏覽器啓動，加載結束後獲取到頁面的靜態html內容。

基於該靜態內容，首先進行script標籤預處理，替換 資源路徑，最後插入自定義標籤。

預處理後，進行 特徵提取和內容識別，包含三個步驟：

第一步將頁面中的素材進行批量OCR掃描，識別可點擊區域，完成交互事件綁定。

第二步，識別頁面內容，比如輪播、視頻等，替換爲悟空業務組件。

最終，通過發佈服務，動態打包生成悟空活動頁，最終實現轉換效果。

 

觀看視頻請點擊此處查看原文

智能化的另一目標是實現自然語言快速搭建。

具體實現的效果如上：通過輸入一段描述，快速創建活動頁。

點擊創建後，基於大語言言模型理解語義，匹配打標好的模板，輸出活動頁面。

針對素材，用戶可以通過司內的AI模型二次創作，點擊發布即可進行活動投放。

智能化方向探索上，我們通過vivo大模型加持，以及邏輯層優化和標準化場景匹配，最終完成悟空系統 從建站工具 向 ai生產力產品的形態轉變。

三、悟空系統中臺設計

悟空系統中臺設計，主要包含三個部分：

1. 活動中臺整體架構

2. 靈活高效的中臺設計

3. 複雜活動的高效支撐

3.1 活動中臺整體架構

悟空爲用戶提供簡單易用的建站工具，我們有內容組件、營銷組件和豐富的互動組件，如答題、簽到、抽獎等。工具服務層之上提供統一的用戶觸達和控制能力，如push推送、灰度實驗等。工具服務層之下是統一的配置層，爲用戶提供一致的，簡單高效的配置體驗。活動中臺層爲互動組件提供中臺能力支撐，包括玩法中心、任務中心、獎品中心等。

3.2 靈活高效的中臺設計

我們做活動，最大的挑戰就是活動的形式豐富、多變。那活動中臺是如何破局，做到靈活高效的呢？我們在不斷的摸索中抽象出了BCA模型，以不變應萬變。BCA即Behavior、Condition、Action。

• Behavior是用戶行爲，如答題、分享、集卡。

• Condition是行爲條件，如答對N道題，分享指定活動，集齊卡片。

• Action是用戶行爲滿足條件後觸發的動作，如送抽獎機會。

 

BCA模型最終的形態是一個行爲對應着多個條件和多個觸發動作，多個條件或動作之間的關係可以是And，也可以是Or。模型引擎的核心工作流程是當有行爲發生時，加載Condition & Action group，校驗一組Condition，執行一組Action。右側是模型引擎的僞代碼。

業務方自身一般都有一些關鍵的用戶行爲和用戶激勵。如遊戲中心下載、打開遊戲，發放遊戲道具等；官方商城用戶購買手機、完成評價，發放滿減優惠券等，那業務方如何將這些用戶行爲和用戶激勵高效接入悟空呢？答案就是剛纔提到的BCA模型。

業務通過悟空開放平臺提供的自定義任務將用戶行爲轉化爲悟空的Behavior、Condition；通過自定義獎品將用戶激勵轉化爲Action。接入後即可使用悟空活動提供的豐富的PaaS服務。如支付訂單送抽獎機會，商城優惠券作爲抽獎的獎品進行發放。

當行爲發生時，業務方用RMQ的方式通知到悟空，消息內容包含自定義任務唯一標識、行爲參數。圖中示例的消息表示發生了觀看短視頻的行爲，時長是15s。悟空消費消息時，根據唯一標識查找任務定義，定義包含行爲參數定義、和用於計算任務是否完成的condition表達式，表達式使用aviator腳本編寫。接着去查找運營配置，如任務完成條件爲觀看10s以上。然後使用aviator規則引擎計算表達式的結果，如果爲true，觸發action的執行。

自定義獎品的核心是利用aviator腳本+dubbo泛化調用的技術達到快速擴展Action的目的，以發獎Action爲例：

發獎時獎品類型形如21#vivoplus-shop-coupon，21是標識自定義獎品類型，#後是自定義獎品的唯一標識。然後我們正常構造發獎Action的上下文，包括流水號、獎品信息、用戶信息等必要內容。自定義獎品的發放包括三個關鍵步驟，即使用aviator腳本構造入參、dubbo接口的泛化調用，aviator腳本解析出參，整個過程通過配置完成，無需開發。

3.3 複雜活動的高效支撐

首先是活動數據互通問題。不同活動之間的數據是隔離的，但是有時業務上需要將不同活動之間的數據打通。比如兩個抽獎活動，每個抽獎活動都有自己的數據，如用戶抽獎機會、活動的獎品池、中獎的輪播信息等都是隔離的。如何實現數據互通呢？

我們設計了組合活動的方案，基於抽獎活動A和抽獎活動B創建組合活動C。需要互通的數據如抽獎機會、中獎輪播信息的讀寫關聯到活動C上，需要隔離的數據仍然關聯到原始活動上。

我們再來看一下大型活動的配置問題。大型活動通常涉及的子活動多、依賴關係複雜。左側是大型新春活動的首頁，我們一起分析拆解來直觀的感受下。

 

1. 簽到送福氣，涉及簽到活動和資產活動，簽到依賴資產；

2. 福氣值達到20可以解鎖新年籤。新增解鎖活動，依賴資產活動；

3. 新年籤解鎖後可以抽獎。新增抽獎活動，解鎖活動依賴抽獎活動。

帶來的問題就是運營理解成本高，配置分散且有嚴格順序。

我們通過playmaker玩法編輯器來解決這個問題。首先通過低代碼技術拖拽活動，用單向箭頭連接活動描述依賴關係，最終生成動態活動定義。根據動態活動定義，渲染集中式配置。集中式配置的好處是運營無需感知需要配置哪些活動以及活動之間的依賴關係。點擊保存後，服務端根據動態活動定義，參考spring bean的初始化過程，完成所有子活動的創建和依賴關係的綁定。

四、總結與展望

悟空系統是可視化、組件化、一站式的綜合運營平臺，聚焦讓活動更簡單、更有效。悟空在自然語言建站方面取得了階段性進展。BCA模型，讓活動更靈活高效，Playmaker，讓複雜活動變得簡單。我們後續會嘗試更多AI場景的探索與落地，完善電商能力。我們還將搭建面向社會的開放平臺，讓更多開發者受益。