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

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

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

1. vivo營銷自動化技術解密｜開篇

2. 設計模式如何提升 vivo 營銷自動化業務擴充套件性 | 引擎篇01

3. 狀態機引擎在vivo營銷自動化中的深度實踐 | 引擎篇02

4. 工作流引擎在vivo營銷自動化中的應用實踐 | 引擎篇03

一、背景

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

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

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

2.實時個性化觸達。

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

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

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

1. 對24小時內收藏訂單後，同時加入購物車的使用者，push推送活動領券提醒；

2. 對領取優惠券1小時內未使用的使用者，推送使用提醒；

3. 對活動期間成功下單總金額達到999元的使用者，推送領取獎勵提醒；

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

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

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

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

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

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

4.高效可擴充套件的規則匹配。

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

二、核心架構設計分析

接入層

提供多種業務事件資料接入方式（比如支援異構外部系統的通用HTTP，內部的DUBBO、MQ等），最後轉成MQ的方式統一分發。

1. 由於事件資料來源的不同，需要對宿主業務進行佇列流量隔離管控，同時還需要評估後續佇列的容量伸縮效率。

2.  需要滿足新增事件時，無需對系統進行重新部署，需要進行動態訊息佇列接入（下文會進行詳細解析）。

資料處理層

實時引擎的核心部分。主要負責對事件資料進行加工處理，主要包括：

1.  業務資料的統一標識補全，將多源資料進行打通關聯。

2. 對業務資料進行各種指標計算。常見的是基於時間視窗和會話視窗的流式計算，一般使用Flink來搭建。         

3. 目標使用者匹配。常用的使用者直接交併差集計算，能夠更好的對目標使用者進行實驗。

4. 業務規則匹配。基於業務邏輯對使用者的資料進行匹配。

資料輸出層

負責結果資料輸出分發，主要目的是資料調配和觸達傳送策略。

資料管理

儲存事件後設資料的配置。

資料倉儲

離線資料的儲存，作用於流程中各種資料處理流程。

三、關鍵元件和流程設計

3.1 事件實時接入的擴充套件性設計

由於公司內部業務技術棧不盡相同，需要支援多種業務事件資料接入方式，比如通用HTTP介面，Java技術棧的DUBBO介面、和MQ訊息佇列的方式，為了系統內部可以進行統一管理，最後轉成MQ的方式進行統一分發。

3.1.1 接入佇列設計

由於事件資料來源的不同，需要對宿主業務進行MQ佇列流量管控隔離。不同業務系統事件接入需求有以下不同的設計方案：

方案一：為每個接入的事件建立一條新佇列，不同事件使用不同佇列。

• 優點：最小粒度的流量控制，不同事件接入之間可以做到隔離，互不影響。

• 缺點：每次接入新事件都需要申請建立佇列，隨著事件接入資料增加，佇列維護成本比較高。

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

• 優點：按接入方來進行流量控制，接入方之間進行隔離，同一接入方只需在首次接入使用時建立佇列，後續接入新事件無需建立。

• 缺點： 不同接入方接入時需要建立佇列，同一接入方不隔離，有相互影響的風險。

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

• 優點：業務方使用友好，後續接入無需變更，耦合度小，方便切換MQ中介軟體。

• 缺點：最大粒度的流量控制，無法做到隔離，風險較高，需要經常進行佇列擴容。

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

• 優點：按事件的維度進行流量控制。

• 缺點：對接入方使用不夠友好，不同業務接入時需要建立佇列。

各方案對比如下：

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

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

3.1.2 動態訊息監聽

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

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

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

• 優點：無需發版。

• 缺點：仍需要重啟伺服器，同時需要維護配置檔案目錄等資訊。

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

• 優點：無需發版和重啟。

• 缺點：定時任務實時性稍差，必須確保佇列監聽成功後在通知業務方接入。

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

3.2 統一分發處理

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

可靠平滑啟停

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

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

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

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

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

解決方案 ：

1. 利用JVM ShutdownHook鉤子函式設定重啟標記flag，MQ取資料時可以根據flag不再取出資料；

2. 業務執行緒池不再接受新的任務,  同時利用執行緒池自身的Hook，等待處理執行緒池完成已有的任務。  

3.3 複雜多源資料的處理

指標補全

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

指標統計

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

交併差運算

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

3.4 規則匹配器義

傳統方案 

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

傳統方案存在的問題

1. 硬編碼開發成本高，交付時間長，難以應對需求變化。

2.  業務規則重複累贅，難以維護。

3. 業務規則發生變化需要修改程式碼，重啟服務後才能生效。

規則引擎

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

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

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

規則引擎優點

1. 業務規則與系統程式碼分離，實現業務規則的集中管理。

2. 在不重啟服務的情況下可隨時對業務規則進行擴充套件和維護。

3. 可以動態修改業務規則，從而快速響應需求變更。

4. 規則引擎是相對獨立的，只關心業務規則，使得業務分析人員也可以參與編輯、維護系統的業務規則。

5. 減少了硬編碼業務規則的成本和風險。

6. 使用規則引擎提供的規則編輯工具，使複雜的業務規則實現變得的簡單。

規則引擎的實現選型

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

1. 如果需要搭建一整套完整BRMS的功能，從規則配置工作臺，圖形化語言建模，規則庫管理等一站式解決方案，可以直接選用Drools。這也是大家認為Drools使用起來比較“重”的原因，元件繁多邏輯複雜，學習成本高。

2. 如果業務場景相對簡單，只是希望解決規則迭代頻繁的問題，提升配置管理的擴充套件性，可以選用Easy Rules或者利用表示式引擎Aviator為基礎搭建。

規則引擎常用應用場景

1. 風險控制系統：風險貸款、風險評估

2. 反欺詐專案：銀行貸款、徵信驗證

3. 決策平臺系統：財務計算

4. 促銷平臺系統：滿減、打折、加價購等營銷場景

5. 其他應用場景

四、總結

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

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