营销系统资格设计
前言：業務進行營銷活動目的是用最少的錢實現更好的營銷效果，此時就需要針對營銷活動的資格進行控制，其中就包括了用戶身份、用戶所處的環境等等一系列因素的考慮，且為了防止惡意套取營銷費用和做到營銷效果的持續性，會進行活動相關次數的控制。此時為了適應業務不斷變革的營銷活動資格，好的資格設計就非常重要。
營銷活動業務在配置中會同一時間存在多個營銷活動，用戶進入某個場景，首先需要給用戶展示目前用戶能夠享受的營銷活動，增加用戶參與此場景的意向，然后用戶參與場景后需要給用戶提示對應的營銷活動，用戶如果沒有參與成功需要給用戶提示具體沒有參與成功的原因。那么在參與前，具體的場景中需要進行用戶資格的校驗，并且用戶參與后需要進行資格記錄。
?
同時，資格校驗能夠有效防止用戶重復參與的問題，通過配置用戶的次數資格來進行校驗，用戶參與成功一次進行記錄，后面用戶參與前對次數資格進行相關的校驗。
?
資格分類??
資格設計先要針對資格進行分類，通過不同的分類進行各自分類領域模塊設計。分類的原則是分層漏斗分類：優先過濾大量不滿足、消耗服務器資源較少的活動，再過濾需要消耗服務器資源較多的活動，最后是進行風控資格校驗。按照這個分類原則后面可能會出現多個營銷活動，這個是另外一個話題—營銷推薦設計。
以上是目前蘇寧金融這邊針對資格設計的分類：靜態資格、動態資格和風控資格。此處風控資格校驗作為獨立的一個分類并且放在最后，主要是由兩個方面考慮：（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進行累加，這塊需要針對每個累加后進行判斷來減少跟緩存的交互，并且需要把已經累加的數據進行記錄，提供回滾資格使用。
?
以上是針對營銷系統的資格設計的一個設計思路和相關實踐的簡單案例，在具體設計中需要考慮的問題比案例中的更加復雜。比如：用戶資格不滿足原因的輸出、異步動態資格數據入庫處理、動態資格校驗返回所有不滿足原因等等。這些就需要進行相關的擴展和針對目前公司的基礎配套設施的情況進行選擇設計。
總結
- 上一篇： 向量时钟Vector Clock in
- 下一篇： 2PC到3PC到Paxos到Raft到I