營銷活動的搭建在最開始是“定制化”的，后來重復性活動多了，便開始套用活動模板，然而用多了又會導致用戶疲勞，于是活動述求變成在現有模板上串聯不同玩法，不斷新增玩法。本文作者分析了在營銷活動中，用戶參與流程或者說玩法串聯的流程編排問題，剛興趣的小伙伴們一起來看一下吧。

就營銷活動搭建的發展過程而言：最初的營銷活動的搭建通常是“定制化”的，面臨一個需求、一個場景寫一個活動，慢慢地重復性活動越來越多，開始借鑒模板的思想，制作幾套活動開始每次換膚，但是次次換膚限定了玩法套路，容易導致用戶疲勞，效果開始衰退。

這時候活動的訴求已經變成在現有的模版思想上靈活串聯現有玩法，并不斷新增玩法，所以開始沉淀一個又一個的標準“玩法”，比如說任務、簽到、抽獎、投票、答題、助力、組團、打榜等等若干玩法，然后每次有新的活動我們只需要手動開發串聯即可。

整個的對于玩法的串聯，可以通過定制開發解決，也可以通過研發配置解決，最終可以完全脫離研發運營配置解決，本篇要描述的就是營銷活動中，用戶參與流程或者說玩法串聯的流程編排問題。

一、分析現狀

正如前面所提到的，我們對于常用的玩法進行沉淀之后，我們獲得了各類形式的抽獎、答題、任務、簽到等玩法，在使用的過程中，通常是玩法A的某個動作在某種場景下關聯玩法B的某個動作，比如用戶第一次參與答題獲得一次抽獎機會，用戶任務完成獲得現金等等。

如果純研發開發定制關聯的話，每次面臨開發的關系是相對復雜的，按照量級來算基本是：m*n*s （輸出事件、輸入動作、場景），即使每次都有沉淀，玩法和玩法的交互關系基本是過度復雜、難以維護的，所以我們需要一個“總線”工具來集中管理這些交互，降低復雜度。

二、整體設計思路

對于這些易變且復雜的邏輯，最直觀的思路是剝離業務決策邏輯與代碼決策邏輯。在活動編排的場景下，業務邏輯是玩法事件之間的關聯關系及決策關系，代碼關聯就是各類事件的接受、各類事件的call。

1. 事件驅動設計

所以需要規范下玩法的輸入輸出，然后有一個地方能夠對這些事件配置關聯，對于關聯之間的業務決策邏輯，只需要借鑒一下決策引擎就可以了。整個抽象完成后活動串聯的成本已經從m*n*s降低到m+n，并且直接進入到研發配置關聯階段，成本至少能縮減80%以上，并為后續的運營可直接手動配置提供了功能開發的切入口。

說到這里大家應該發現本質上就是一個業務事件總線，如果看過SOA事件交互總線的定義，本質上思想是一樣的，只不過我們不需要SOA這么強的定義。不光是SOA架構設計中會有相關描述，如果熟知微服務架構、事件驅動架構還有DDD設計思想等，也存在大量對于事件總線設計的描述。

這里的業務事件總線不過是在這些思想之上，根據活動業務場景進行本地化處理，增加了一些動態決策、配置關聯的能力。

2. 上下文共享問題

在把各種玩法解耦，然后通過業務事件總線進行玩法關聯，每個玩法內部基本形成一個信息孤島，只關心自己內部的變化，其實是不利于活動邏輯的。高門檻任務加的抽獎機會面向的獎品集合往往價值更高，不同的組團（不同身份團隊成員）面向的獎勵價值也是不同，很多時候需要依賴用戶參與的上下文信息，如果打破信息孤島，通常有兩種處理思路：

1）把獎勵這些需要上下文的玩法做成一種基礎能力，感知所有玩法的上下文，獎勵作為一種微內核的存在，每個玩法直接帶著上下文調用。

2）進一步抽象這些感知上下文的應用，將業務規則進一步剝離，僅有業務規則（規則引擎）感知上下文信息，其他玩法的上下文對于一個玩法來說只是普通 key-value 而已，具體使用在持有業務規則的表達式中執行。

整體來看兩種思路本質上都是可以的，適用于不同的系統發展階段，活動相對較多，第一種就足夠了，復雜活動較多，第二種就相對適合。

整體比較來看：

• 第一種：實現相對簡單，對玩法的要求相對較低，但是如果一個操作，同時涉及多個玩法的上下文，處理相對費勁。并且需要上下文的操作如果變多且關聯，架構就逐漸退化到手動強關聯。
• 第二種：實現相對復雜，對于玩法可配置要求較高，但擴展性較好，對于復雜活動的處理更加輕松。

3. 上下文的設計

上下文的設計相對簡單，可以粗暴地理解為一個 get 的路由分發，大家可以理解為一個具有業務特性的 dataSource，可以根據一個 key 來找到我們所需要的用戶參與的上下文信息。

具體的實現方案可以是一個集中存儲，用來存放活動的上下文，也可以是邏輯上的集中存儲，做一層代理透過玩法注入的 method 活動上下文。

上下文 + 動態決策編排 = 活動編排引擎

三、性能保證

由于需要處理一個業務或者幾個業務下的事件流轉，業務事件總線是一個對性能要求相對較高“系統節點”，需要盡可能保證它的性能極佳的特點，這里就來說一下對于事件總線的整體優化過程（按照老套路，先優化點、再優化分布式場景下“量”），先看結果：

1. 更少&更快的IO

對于事件總線的使用，盡可能不發生網絡 IO，首先對于事件總線調用的應該本地化，第二是事件總線對于外部事件的調用盡量本地化，僅作為邏輯上的模塊。

如果因為擴展性、可用性等若干因素，當前的架構不允許或者不支持整個活動玩法打包到一起部署，便免不了發生 IO，那就一句話，盡可能地利用 epoll，這些事作為一個業務開發來說交給基礎架構來處理就好啦。

2. 更快的存儲

硬編碼 > 內存 > 本地磁盤 > 網絡IO，常規事件之間的關聯關系直接內存存儲（可以DB預加載至進程內），強關聯事件配置直接硬編碼（硬編碼的配置問題可以利用一些表達式），避免發生網絡IO、磁盤IO。

3. 合理的優化分布式下的量

事件異步化處理&微批處理這類優化吞吐的直接拿來主義，看看 kafka 之類的 mq 的優化思路，我相信大家就知道該怎么做了，像這種場景直接就別重復造輪子了，用 kafka 實現異步化就足夠了。

平衡一致性、可用性，前面提到了盡可能利用快的存儲，在分布式場景下，如果能接受多節點不一致可以用這個思路，如果一致性要求相對較高可以用單點的 redis 進行關聯關系的存儲，如果對可靠性要求很高再退一步使用 mysql 這些。

通常來說，事件總線總并沒有顯著的業務熱點，橫向擴容基本可以解決所有量的問題，意義需要注意的就是這個業務上的單點，做好資源隔離就可以啦。

4. 數據一致性保證

事件總線并不是一個強業務實體，屬于一個純虛構的概念，我們只需要使用到事件總線的流程能得到保證即可。

對于分布式事務的場景，這個依賴于分布式事務的實現方案，如果是TCC類，只要保證事件能正常參與進事務中即可，對于依賴于事務型消息的分布式事務，可以替換下事件總線的“事件調用維護”，在事務消息隊列上做封裝即可。

對于沒有分布式事務的處理場景下，最大程度利用冪等重試，做好事件處理的補單極致就好了，順便說下，圍繞“事件總線”做冪等重試是一個不錯的處理思路。

四、現有的輪子

打開搜索引擎搜一下業務事件總線，阿里云、騰訊云都有相似的解決方案，只不是針對的業務場景相對較少，這東西并不復雜一個人兩個周基本就能開發完成上線了，最重要的是對應思想的本地化實現，如果現實工作過程中遇到了相似的場景，綜合評估下成本來落地就好了。