隨着用戶體量不斷擴大，vivo互聯網營銷業務面臨眾多的效率問題：如何在活動營銷中減少成本、降低難度、提升效率？如何優化終端用戶的體驗？如何將企業的營銷活動開發和運營能力通過中台標準化和敏捷化，實現對前端需求的快速響應和後端能力的整合復用，從而提升企業營銷能力和營銷效果。277期高手問答（ 2 月 16 日 - 2 月 22 日）嘉賓我們邀請到來自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的公眾號悟空系統文章進行了解，服務端目前無法完全支撐敏捷定製，過於個性化的訴求，需要業務方單獨提供。問：阿里都在去中台了，現在還能上中台嗎？上了中台後，最大的坑是什麼？中台好像只提供業務的標準版和核心功能，對接的業務方還要做不少的定製化需求，這樣的話，是不是個性化需求太多的不建議接中台，沒什麼個性化需求的才可以考慮接入中台？答：你好~不同的中台切入點不同，就活動業務而言，我們不僅需要是服務端的微服務能力，更多是最大化復用能力去滿足活動運營對前台靈活搭建活動的訴求。就活動接入中台，他將具備插拔式的插件開發模式、低代碼組件及配置生成能力，組件市場，全鏈路的活動支撐能力，如：監控、風控、實驗、反垃圾等能力。就算該活動組件過於定製化，除去服務端能力需要單獨提供，但其他的配套的能力也是很吸引開發者的。Java 8「失寵」瀏覽器廠商聯盟！合力解決Web兼容性問題PHP社區拒絕在俄烏衝突中「站隊」
覺得不錯，請點個在看呀
留言列表
留言列表