隨着用戶體量不斷擴大，vivo互聯網營銷業務面臨衆多的效率問題：如何在活動營銷中減少成本、降低難度、提升效率？如何優化終端用戶的體驗？
如何將企業的營銷活動開發和運營能力通過中臺標準化和敏捷化，實現對前端需求的快速響應和後端能力的整合複用，從而提升企業營銷能力和營銷效果。
本期高手問答嘉賓我們邀請到來自vivo互聯網系統架構師 @朱明鵬 老師。朱老師將與大家一起探討 活動中臺在vivo互聯網中是如何解決營銷業務的效率問題的。
嘉賓簡介
朱明鵬
近10年的軟件開發與架構經驗，曾負責並參與多個大型系統軟件的基礎架構和業務平臺的設計與研發工作。目前是vivo互聯網系統架構師，領導低代碼效能工具的設計研發和大前端領域的技術探索。
問：在“通過中臺進行標準化和敏捷化的營銷和運營”的背景下，請問“創新性的活動開發模式”和“傳統模式”的差異要怎麼理解，謝謝。
答：傳統的活動開發模式，例如純編碼的形式、或者通過活動後臺或SaaS產品進行搭建開發，拋開純編碼開發，後面兩者都會有活動能力依賴項目本身。例如A活動需要具備砸金蛋組件，如果平臺本身不具備，就需要負責該平臺的團隊或廠商進行定製開發升級上線。 而活動中臺的活動開發模式，是將組件的開發能力交給了該活動的團隊，開發完成後平臺無需在線升級，就可以將組件熱加載至活動編輯器進行使用。
問：老師 ，您好！ 活動中臺是不是在設計之初就要抽象出一套通用的設計概念，然後不斷的增加具體實現,如果先具體實現再抽象概念 ，是不是會造成代碼重構等問題 ？ 還有一個問題是關於低代碼平臺， 會不會造成技術人員懶得用,非技術人員不會用的現象？
答：
1、活動中臺在設計之初就是在摸索可以兼顧個性化和通用化需求的搭建方案。如果這個方案一直不滿意，那將不會有活動中臺，頂多算是活動平臺，另外如果先考慮實現活動需求後再抽象，抽象的餘地會很少，難以達到中臺訴求。
2、首先我們認爲術業有專攻，技術人員無法完全承擔非技術的職能，相反也是這個道理。兩者只能在淺層能力交界處進行適當的“跨界”輸出。還有一種就是低代碼提供80%-100%的案例模版，讓兩者都能適用。
問：如何平衡使用複雜性和功能靈活性的問題？當我需要把一個組件做到很靈活，能適應很多不同種類的活動，那麼要麼把組件的粒度拆分得很細，要麼把組件的配置選項做的很多，這都會造成產運人員使用上的困難。如果把組件做的很傻瓜，那麼就得針對不同的需求產出不同的組件，造成通用型下降。現在不太明白如何平衡這些問題。希望老師賜教。
答：
我們在抽象化組件上同樣也遇到了這樣的場景。產品希望設計的組件足夠強大，可以面對不同活動場景。可往往到了活動運營同事那裏，發現配置太多、太細，常用的就那幾個，插件配置體驗差。如果對組件配置進行精簡設計，那其他業務的同事，大機率會反饋組件功能不滿足訴求。 至於活動中臺的平衡方案不能說是絕對完美，但也解決緩解了現狀問題。
首先我們在設計組件時會搭配【推薦設置】，另外也會使用【漸進式的配置方案】來引導用戶學習使用（例如抽獎只暴露了UI配置，負責的抽獎設置，我們使用“任務中心”的概率來承接）。 另外我們也開發了jsonschema to from的能力，幫助開發者【快速開發】多項配置的活動組件（當然插件UI需要預留能力）。
問：我一直很好奇 微前端的架構和設計模式是一個什麼樣的流程 還有低代碼的一個實現 以及需要實現的場景？
答：活動中臺簡單的微前端架構設計，在vivo的公衆號活動中臺文章中也有介紹。在活動中臺的低代碼承接的使命，主要還是快速幫助開發者生成活動組件和玩法場景。
問：請問在低代碼平臺中各個組件間通信是如何進行的？組件是版本是如何進行管理的？謝謝。
答：組件的通信方案，您可閱讀vivo的公衆號文章。當初步瞭解活動中臺下的組件加載方案，您自然就明白組件的版本是如何控制的。
問：你好，首先關注你們很久了，你們的文章內容很棒。
關於活動中臺我看其他人問的比較多的是前端範圍，我的問題是後端如何做到靈活適配各種活動的？比如一個簽到活動，可以做成打卡滿多少天，或者完成任務才能打卡，而這個任務就是每個活動不同了。那是不是就需要提供新的後端接口呢？或者你們是通過什麼途徑達到動態的呢？模板？規則？
再一個就是對活動中臺的監控，目前的監控維度是隻能支持常見的一個活動期間內，活動銷售額情況和競品對比。還是能針對不同的活動有不同的監控維度呢？
答：
一、活動中臺靈活運營
1、對於通用的運營活動（例如會員權益領取，完成任務才能打卡），我們將活動抽象成Rule + Action這樣的模型，Rule是一系列規則表達式的集合，Action是滿足Rule執行的動作。 2、對於玩法比較複雜的活動（例如抽獎、大富翁等），這類活動玩法新穎、多變，且複用價值較低的後臺服務，我們推薦業務方自行提供或中臺團隊評估後開發。3、我們已經在嘗試在模型中融入用戶資產（例如參與活動需要扣除積分），抽象獎勵，能夠快速的支撐任何形式的獎勵發放。
二、活動中臺的運營指標監控
1、對常見的監控指標做，比如日活、留存、點擊率等，活動中臺制定統一的採集標準和採集方法，活動的開發者和產品不用重複建設。另外對於不同的監控維度，前後臺都暴露了採集的方法和接口，利用統一的監控平臺進行細分管理。
問：活動中臺的功能架構和業務設計，有沒有使用什麼設計模式？
答：您可閱讀vivo的系列文章。初步瞭解活動中臺下的功能架構和業務設計。
問：請問，中臺和普通的一個業務服務有什麼區別？ 假設有一個支付業務服務，和一個支付業務中臺，這兩個在設計的時候，有哪些不同的考慮點？
答：不同類型的中臺，切入點和使命是不同的，但是它們的出發點都是類似的，需要通過【抽象複用】、【敏捷定製】的能力進行支撐前臺業務訴求。在活動中臺的實踐和設計過程中，我們需要同時滿足了通用化和個性化兩個目標，這就和普通的活動平臺設計產生了區別。
問：中臺在設計的時候，有哪些安全性要考慮的。中臺架構和普通的微服務架構區別在哪？
答：該中臺目前僅在vivo內部使用，對於常規系統，安全性要求沒有特殊地方額外考慮。可能大家考慮的是中臺發佈的活動本身的安全性要求。另外中臺是抽象企業業務能力的一種設計實現，該實現是需要使用微服務技術架構來搭建中臺所需要的原子服務。在活動中臺，前端架構設計中，微組件的概念也是同理。
問：請問， “大中臺，小前臺”，在vivo 團隊有啥指導的原則和最佳實踐呢，可以分享下嗎？
主要還是將我們的經驗進行闡述一下。 我們在2018年初，遇到了因爲活動的業務屬性和需求緊急程度不同，各業務團隊都在構建符合自身業務的活動後臺。這個過程中，各系統近70%的能力時重複建設的。那如何滿足基本的【抽象服用】和個性化的【敏捷定製】，我們在這個問題的驅使下設計了活動中臺，目的就是整合活動能力，快速達成前臺需求。這個過程中，其實缺少不了組織的推動力，來幫助中臺真正的紮根、進化。
問：中臺一般都會對接各個部門的多個業務線吧。這些業務線的數據是否要隔離，是否要設計租戶的概念。請問，這一塊如何設計？
答：你好~中臺的作用是爲了解決重複造輪子的問題，將不同業務線中的相似功能歸併，最大化複用資源，降低企業成本。多租戶概念來源於saas化服務，是否需要隔離數據，在中臺建設中視具體場景而定，如會員中臺，聚合企業會員信息，統一對外提供會員服務，就無需分隔數據。 如活動中臺，按照各活動對系統性能的敏感性、資源使用情況考慮，可進行多租戶的處理，一般從系統層-虛擬化技術，應用層-負載路由，數據層-庫、表、字段等方面入手。
問：搞中臺的話，一定會面臨的問題是各個業務線的個性化需求，這麼多個性化需求，如何處理，是都接過來做，還是都不做（只專心中臺核心功能）。你在上文提到的個性化的【敏捷定製】能展開講講嗎？
答：你好~前端的敏捷定製，一方面是支持H5組件的離線開發，在線集成；另一方面提供了全鏈路的開發套件。詳細可以閱讀vivo的公衆號悟空系統文章進行了解，服務端目前無法完全支撐敏捷定製，過於個性化的訴求，需要業務方單獨提供。
問：阿里都在去中臺了，現在還能上中臺嗎？上了中臺後，最大的坑是什麼？中臺好像只提供業務的標準版和核心功能，對接的業務方還要做不少的定製化需求，這樣的話，是不是個性化需求太多的不建議接中臺，沒什麼個性化需求的纔可以考慮接入中臺？
答：你好~不同的中臺切入點不同，就活動業務而言，我們不僅需要是服務端的微服務能力，更多是最大化複用能力去滿足活動運營對前臺靈活搭建活動的訴求。就活動接入中臺，他將具備插拔式的插件開發模式、低代碼組件及配置生成能力，組件市場，全鏈路的活動支撐能力，如：監控、風控、實驗、反垃圾等能力。就算該活動組件過於定製化，除去服務端能力需要單獨提供，但其他的配套的能力也是很吸引開發者的。