背景
隨著金融環(huán)境的劇烈變化及人們悄然轉(zhuǎn)變的消費習(xí)慣，金融行業(yè)的業(yè)務(wù)變化愈加頻繁和劇烈。尤其是風(fēng)控和反欺詐場景，涉及規(guī)則成百上千。
這類經(jīng)常變更的業(yè)務(wù)規(guī)則讓公司開發(fā)人員和運營人員都非常頭疼。按照產(chǎn)品開發(fā)的傳統(tǒng)方式，通常是在程序代碼或配置文件中不斷添加邏輯判斷，來實現(xiàn)業(yè)務(wù)規(guī)則。但這種方式、會出現(xiàn)如下弊端：（1）增加開發(fā)人員與測試人員的工作量。（2）部門間需要更加頻繁地進(jìn)行業(yè)務(wù)溝通，時間成本增加。（3）增加用人成本，造成公司損失。如何解決這些弊端成了技術(shù)部門的重要任務(wù)之一。規(guī)則引擎的出現(xiàn)完美地解決了這個問題。
如何通過規(guī)則引擎解決上述問題呢？
將復(fù)雜且多變的業(yè)務(wù)規(guī)則從硬編碼中解放出來，以規(guī)則腳本的形式存放在文件或特定的存儲介質(zhì)中（這里可以是數(shù)據(jù)庫表），使得業(yè)務(wù)規(guī)則的變更不需要修正項目代碼、重啟服務(wù)器就可以在線上環(huán)境立即生效。這樣就將業(yè)務(wù)決策從程序代碼中分離出來，使其代碼與業(yè)務(wù)解耦。通過特定的語法內(nèi)容編寫業(yè)務(wù)模塊，由API進(jìn)行解析并對外提供執(zhí)行接口，再接收輸入數(shù)據(jù)、進(jìn)行業(yè)務(wù)邏輯處理并返回執(zhí)行結(jié)果。而我們選擇用的規(guī)則引擎就是Drools
為什么選用Drools？
Drools與其他規(guī)則引擎對比：
圖一：Drools對比圖
由圖一對比得出Drools與相對于其他規(guī)則框架有以下優(yōu)勢：
1. 非?；钴S的社區(qū)支持（JBoss支持）；
2. 快速的執(zhí)行速度；
3. 完善的功能；
4. 國外金融領(lǐng)域使用比較多；
什么是Drools？
Drools是為Java量身定制的基于Charles Forgy的RETE（RETE的詳細(xì)介紹：https://blog.csdn.net/sdmxdzb/article/details/81461744）算法的規(guī)則引擎的實現(xiàn)。具有了OO接口的RETE,使得商業(yè)規(guī)則有了更自然的表達(dá)。
Rule是什么呢？
一條規(guī)則是對商業(yè)知識的編碼。一條規(guī)則有 attributes ，一個 Left Hand Side （ LHS ）和一個 Right Hand Side （ RHS ）。Drools 允許下列幾種 attributes ：salience ， agenda-group ， no-loop ， auto-focus ， duration ， activation-group 。
規(guī)則的 LHS 由一個或多個條件（ Conditions ）組成。當(dāng)所有的條件（ Conditions ）都滿足并為真時， RHS 將被執(zhí)行。RHS 被稱為結(jié)果（ Consequence ）。LHS 和 RHS 類似于
if（<LHS>){
<RHS>
}
下面介紹幾個術(shù)語：
對新的數(shù)據(jù)和被修改的數(shù)據(jù)進(jìn)行規(guī)則的匹配稱為模式匹配（ Pattern Matching ）。進(jìn)行匹配的引擎稱為推理機(jī)（ Inference Engine ）。被訪問的規(guī)則稱為 ProductionMemory ，被推理機(jī)進(jìn)行匹配的數(shù)據(jù)稱為 WorkingMemory 。Agenda 管理被匹配規(guī)則的執(zhí)行。推理機(jī)所采用的模式匹配算法有下列幾種：Linear ， RETE ， Treat ， Leaps 。這里注意加紅的地方，對數(shù)據(jù)的修改也會觸發(fā)重新匹配，即對 WorkingMemory中的數(shù)據(jù)進(jìn)行了修改。
然后規(guī)則引擎大概是這個樣子的：
這個圖也很好理解，就是推理機(jī)拿到數(shù)據(jù)和規(guī)則后，進(jìn)行匹配，然后把匹配的規(guī)則和數(shù)據(jù)傳遞給Agenda。
規(guī)則引擎實現(xiàn)了數(shù)據(jù)同邏輯的完全解耦。規(guī)則并不能被直接調(diào)用，因為它們不是方法或函數(shù)，規(guī)則的激發(fā)是對 WorkingMemory 中數(shù)據(jù)變化的響應(yīng)。結(jié)果（ Consequence ，即 RHS ）作為 LHS events 完全匹配的 Listener 。
數(shù)據(jù)被 assert 進(jìn) WorkingMemory 后，和 RuleBase 中的 rule 進(jìn)行匹配（確切的說應(yīng)該是 rule 的 LHS ），如果匹配成功這條 rule 連同和它匹配的數(shù)據(jù)（此時就叫做 Activation ）一起被放入 Agenda ，等待 Agenda 來負(fù)責(zé)安排激發(fā) Activation （其實就是執(zhí)行 rule 的 RHS ），上圖中的菱形部分就是在 Agenda 中來執(zhí)行的， Agenda 就會根據(jù)沖突解決策略來安排 Activation 的執(zhí)行順序。
下面附上drools規(guī)則引擎的執(zhí)行過程:
反欺詐平臺規(guī)則引擎使用案例
由某行反欺詐平臺執(zhí)行過程為例：
圖二：某銀行反欺詐平臺數(shù)據(jù)架構(gòu)
如圖二以監(jiān)管部門發(fā)布的【146號文】中關(guān)于基于大基數(shù)技術(shù)的風(fēng)險防控、ⅡⅢ類銀行賬戶管理相關(guān)監(jiān)管考核內(nèi)容數(shù)據(jù)流向為例,數(shù)據(jù)源獲取從三個方向獲?。?.行內(nèi)數(shù)據(jù)（例如用戶交易數(shù)據(jù)）推送到Kafka中，利用Flink實時消費Kafka中的數(shù)據(jù)，將清洗過后的數(shù)據(jù)通過Flink對數(shù)據(jù)進(jìn)行處理后保存到Redis；2.我們以行內(nèi)外數(shù)據(jù)為數(shù)據(jù)源，接入黑白名單列表，保存到ElasticSearc;3.通過欺詐交易組合查詢接口獲取其他數(shù)據(jù)。然后由銀行全渠道交易調(diào)用風(fēng)險查詢接口在不降低客戶體驗滿意度的前提下實現(xiàn)對交易事前、事中和事后的風(fēng)險偵測、識別、處理，快速、動態(tài)和全面控制電子銀行業(yè)務(wù)風(fēng)險，推動銀行業(yè)務(wù)快速、健康、安全地發(fā)展。
結(jié)束語
數(shù)據(jù)解決方案部已經(jīng)在部分銀行將規(guī)則引擎應(yīng)用到風(fēng)控，反欺詐等多個業(yè)務(wù)場景。規(guī)則引擎的運用，不僅簡化了系統(tǒng)的復(fù)雜度，而且提高了系統(tǒng)的可維護(hù)性；同時相對獨立的開發(fā)模式，使得開發(fā)人員只需關(guān)注業(yè)務(wù)邏輯，靈活應(yīng)對業(yè)務(wù)需求的變動，節(jié)約了項目成本，避免服務(wù)停機(jī)重啟。未來還會有更多業(yè)務(wù)與規(guī)則解耦的運用場景，Drools將會成為主流的解決方案
聯(lián)系客服
