業(yè)務進行營銷活動目的是用最少的錢實現更好的營銷效果，此時就需要針對營銷活動的資格進行控制，其中就包括了用戶身份、用戶所處的環(huán)境等等一系列因素的考慮，且為了防止惡意套取營銷費用和做到營銷效果的持續(xù)性，會進行活動相關次數的控制。此時為了適應業(yè)務不斷變革的營銷活動資格，好的資格設計就非常重要。

營銷活動業(yè)務在配置中會同一時間存在多個營銷活動，用戶進入某個場景，首先需要給用戶展示目前用戶能夠享受的營銷活動，增加用戶參與此場景的意向，然后用戶參與場景后需要給用戶提示對應的營銷活動，用戶如果沒有參與成功需要給用戶提示具體沒有參與成功的原因。那么在參與前，具體的場景中需要進行用戶資格的校驗，并且用戶參與后需要進行資格記錄。

同時，資格校驗能夠有效防止用戶重復參與的問題，通過配置用戶的次數資格來進行校驗，用戶參與成功一次進行記錄，后面用戶參與前對次數資格進行相關的校驗。

資格分類

資格設計先要針對資格進行分類，通過不同的分類進行各自分類領域模塊設計。分類的原則是分層漏斗分類：優(yōu)先過濾大量不滿足、消耗服務器資源較少的活動，再過濾需要消耗服務器資源較多的活動，最后是進行風控資格校驗。按照這個分類原則后面可能會出現多個營銷活動，這個是另外一個話題—營銷推薦設計。

以上是目前蘇寧金融這邊針對資格設計的分類：靜態(tài)資格、動態(tài)資格和風控資格。此處風控資格校驗作為獨立的一個分類并且放在最后，主要是由兩個方面考慮：（1）風控的內容很多，在蘇寧金融有專門的風控中心來進行風控規(guī)則的制定和執(zhí)行；（2）風控返回的風控級別也有很多，營銷活動的不同、觸發(fā)風控的級別不同，對應的營銷活動處理邏輯也不一樣。

下面針對以上的分類的靜態(tài)資格和動態(tài)資格進行相關的領域模塊具體設計探討。

靜態(tài)資格

靜態(tài)資格在蘇寧金融營銷中的定義是：用戶進入具體場景、當時用戶屬性標簽的一個靜態(tài)數據。

靜態(tài)數據的獲取方面主要通過兩個部分獲取：（1）上游系統(tǒng)的傳遞，這個數據主要是獲取用戶所處的場景數據，包括但不限于：用戶當前進行的業(yè)務及業(yè)務數據、用戶使用終端、網絡環(huán)境等等數據。（2）用戶屬性標簽的大數據獲取。在蘇寧金融大數據中心有一套完整的用戶實時標簽庫，用戶請求后通過次標簽庫實時查詢用戶目前的標簽。

靜態(tài)數據的過濾在技術方案中適合采用規(guī)則引擎進行相關資格校驗。目前在蘇寧金融的營銷系統(tǒng)中使用 Drools，主要是考慮以下幾個方面：

（1） 業(yè)務規(guī)則較多，如果使用編碼方式新增規(guī)則就需要進行相關的編碼，增加代碼量和維護成本。

（2） Drools 的自定義關系操作符：通過自定義關系操作符可以針對不同的業(yè)務規(guī)則配置需要的操作符還可以針對每個活動不能匹配的原因進行內部埋點記錄，方便運營進行客訴查詢。

（3） 純 java 實現，學習成本低。

業(yè)務配置生成 drl 文件設計

關于生成 drl 文件的設計，先來看看 drools 引擎原理：

Drools 引擎通過每個條件進行匹配，最終匹配出相關的活動，所以在設計中需要考慮最終返回的數據是活動集合。

Drl 文件組成：

通過原理及文件組成，設計 Drl 文件生成的類圖如下：

writeRuleFile 是入口，通過入口進行內部方法組裝，此方法需要功能是組裝文件內容和寫文件；writeDrlHead 方法為寫文件頭部包、引用和全局變量定義；assembleEvaluatorDefinition 方法是組裝自定義操作符規(guī)則；getActRuleWhenCondition 此方法為拼接規(guī)則字符串；writeActivityRule 此方法為活動的規(guī)則寫入。

以上是一種純 java 代碼實現 Drl 文件生成的一個方式，目的是為了讓大家能夠理解 Drl 文件的結構。實際操作過程中也可以通過 freemarker 模版來生成對應的 Drl 文件。

Drools 規(guī)則加載

此處規(guī)則加載設計可以設計為內置定時器掃描規(guī)則生成表是否有新增記錄或者采用分布式集群通知的方式進行加載。

目前，蘇寧內部的統(tǒng)一配置平臺采用的是自研的 SCM 平臺，能夠很好地支持實時修改，應用服務器集群每臺應用監(jiān)聽具體某個配置文件的內容變更。

應用服務器監(jiān)聽到需要進行 Drl 文件 加載后，通過拉取 Drl 文件，并讀取其中的內容生成對應的 KieBase。

靜態(tài)資格匹配

為了更加通用性在設計中可以設置規(guī)則匹配的入參為 Map 形式，在進行匹配前需要把靜態(tài)資格數據轉化為 Map 數據格式，然后在生成的 KieBase 中獲取 KieSession，通過此 KieSession 進行規(guī)則匹配。

KieSession 需要設置全局的一個集合，來返回匹配到相關活動編碼數據，同時需要考慮活動是有狀態(tài)和有效期的，所以在拿到靜態(tài)數據匹配的活動編碼后，需要對活動的狀態(tài)進行篩選，拿到的是生效且在有效期范圍內的活動。

動態(tài)資格

此處動態(tài)資格主要是指活動的次數和用戶次數。營銷活動為了能夠使更多的用戶能夠參與，防止某些用戶的重復參與，會對用戶的每日、每月、總參與次數進行限制，同時活動的經費是有限的，為了能夠使營銷活動效果做的更好，也會對活動的每日、每月、總次數進行限制。

動態(tài)資格設計可以分為兩個維度，一個是對象，一個是周期：

通過上圖設計，周期維度確認好后變更的可能性比較小，可以在前期調研階段確認好周期范圍。不過，對象變更相比較周期而言會更頻繁，前期系統(tǒng)上線的時候確認一個自然人可能只有帳號、綁定手機兩個屬性，后期通過系統(tǒng)的不斷迭代及技術的不斷進步這個屬性可能會進行擴容。所以，在進行架構設計的時候需要考慮具體對象的擴展性。同時，為了高并發(fā)的查詢、次數的扣減或者回滾，可以通過緩存來代替數據庫的記錄和操作，當然為了保證數據的可恢復性，可以設計實時緩存，異步落庫的操作。

動態(tài)資格組裝

資格組裝按照分析，采用抽象類封裝內部實現，每個對象通過繼承抽象類，實現具體的抽象方法的方式來實現。

抽象類 AbstractDimensionDynamic 中有兩個抽象方法獲取對象 targetType 和獲取對象值 targetValue 是在具體類中進行實現。dynamicAssemble 方法是進行 dynamicKey 的拼接并組裝動態(tài)資格的具體對象，最終得到動態(tài)資格對象的集合。

AbstractDimensionDynamic 的子類是具體的動態(tài)資格對象，每增加一個對象，通過增加子類的方式來實現。

動態(tài)資格服務

此處設計中 DynamicService 對外提供的是動態(tài)資格校驗和動態(tài)資格扣減兩個服務，在實際過程中還會存在回退的服務，這個需要自行進行擴展。

抽象類 AbstractDynamicService 中的 dimensionDynamics 是一個 List，并且注解為 @Autowired，Spring 會自動從容器中取出 DimesionDynamic 的實現類裝配到 List 類型的 dimensionDynamics 中，從而簡化了依賴注入的過程，并且有新增實現類的時候系統(tǒng)啟動會自動注入。

@Autowiredprivate List<DimensionDynamic> dimensionDynamics; @Resourceprivate RedisService redisService;

復制代碼

其中的 assembleDynamicRecordList 方法是通過遍歷 dimensionDynamics，組裝需要的查詢或者扣減的動態(tài)數據記錄；rollback 方法是扣減出現異常或者扣減超過限制后進行回滾使用的操作，此方法需要拋出異常，供上游判斷是否需要進行處理。

緩存使用 Redis，主要是考慮在 redis 中的 incrBy 和 decrBy 都是原子性操作，這個在高并發(fā)的場景中防止由于并發(fā)導致的累計錯誤問題。而且 redis 的 mget 命令可以批量查詢，主要是由于 redis 使用基于 RESP 協議的 rpc 接口，而 redis 本身的數據結構非常高效，所以 IO 和協議解析是個不容忽略的資源消耗。通過 mget 將多個 get 請求匯聚成一條命令，可以大大降低網絡、rpc 協議解析的開銷，從而大幅提升緩存效率。

DynamicServiceImpl 是 DynamicService 的具體實現，并且要繼承 AbstractDynamicService 抽象類。需要實現 dynamicChack 動態(tài)資格校驗和 dynamicDeduction 動態(tài)資格扣減方法。

動態(tài)資格校驗是通過組裝的動態(tài)記錄數據集，到緩存中查詢目前存儲的值跟對應動態(tài)資格最大值進行比較，當緩存值大于等于最大值表示動態(tài)資格校驗不通過。

動態(tài)資格扣減使用緩存的 incrBy 進行累加，這塊需要針對每個累加后進行判斷來減少跟緩存的交互，并且需要把已經累加的數據進行記錄，提供回滾資格使用。

以上是針對營銷系統(tǒng)的資格設計的一個設計思路和相關實踐的簡單案例，在具體設計中需要考慮的問題比案例中的更加復雜。比如：用戶資格不滿足原因的輸出、異步動態(tài)資格數據入庫處理、動態(tài)資格校驗返回所有不滿足原因等等。這些就需要進行相關的擴展和針對目前公司的基礎配套設施的情況進行選擇設計。

總結

以上是生活随笔為你收集整理的规则引擎：大厂营销系统资格设计全解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。