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

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

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

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

一、分析現(xiàn)狀

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

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

二、整體設(shè)計思路

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

1. 事件驅(qū)動設(shè)計

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

說到這里大家應(yīng)該發(fā)現(xiàn)本質(zhì)上就是一個業(yè)務(wù)事件總線，如果看過SOA事件交互總線的定義，本質(zhì)上思想是一樣的，只不過我們不需要SOA這么強的定義。不光是SOA架構(gòu)設(shè)計中會有相關(guān)描述，如果熟知微服務(wù)架構(gòu)、事件驅(qū)動架構(gòu)還有DDD設(shè)計思想等，也存在大量對于事件總線設(shè)計的描述。

這里的業(yè)務(wù)事件總線不過是在這些思想之上，根據(jù)活動業(yè)務(wù)場景進行本地化處理，增加了一些動態(tài)決策、配置關(guān)聯(lián)的能力。

2. 上下文共享問題

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

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

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

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

整體比較來看：

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

3. 上下文的設(shè)計

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

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

上下文 + 動態(tài)決策編排 = 活動編排引擎

三、性能保證

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

1. 更少&更快的IO

對于事件總線的使用，盡可能不發(fā)生網(wǎng)絡(luò) IO，首先對于事件總線調(diào)用的應(yīng)該本地化，第二是事件總線對于外部事件的調(diào)用盡量本地化，僅作為邏輯上的模塊。

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

2. 更快的存儲

硬編碼 > 內(nèi)存 > 本地磁盤 > 網(wǎng)絡(luò)IO，常規(guī)事件之間的關(guān)聯(lián)關(guān)系直接內(nèi)存存儲（可以DB預(yù)加載至進程內(nèi)），強關(guān)聯(lián)事件配置直接硬編碼（硬編碼的配置問題可以利用一些表達式），避免發(fā)生網(wǎng)絡(luò)IO、磁盤IO。

3. 合理的優(yōu)化分布式下的量

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

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

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

4. 數(shù)據(jù)一致性保證

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

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

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

四、現(xiàn)有的輪子

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