二維火營銷底層實踐

前言

營銷是餐飲行業很是重要的一環，如何經過各類營銷幫助商戶實現老客迴流，潛在客戶的推廣引流，以及店內客流的數字化轉變和數據沉澱等，是餐飲行業公司的核心競爭力。隨着二維火會員營銷業務的快速發展，營銷活動業務需求愈來愈多，每次對接營銷活動需求，對於開發人員來講，從新開發一套，都是一個費時費力，成本巨大的工做，上線的活動伴隨着也愈來愈難維護,一個小改動也會致使系統不穩定。如何快速，靈活的去對接活動需求以及容易維護是當前面臨的一個挑戰。

爲了應對這個挑戰，會員營銷底層研發團隊啓動了營銷底層改造項目，主要圍繞如下幾個方面進行展開:

• 框架流程統一: 活動流程統一，提高效率, 避免重複代碼，便於維護等等。
• 規則解析引擎: 優惠活動規則的配置，解析和匹配功能，將業務規則決策邏輯從系統邏輯中抽離出來。
• 優惠組件化以及優惠自動化: 封裝可重用優惠組件，提高代碼的可複用性。業務不關心優惠發放，優惠自動化發放。
• 工具化: 業務流程代碼界面可視化，查找問題更高效，很大程度讓開發人員從線上問題羣解放出來。

解決方案

在明確改造點以後，咱們就開始了營銷底層系統的設計，具體的系統架構圖以下所示。下面咱們開始逐層的介紹。

框架流程統一

在框架流程統一以前，每一個活動單獨一套代碼，由於歷史緣由，是由不一樣開發人員去開發。致使代碼風格不一，代碼鏈路也很長，後期維護人員比較難維護，一個小改動可能也會形成鏈路不穩定，引出其餘問題。

所以，咱們根據不一樣活動流程，梳理核心主鏈路，統一流程，不一樣活動統一流程接入。如下是部分時序圖。

這裏簡單說下典型的兩條主鏈路:

發佈活動場景下:

• 全部營銷活動都會涉及到商家發佈保存這塊，通常都是活動先添加保存，而後發佈，總體代碼流程是統一的。這裏要提到的是發佈這裏由於不一樣營銷活動涉及的邏輯仍是有稍微區別的，因此這裏提供了鉤子HOOK，主流程嵌入前中後鉤子，以便不一樣營銷活動業務去擴展主流程，知足本身的業務個性化需求。這裏主要仍是經過活動類型路由反射去尋找不一樣鉤子，jdk反射自己效率是很低的，目前引入了reflectasm，同時反射對象緩存了下，以便提升效率。（不過本地緩存這塊有對象個數上限，後期能夠考慮引入淘汰算法主動淘汰）
• 活動發佈過程中，同時也伴隨着一些事件的觸發，好比店鋪打標等。目前主要提供了基於spring事件驅動同步或異步的鉤子去知足相應需求，同時給業務方提供了相應的mq消息通知，讓業務方訂製業務處理。

發放優惠場景下:

• 發放優惠，首先會通過規則解析引擎這塊，匹配相應的規則，進行判斷，好比是否知足100塊，是不是新人等，而後觸發執行相應的統一發送底層接口。底層觸發組件管道鏈路，不一樣組件會有不一樣的二進制位置標識，數據路由能夠控制到不一樣優惠組件，優惠組件而後各自執行業務邏輯。接着也預留了個消息口子，讓業務方定製化處理，好比消息觸發等。

規則解析引擎

以前規則條件判斷這塊比較分散，規則條件判斷與其餘系統代碼耦合在一塊兒，改動起來也比較容易出問題。另外一方面，每個營銷活動的接入都涉及到規則的開發，規則惟一不變的就是"多變"。出於規則統一的角度，以及後續平臺規則可讓業務運營方定製化配置角度的考慮，引入了規則解析引擎。

規則引擎這塊仍是比較複雜的，不過目前咱們規則這塊仍是比較簡單的，主要仍是涉及到Condition條件與Action動做。舉個例子，好比判斷是否新人，送禮品。

規則的判斷經過condition註解標記方法去控制，規則經過的話，觸發相應Action標記的方法行爲。
上面只是個簡單的舉個例子。實際上規則判斷這塊，沒這麼簡單。通常規則涉及到多個規則組合觸發行爲，以及多個規則有一個規則經過（可能涉及優先級@Priority），就觸發行爲，後續規則直接中斷等。目前營銷底層規則策略主要仍是單個以及組合策略，仍是比較簡單的, 能夠知足如今的需求。後面隨着業務愈來愈複雜，以及營銷活動平臺開放出去的發展，運營配置化等，咱們會去考慮規則動態化配置，規則策略的完善，規則表達式解析等等。

優惠組件化以及優惠自動化

優惠組件化，主要仍是出於模塊重用性以及代碼複用性考慮，優惠之間如何執行互不影響，各自維護本身的業務以及保持本身的穩定性。目前咱們優惠組件主要仍是包含下面這幾個:

這裏提到的自動化主要仍是指，基於規則觸發優惠自動化發送這塊。上面已經提到過，營銷活動業務本身定義一些規則，判斷用戶是否發送優惠，主要先通過規則解析引擎，知足後觸發底層優惠發送接口。後續給用戶發送什麼優惠，以及發送多少，失敗重試以及補償，底層自動化處理，業務方不用關心，只須要簡單觸發一下。固然咱們也開放出去了接口，支持業務方去自定義發送什麼，流水記錄是否記錄等。

工具化

目前咱們營銷業務這塊正在快速發展中，隨之伴隨着線上大量業務的問題諮詢以及答疑。開發每每在這方面花費很多時間與精力去排查。工具化就是基於此誕生的，簡單說就是用產品的思惟開發出這套工具，讓工程團隊等去查詢問題，知道問題出在哪一步，極大解放出來了研發。

上面說到咱們目前框架流程統一，這樣其實讓工具化更好統一了。那究竟工具化是怎樣的呢？

好比，優惠發放整個流程節點以下圖:

工程團隊在使用工具化後臺的話，要查看某個用戶的權益發放狀況。輸入店鋪編碼與手機號，出現活動列表，選擇商家相應的活動，進入到相似上面的節點圖。工程團隊能夠查看每一步的執行狀況，好比step3，觸發領卡動做，可能這一步會失敗，那結點上會顯示爲何失敗，具體緣由多是會員卡刪除了仍是其餘的什麼。簡單說就是整個業務流程可視化了，能夠看每個結點的執行狀況，固然業務方能夠自行定義結點，在流程展現出來。不只僅對於工程團隊，對於研發來講，其實也很大減輕了排查問題的效率。

從技術層面考慮，工具化實現，除了自己框架流程自行會記錄下來關鍵數據，咱們在數據底層提供了相應的服務接口暴露開放出來，可讓業務自行自定義結點，埋點記錄下來業務執行數據。目前業務結點關鍵數據是存儲在TIDB，主要仍是由於TIDB既能像MySQL同樣便於使用，能讓業務幾乎不用作任何修改，又能知足分佈式的存儲需求，同時還能保證查詢性能。這裏提到一點，隨着業務的接入，這個接口後期可能QPS仍是很高的，咱們目前仍是經過mq去削峯，以及併發控制。

總結以及後續規劃

營銷底層其實很大程度上提升研發效率，以及系統穩定性。除了上面提到的一些點之外，營銷底層其實還作了不少，好比動態日誌級別輸出等。後續隨着業務的遷入，營銷底層後面主要仍是更多的考慮怎麼去完善底層鏈路，規則策略，動態配置化，以及平臺化開放等。

招聘

最後插播一個招聘廣告，會員營銷部門是一個崇尚自由、開放、互通的部門，對營銷產品開發感興趣的能夠發郵件給 lurou@2dfire.com

---

若是你以爲我分享的東西有所幫助,不妨關注下。