作者：vivo 互聯網伺服器團隊

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

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

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

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

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

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

一、背景

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

1. 離線目標用戶群發。

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

2.實時個性化觸達。

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

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

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

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. 其他應用場景

四、總結

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

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