總體介紹
業務進行營銷活動目的是用最少的錢實現更好的營銷效果，此時就需要針對營銷活動的資格進行控制，其中就包括了用戶身份、用戶所處的環境等等一系列因素的考慮，且爲了防止惡意套取營銷費用和做到營銷效果的持續性，會進行活動相關次數的控制。此時爲了適應業務不斷變革的營銷活動資格，好的資格設計就非常重要。
營銷活動業務在配置中會同一時間存在多個營銷活動，用戶進入某個場景，首先需要給用戶展示目前用戶能夠享受的營銷活動，增加用戶參與此場景的意向，然後用戶參與場景後需要給用戶提示對應的營銷活動，用戶如果沒有參與成功需要給用戶提示具體沒有參與成功的原因。那麼在參與前，具體的場景中需要進行用戶資格的校驗，並且用戶參與後需要進行資格記錄。
同時，資格校驗能夠有效防止用戶重複參與的問題，通過配置用戶的次數資格來進行校驗，用戶參與成功一次進行記錄，後面用戶參與前對次數資格進行相關的校驗。
資格分類
資格設計先要針對資格進行分類，通過不同的分類進行各自分類領域模塊設計。分類的原則是分層漏斗分類：優先過濾大量不滿足、消耗服務器資源較少的活動，再過濾需要消耗服務器資源較多的活動，最後是進行風控資格校驗。按照這個分類原則後面可能會出現多個營銷活動，這個是另外一個話題—營銷推薦設計。
以上是目前蘇寧金融這邊針對資格設計的分類：靜態資格、動態資格和風控資格。此處風控資格校驗作爲獨立的一個分類並且放在最後，主要是由兩個方面考慮：（1）風控的內容很多，在蘇寧金融有專門的風控中心來進行風控規則的制定和執行；（2）風控返回的風控級別也有很多，營銷活動的不同、觸發風控的級別不同，對應的營銷活動處理邏輯也不一樣。
下面針對以上的分類的靜態資格和動態資格進行相關的領域模塊具體設計探討。
靜態資格
靜態資格在蘇寧金融營銷中的定義是：用戶進入具體場景、當時用戶屬性標籤的一個靜態數據。
靜態數據的獲取方面主要通過兩個部分獲取：（1）上游系統的傳遞，這個數據主要是獲取用戶所處的場景數據，包括但不限於：用戶當前進行的業務及業務數據、用戶使用終端、網絡環境等等數據。（2）用戶屬性標籤的大數據獲取。在蘇寧金融大數據中心有一套完整的用戶實時標籤庫，用戶請求後通過次標籤庫實時查詢用戶目前的標籤。
靜態數據的過濾在技術方案中適合採用規則引擎進行相關資格校驗。目前在蘇寧金融的營銷系統中使用Drools，主要是考慮以下幾個方面：
（1） 業務規則較多，如果使用編碼方式新增規則就需要進行相關的編碼，增加代碼量和維護成本。
（2） Drools的自定義關係操作符：通過自定義關係操作符可以針對不同的業務規則配置需要的操作符還可以針對每個活動不能匹配的原因進行內部埋點記錄，方便運營進行客訴查詢。
（3） 純java實現，學習成本低。
業務配置生成drl文件設計
關於生成drl文件的設計，先來看看drools引擎原理：
Drools引擎通過每個條件進行匹配，最終匹配出相關的活動，所以在設計中需要考慮最終返回的數據是活動集合。
Drl文件組成：
通過原理及文件組成，設計Drl文件生成的類圖如下：
writeRuleFile是入口，通過入口進行內部方法組裝，此方法需要功能是組裝文件內容和寫文件；writeDrlHead方法爲寫文件頭部包、引用和全局變量定義；assembleEvaluatorDefinition方法是組裝自定義操作符規則；getActRuleWhenCondition此方法爲拼接規則字符串；writeActivityRule此方法爲活動的規則寫入。
以上是一種純java代碼實現Drl文件生成的一個方式，目的是爲了讓大家能夠理解Drl文件的結構。實際操作過程中也可以通過freemarker模版來生成對應的Drl文件。
Drools規則加載
此處規則加載設計可以設計爲內置定時器掃描規則生成表是否有新增記錄或者採用分佈式集羣通知的方式進行加載。
目前，蘇寧內部的統一配置平臺採用的是自研的SCM平臺，能夠很好地支持實時修改，應用服務器集羣每臺應用監聽具體某個配置文件的內容變更。
應用服務器監聽到需要進行Drl文件 加載後，通過拉取Drl文件，並讀取其中的內容生成對應的KieBase。
靜態資格匹配
爲了更加通用性在設計中可以設置規則匹配的入參爲Map形式，在進行匹配前需要把靜態資格數據轉化爲Map數據格式，然後在生成的KieBase中獲取KieSession，通過此KieSession進行規則匹配。
KieSession需要設置全局的一個集合，來返回匹配到相關活動編碼數據，同時需要考慮活動是有狀態和有效期的，所以在拿到靜態數據匹配的活動編碼後，需要對活動的狀態進行篩選，拿到的是生效且在有效期範圍內的活動。
動態資格
此處動態資格主要是指活動的次數和用戶次數。營銷活動爲了能夠使更多的用戶能夠參與，防止某些用戶的重複參與，會對用戶的每日、每月、總參與次數進行限制，同時活動的經費是有限的，爲了能夠使營銷活動效果做的更好，也會對活動的每日、每月、總次數進行限制。
動態資格設計可以分爲兩個維度，一個是對象，一個是週期：
通過上圖設計，週期維度確認好後變更的可能性比較小，可以在前期調研階段確認好週期範圍。不過，對象變更相比較週期而言會更頻繁，前期系統上線的時候確認一個自然人可能只有帳號、綁定手機兩個屬性，後期通過系統的不斷迭代及技術的不斷進步這個屬性可能會進行擴容。所以，在進行架構設計的時候需要考慮具體對象的擴展性。同時，爲了高併發的查詢、次數的扣減或者回滾，可以通過緩存來代替數據庫的記錄和操作，當然爲了保證數據的可恢復性，可以設計實時緩存，異步落庫的操作。
動態資格組裝
資格組裝按照分析，採用抽象類封裝內部實現，每個對象通過繼承抽象類，實現具體的抽象方法的方式來實現。
其中，各個基類的設計如下：
|
類名 |
類含義 |
屬性 |
含義 |
|
UserInfoDto |
用戶信息 |
userId |
用戶ID |
|
mobilePhone |
綁定手機 |
||
|
… … |
其他用戶的屬性內容 |
||
|
DynamicConfig |
動態配置 |
activityCode |
活動編碼 |
|
period |
週期 |
||
|
limitType |
限制具體對象 |
||
|
limitNum |
限制動態次數 |
||
|
DynamicRecord |
動態記錄 |
dynamicKey |
動態key |
|
expire |
過期秒 |
||
|
value |
動態增加次數（默認1） |
||
|
maxValue |
限制次數 |
||
|
activityCode |
活動編碼 |
||
|
targetValue |
具體對象值 |
||
|
period |
週期 |
抽象類AbstractDimensionDynamic中有兩個抽象方法獲取對象targetType和獲取對象值targetValue是在具體類中進行實現。dynamicAssemble方法是進行dynamicKey的拼接並組裝動態資格的具體對象，最終得到動態資格對象的集合。
AbstractDimensionDynamic的子類是具體的動態資格對象，每增加一個對象，通過增加子類的方式來實現。
動態資格服務
此處設計中DynamicService對外提供的是動態資格校驗和動態資格扣減兩個服務，在實際過程中還會存在回退的服務，這個需要自行進行擴展。
抽象類AbstractDynamicService中的dimensionDynamics是一個List，並且註解爲@Autowired，Spring會自動從容器中取出DimesionDynamic的實現類裝配到List類型的dimensionDynamics中，從而簡化了依賴注入的過程，並且有新增實現類的時候系統啓動會自動注入。
@Autowired
private List<DimensionDynamic> dimensionDynamics;
@Resource
private RedisService redisService;
其中的assembleDynamicRecordList方法是通過遍歷dimensionDynamics，組裝需要的查詢或者扣減的動態數據記錄；rollback方法是扣減出現異常或者扣減超過限制後進行回滾使用的操作，此方法需要拋出異常，供上游判斷是否需要進行處理。
緩存使用Redis，主要是考慮在redis中的incrBy和decrBy都是原子性操作，這個在高併發的場景中防止由於併發導致的累計錯誤問題。而且redis的mget命令可以批量查詢，主要是由於redis使用基於RESP協議的rpc接口，而redis本身的數據結構非常高效，所以IO和協議解析是個不容忽略的資源消耗。通過mget將多個get請求匯聚成一條命令，可以大大降低網絡、rpc協議解析的開銷，從而大幅提升緩存效率。
DynamicServiceImpl是DynamicService的具體實現，並且要繼承AbstractDynamicService抽象類。需要實現dynamicChack動態資格校驗和dynamicDeduction動態資格扣減方法。
動態資格校驗是通過組裝的動態記錄數據集，到緩存中查詢目前存儲的值跟對應動態資格最大值進行比較，當緩存值大於等於最大值表示動態資格校驗不通過。
動態資格扣減使用緩存的incrBy進行累加，這塊需要針對每個累加後進行判斷來減少跟緩存的交互，並且需要把已經累加的數據進行記錄，提供回滾資格使用。
以上是針對營銷系統的資格設計的一個設計思路和相關實踐的簡單案例，在具體設計中需要考慮的問題比案例中的更加複雜。比如：用戶資格不滿足原因的輸出、異步動態資格數據入庫處理、動態資格校驗返回所有不滿足原因等等。這些就需要進行相關的擴展和針對目前公司的基礎配套設施的情況進行選擇設計。
作者介紹 ：
王海民，蘇寧金融研發中心高級技術經理，主要負責蘇寧金融會員及互聯網研發中心的營銷部門工作。具有營銷、電商、支付、金融等相關領域 10 年以上工作經歷；擅長互聯網產品服務端應用技術架構。
小廣告：17年及之前畢業的Java後端，可內推直聘拼多多，簡歷郵箱：[email protected]
=>更多文章請參考：《中國互聯網業務研發體系架構指南》
https://blog.csdn.net/Ture010Love/article/details/104381157
=>更多行業權威架構案例、領域標準及技術趨勢請關注微信公衆號 '軟件真理與光'：
