规则引擎：大厂营销系统资格设计全解
業(yè)務(wù)進(jìn)行營銷活動目的是用最少的錢實現(xiàn)更好的營銷效果，此時就需要針對營銷活動的資格進(jìn)行控制，其中就包括了用戶身份、用戶所處的環(huán)境等等一系列因素的考慮，且為了防止惡意套取營銷費(fèi)用和做到營銷效果的持續(xù)性，會進(jìn)行活動相關(guān)次數(shù)的控制。此時為了適應(yīng)業(yè)務(wù)不斷變革的營銷活動資格，好的資格設(shè)計就非常重要。
營銷活動業(yè)務(wù)在配置中會同一時間存在多個營銷活動，用戶進(jìn)入某個場景，首先需要給用戶展示目前用戶能夠享受的營銷活動，增加用戶參與此場景的意向，然后用戶參與場景后需要給用戶提示對應(yīng)的營銷活動，用戶如果沒有參與成功需要給用戶提示具體沒有參與成功的原因。那么在參與前，具體的場景中需要進(jìn)行用戶資格的校驗，并且用戶參與后需要進(jìn)行資格記錄。
同時，資格校驗?zāi)軌蛴行Х乐褂脩糁貜?fù)參與的問題，通過配置用戶的次數(shù)資格來進(jìn)行校驗，用戶參與成功一次進(jìn)行記錄，后面用戶參與前對次數(shù)資格進(jìn)行相關(guān)的校驗。
資格分類
資格設(shè)計先要針對資格進(jìn)行分類，通過不同的分類進(jìn)行各自分類領(lǐng)域模塊設(shè)計。分類的原則是分層漏斗分類：優(yōu)先過濾大量不滿足、消耗服務(wù)器資源較少的活動，再過濾需要消耗服務(wù)器資源較多的活動，最后是進(jìn)行風(fēng)控資格校驗。按照這個分類原則后面可能會出現(xiàn)多個營銷活動，這個是另外一個話題—營銷推薦設(shè)計。
以上是目前蘇寧金融這邊針對資格設(shè)計的分類：靜態(tài)資格、動態(tài)資格和風(fēng)控資格。此處風(fēng)控資格校驗作為獨(dú)立的一個分類并且放在最后，主要是由兩個方面考慮：（1）風(fēng)控的內(nèi)容很多，在蘇寧金融有專門的風(fēng)控中心來進(jìn)行風(fēng)控規(guī)則的制定和執(zhí)行；（2）風(fēng)控返回的風(fēng)控級別也有很多，營銷活動的不同、觸發(fā)風(fēng)控的級別不同，對應(yīng)的營銷活動處理邏輯也不一樣。
下面針對以上的分類的靜態(tài)資格和動態(tài)資格進(jìn)行相關(guān)的領(lǐng)域模塊具體設(shè)計探討。
靜態(tài)資格
靜態(tài)資格在蘇寧金融營銷中的定義是：用戶進(jìn)入具體場景、當(dāng)時用戶屬性標(biāo)簽的一個靜態(tài)數(shù)據(jù)。
靜態(tài)數(shù)據(jù)的獲取方面主要通過兩個部分獲取：（1）上游系統(tǒng)的傳遞，這個數(shù)據(jù)主要是獲取用戶所處的場景數(shù)據(jù)，包括但不限于：用戶當(dāng)前進(jìn)行的業(yè)務(wù)及業(yè)務(wù)數(shù)據(jù)、用戶使用終端、網(wǎng)絡(luò)環(huán)境等等數(shù)據(jù)。（2）用戶屬性標(biāo)簽的大數(shù)據(jù)獲取。在蘇寧金融大數(shù)據(jù)中心有一套完整的用戶實時標(biāo)簽庫，用戶請求后通過次標(biāo)簽庫實時查詢用戶目前的標(biāo)簽。
靜態(tài)數(shù)據(jù)的過濾在技術(shù)方案中適合采用規(guī)則引擎進(jìn)行相關(guān)資格校驗。目前在蘇寧金融的營銷系統(tǒng)中使用 Drools，主要是考慮以下幾個方面：
（1） 業(yè)務(wù)規(guī)則較多，如果使用編碼方式新增規(guī)則就需要進(jìn)行相關(guān)的編碼，增加代碼量和維護(hù)成本。
（2） Drools 的自定義關(guān)系操作符：通過自定義關(guān)系操作符可以針對不同的業(yè)務(wù)規(guī)則配置需要的操作符還可以針對每個活動不能匹配的原因進(jìn)行內(nèi)部埋點(diǎn)記錄，方便運(yùn)營進(jìn)行客訴查詢。
（3） 純 java 實現(xiàn)，學(xué)習(xí)成本低。
業(yè)務(wù)配置生成 drl 文件設(shè)計
關(guān)于生成 drl 文件的設(shè)計，先來看看 drools 引擎原理：
Drools 引擎通過每個條件進(jìn)行匹配，最終匹配出相關(guān)的活動，所以在設(shè)計中需要考慮最終返回的數(shù)據(jù)是活動集合。
Drl 文件組成：
通過原理及文件組成，設(shè)計 Drl 文件生成的類圖如下：
writeRuleFile 是入口，通過入口進(jìn)行內(nèi)部方法組裝，此方法需要功能是組裝文件內(nèi)容和寫文件；writeDrlHead 方法為寫文件頭部包、引用和全局變量定義；assembleEvaluatorDefinition 方法是組裝自定義操作符規(guī)則；getActRuleWhenCondition 此方法為拼接規(guī)則字符串；writeActivityRule 此方法為活動的規(guī)則寫入。
以上是一種純 java 代碼實現(xiàn) Drl 文件生成的一個方式，目的是為了讓大家能夠理解 Drl 文件的結(jié)構(gòu)。實際操作過程中也可以通過 freemarker 模版來生成對應(yīng)的 Drl 文件。
Drools 規(guī)則加載
此處規(guī)則加載設(shè)計可以設(shè)計為內(nèi)置定時器掃描規(guī)則生成表是否有新增記錄或者采用分布式集群通知的方式進(jìn)行加載。
目前，蘇寧內(nèi)部的統(tǒng)一配置平臺采用的是自研的 SCM 平臺，能夠很好地支持實時修改，應(yīng)用服務(wù)器集群每臺應(yīng)用監(jiān)聽具體某個配置文件的內(nèi)容變更。
應(yīng)用服務(wù)器監(jiān)聽到需要進(jìn)行 Drl 文件 加載后，通過拉取 Drl 文件，并讀取其中的內(nèi)容生成對應(yīng)的 KieBase。
靜態(tài)資格匹配
為了更加通用性在設(shè)計中可以設(shè)置規(guī)則匹配的入?yún)?Map 形式，在進(jìn)行匹配前需要把靜態(tài)資格數(shù)據(jù)轉(zhuǎn)化為 Map 數(shù)據(jù)格式，然后在生成的 KieBase 中獲取 KieSession，通過此 KieSession 進(jìn)行規(guī)則匹配。
KieSession 需要設(shè)置全局的一個集合，來返回匹配到相關(guān)活動編碼數(shù)據(jù)，同時需要考慮活動是有狀態(tài)和有效期的，所以在拿到靜態(tài)數(shù)據(jù)匹配的活動編碼后，需要對活動的狀態(tài)進(jìn)行篩選，拿到的是生效且在有效期范圍內(nèi)的活動。
動態(tài)資格
此處動態(tài)資格主要是指活動的次數(shù)和用戶次數(shù)。營銷活動為了能夠使更多的用戶能夠參與，防止某些用戶的重復(fù)參與，會對用戶的每日、每月、總參與次數(shù)進(jìn)行限制，同時活動的經(jīng)費(fèi)是有限的，為了能夠使?fàn)I銷活動效果做的更好，也會對活動的每日、每月、總次數(shù)進(jìn)行限制。
動態(tài)資格設(shè)計可以分為兩個維度，一個是對象，一個是周期：
通過上圖設(shè)計，周期維度確認(rèn)好后變更的可能性比較小，可以在前期調(diào)研階段確認(rèn)好周期范圍。不過，對象變更相比較周期而言會更頻繁，前期系統(tǒng)上線的時候確認(rèn)一個自然人可能只有帳號、綁定手機(jī)兩個屬性，后期通過系統(tǒng)的不斷迭代及技術(shù)的不斷進(jìn)步這個屬性可能會進(jìn)行擴(kuò)容。所以，在進(jìn)行架構(gòu)設(shè)計的時候需要考慮具體對象的擴(kuò)展性。同時，為了高并發(fā)的查詢、次數(shù)的扣減或者回滾，可以通過緩存來代替數(shù)據(jù)庫的記錄和操作，當(dāng)然為了保證數(shù)據(jù)的可恢復(fù)性，可以設(shè)計實時緩存，異步落庫的操作。
動態(tài)資格組裝
資格組裝按照分析，采用抽象類封裝內(nèi)部實現(xiàn)，每個對象通過繼承抽象類，實現(xiàn)具體的抽象方法的方式來實現(xiàn)。
抽象類 AbstractDimensionDynamic 中有兩個抽象方法獲取對象 targetType 和獲取對象值 targetValue 是在具體類中進(jìn)行實現(xiàn)。dynamicAssemble 方法是進(jìn)行 dynamicKey 的拼接并組裝動態(tài)資格的具體對象，最終得到動態(tài)資格對象的集合。
AbstractDimensionDynamic 的子類是具體的動態(tài)資格對象，每增加一個對象，通過增加子類的方式來實現(xiàn)。
動態(tài)資格服務(wù)
此處設(shè)計中 DynamicService 對外提供的是動態(tài)資格校驗和動態(tài)資格扣減兩個服務(wù)，在實際過程中還會存在回退的服務(wù)，這個需要自行進(jìn)行擴(kuò)展。
抽象類 AbstractDynamicService 中的 dimensionDynamics 是一個 List，并且注解為 @Autowired，Spring 會自動從容器中取出 DimesionDynamic 的實現(xiàn)類裝配到 List 類型的 dimensionDynamics 中，從而簡化了依賴注入的過程，并且有新增實現(xiàn)類的時候系統(tǒng)啟動會自動注入。
@Autowiredprivate List<DimensionDynamic> dimensionDynamics; @Resourceprivate RedisService redisService;復(fù)制代碼
其中的 assembleDynamicRecordList 方法是通過遍歷 dimensionDynamics，組裝需要的查詢或者扣減的動態(tài)數(shù)據(jù)記錄；rollback 方法是扣減出現(xiàn)異常或者扣減超過限制后進(jìn)行回滾使用的操作，此方法需要拋出異常，供上游判斷是否需要進(jìn)行處理。
緩存使用 Redis，主要是考慮在 redis 中的 incrBy 和 decrBy 都是原子性操作，這個在高并發(fā)的場景中防止由于并發(fā)導(dǎo)致的累計錯誤問題。而且 redis 的 mget 命令可以批量查詢，主要是由于 redis 使用基于 RESP 協(xié)議的 rpc 接口，而 redis 本身的數(shù)據(jù)結(jié)構(gòu)非常高效，所以 IO 和協(xié)議解析是個不容忽略的資源消耗。通過 mget 將多個 get 請求匯聚成一條命令，可以大大降低網(wǎng)絡(luò)、rpc 協(xié)議解析的開銷，從而大幅提升緩存效率。
DynamicServiceImpl 是 DynamicService 的具體實現(xiàn)，并且要繼承 AbstractDynamicService 抽象類。需要實現(xiàn) dynamicChack 動態(tài)資格校驗和 dynamicDeduction 動態(tài)資格扣減方法。
動態(tài)資格校驗是通過組裝的動態(tài)記錄數(shù)據(jù)集，到緩存中查詢目前存儲的值跟對應(yīng)動態(tài)資格最大值進(jìn)行比較，當(dāng)緩存值大于等于最大值表示動態(tài)資格校驗不通過。
動態(tài)資格扣減使用緩存的 incrBy 進(jìn)行累加，這塊需要針對每個累加后進(jìn)行判斷來減少跟緩存的交互，并且需要把已經(jīng)累加的數(shù)據(jù)進(jìn)行記錄，提供回滾資格使用。
以上是針對營銷系統(tǒng)的資格設(shè)計的一個設(shè)計思路和相關(guān)實踐的簡單案例，在具體設(shè)計中需要考慮的問題比案例中的更加復(fù)雜。比如：用戶資格不滿足原因的輸出、異步動態(tài)資格數(shù)據(jù)入庫處理、動態(tài)資格校驗返回所有不滿足原因等等。這些就需要進(jìn)行相關(guān)的擴(kuò)展和針對目前公司的基礎(chǔ)配套設(shè)施的情況進(jìn)行選擇設(shè)計。
總結(jié)
以上是生活随笔為你收集整理的规则引擎：大厂营销系统资格设计全解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Golang 规则引擎原理及实战
- 下一篇： GitHub for Windows使用