作者：vivo 網際網路伺服器團隊

本文是《vivo行銷自動化技術解密》的第5篇文章，重點分析介紹在行銷自動化業務中實時行銷場景的背景價值、實時行銷引擎架構以及專案開發過程中如何利用動態佇列做好業務流量隔離，動態釋出，使用規則引擎來提升行銷規則的設定效率等幾種關鍵技術設計實踐。

《vivo行銷自動化技術解密》系列文章：

一、背景

行銷自動化的觸達場景按照時效性劃分主要有兩大類：

1. 離線目標使用者群發。

通過對業務離線資料的分析決策，制定合適的運營策略對目標使用者進行群發觸達。典型的場景有：新品推薦、活動預熱、定期關懷、使用者召回等。

2.實時個性化觸達。

通過分析單個使用者在一段指定時間內的行為軌跡，進行個性化的實時性行銷觸達。典型的場景有：支付提醒，滿足活動條件觸達等。

離線目標使用者群發一般根據活動規則，T+n或者週期性對巨量資料離線使用者資料進行批次處理分析查詢，獲取滿足條件的目標使用者，從而進行行銷觸達。

需要關注的問題是：海量巨量資料的儲存、查詢效能和穩定性。而相比於離線目標使用者群發，實時個性化觸達對時效性的要求更高，一般來說觸達效果也會更優，比如：

對24小時內收藏訂單後，同時加入購物車的使用者，push推播活動領券提醒；
對領取優惠券1小時內未使用的使用者，推播使用提醒；
對活動期間成功下單總金額達到999元的使用者，推播領取獎勵提醒；

實時個性化觸達需要關注問題包括：

1. 事件實時接入的高擴充套件性。

需要快速支撐接入不同業務系統的各類行為事件和規則，需要進行統一的分發處理。

2.高效能高可靠統一分發處理。

3.複雜多源資料的處理。

包括資料的補全，各種規則指標的統計，目標使用者的交併差計算。

4.高效可延伸的規則匹配。

對業務定義的各種複雜規則，需要有一套強擴充套件性的規則匹配工具。

二、核心架構設計分析

優點：最小粒度的流量控制，不同事件接入之間可以做到隔離，互不影響。
缺點：每次接入新事件都需要申請建立佇列，隨著事件接入資料增加，佇列維護成本比較高。

方案二：同一接入方的事件使用同一佇列，不同接入方使用不同佇列（目前訊息中心的方案）

優點：按接入方來進行流量控制，接入方之間進行隔離，同一接入方只需在首次接入使用時建立佇列，後續接入新事件無需建立。
缺點： 不同接入方接入時需要建立佇列，同一接入方不隔離，有相互影響的風險。

方案三：不同接入方、事件均使用同一佇列

優點：業務方使用友好，後續接入無需變更，耦合度小，方便切換MQ中介軟體。
缺點：最大粒度的流量控制，無法做到隔離，風險較高，需要經常進行佇列擴容。

方案四：事先評估每個事件的優先順序（如流量），高優先順序的事件單獨建立一條佇列，低優先順序的事件共用同一佇列

優點：按事件的維度進行流量控制。
缺點：對接入方使用不夠友好，不同業務接入時需要建立佇列。

各方案對比如下：

結論：按照當前專案優先順序綜合評估來看，業務隔離性>可伸縮性>可維護性>接入方友好性。

方案二比較適合。（不同的專案可以根據自己的實際情況按優先順序進行合適的選型）

3.1.2 動態訊息監聽

背景：當需要做好業務間風險隔離時，就必須按業務或者事件的維度進行佇列拆分。此時若進行新接入事件就可能需要重新建立新的佇列。

初期方案：採用公司中介軟體vivo-rmq, 當接入方需要新增佇列時，需要修改程式碼新增佇列監聽，重新發版，這樣做的問題是重新發版成本較高，按照專案流程管理進行效率低。

優化方案一： 修改啟動載入類載入指定目錄下的組態檔，新增佇列時修改組態檔上傳。

優點：無需發版。
缺點：仍需要重啟伺服器，同時需要維護組態檔目錄等資訊。

優化方案二：儲存佇列設定資訊到資料表中，啟用定時任務在伺服器執行時動態監聽資料庫設定，新增或者下線佇列設定記錄後，自動進行佇列變更。

優點：無需發版和重啟。
缺點：定時任務實時性稍差，必須確保佇列監聽成功後在通知業務方接入。

結論：採用方案二，新增事件無需對系統進行重新部署，使用執行時動態方式進行訊息佇列接入。

3.2 統一分發處理

抽象公共分發模板：事件引數和有效性檢測 → 分發到事件規則匹配器 EventMatcher → 輸出到渠道傳送流程

可靠平滑啟停

1. MQ消費端分發主流程未處理完成，系統重啟可能會造成事件訊息丟失。

解決方案：設定MQ消費端沒有返回ack時，MQ伺服器端重新傳送訊息，此時業務消費必須保證冪等性。

2. MQ分發主流程處理完成已返回ack，但是在分發到業務執行緒池過程中，由於JVM重啟而丟失。

解決方案：這種場景時間極短，可以等待分發完成再進行ack。

3. MQ分發主流程分發到業務執行緒池處理過後，但是執行緒池處理渠道傳送過程仍可能因為JVM重啟而丟失。

解決方案：

利用JVM ShutdownHook勾點函數設定重啟標記flag，MQ取資料時可以根據flag不再取出資料；
業務執行緒池不再接受新的任務, 同時利用執行緒池自身的Hook，等待處理執行緒池完成已有的任務。

3.3 複雜多源資料的處理

指標補全

業務接入方可以提前將業務資料載入到統一巨量資料平臺，並補充後設資料設定，支援實時事件資料之外的資料補全。

指標統計

對規則設定資料進行，使用Flink CEP負責事件處理，支援時間視窗計算。

交併差運算

基於Presto計算查詢引擎，對不同目標使用者群進行交併差負責運算，得到處理後的結果資料。

3.4 規則匹配器義

傳統方案

使用簡單直接的寫死的方式，根據不同的事件條件進行編碼處理，適合迭代更新要求低的小型系統。

傳統方案存在的問題

寫死開發成本高，交付時間長，難以應對需求變化。
業務規則重複累贅，難以維護。
業務規則發生變化需要修改程式碼，重啟服務後才能生效。

規則引擎

狹義上的規則引擎是業務規則管理系統，英文名為BRMS(即Business Rule Management System)，指一整套的規則管理解決方案。

而廣義上的規則引擎是指一個可以將業務決策從應用程式程式碼中分離出來的輸入輸出元件，接收業務資料輸入，並根據業務規則輸出決策。

規則引擎重點關注的是：規則設定的通用性和擴充套件性，以及規則匹配的效能。

規則引擎優點

業務規則與系統程式碼分離，實現業務規則的集中管理。
在不重啟服務的情況下可隨時對業務規則進行擴充套件和維護。
可以動態修改業務規則，從而快速響應需求變更。
規則引擎是相對獨立的，只關心業務規則，使得業務分析人員也可以參與編輯、維護系統的業務規則。
減少了寫死業務規則的成本和風險。
使用規則引擎提供的規則編輯工具，使複雜的業務規則實現變得的簡單。

規則引擎的實現選型

目前開源規則引擎 Drools、Easy Rules、表示式引擎Aviator，還有動態語言Groovy、甚至直接使用SpEL進行封裝都可以作為規則引擎的一種實現方案。

如果需要搭建一整套完整BRMS的功能，從規則設定工作臺，圖形化語言建模，規則庫管理等一站式解決方案，可以直接選用Drools。這也是大家認為Drools使用起來比較「重」的原因，元件繁多邏輯複雜，學習成本高。
如果業務場景相對簡單，只是希望解決規則迭代頻繁的問題，提升設定管理的擴充套件性，可以選用Easy Rules或者利用表示式引擎Aviator為基礎搭建。

規則引擎常用應用場景

風險控制系統：風險貸款、風險評估
反欺詐專案：銀行貸款、徵信驗證
決策平臺系統：財務計算
促銷平臺系統：滿減、打折、加價購等行銷場景
其他應用場景

四、總結

本文重點分析介紹在行銷自動化業務中實時行銷引擎的設計，實時行銷是通過分析單個使用者在一段指定時間內的行為軌跡，產生動態的運營決策，可以對使用者進行即時性的觸達。

實時行銷引擎架構設計主要分為事件接入、資料處理、指標計算、資料輸出、後設資料設定和數倉管理等模組。在專案開發過程我們利用佇列隔離做好業務流量隔離，佇列動態設定支援事件高效接入釋出，統一分發處理提升流程的抽象化，平滑釋出保障資料的可靠性，規則引擎來提升行銷規則的設定效率。