规则引擎调研报告
背景
我們公司由于業務的極具擴大，每天經過系統的金額也達到了20億美金左右，這個時候對資金的管控就不能像以前那樣分散在不同的系統，由不同的部門負責了。所以說，我們成立了風控部門，必須成立了專門的研發團隊負責風控需求，要開始做風控了。我受命去調研如何做風控。發現風控平臺一般都需要一個叫規則引擎的東西，那么我就去調研了規則引擎的一些現狀。
目前公司內部規則執行現狀
if(f1){if(a||b||c||d) } if(f2){ } if(a&b&d){ }- 優點
當規則較少、變動不頻繁時，開發效率非常高。
穩定性較佳：語法級別錯誤不會出現，由編譯系統保證。
沒有外部依賴，執行速度很快 - 缺點
規則迭代成本高：對規則的少量改動就需要走全流程（排期，開發、測試、部署）。
當存量規則較多時，可維護性差。
規則開發和維護門檻高：規則對業務分析人員不可見
沒有規則效果分析，很難感知規則的效果
規則引擎簡介
規則引擎由推理引擎發展而來，是一種嵌入在應用程序中的組件，實現了將業務決策從應用程序代碼中分離出來，并使用預定義的語義模塊編寫業務決策。接受數據輸入，解釋業務規則，并根據業務規則做出業務決策。–來自百度百科
這個定義我感覺比較清晰了，但是我們做的不一定要有推理模塊。如果只是互聯網化的簡單規則執行，其實不需要推理，也能做到非常高的性能。
為啥要用規則引擎
- 規則的變更非常方便，從而實現業務規則的隨需應便。
- 業務規則與系統代碼分離，實現業務規則的集中管理。
- 在不重啟服務的情況下可隨時對業務規則進行擴展和維護。
- 可以動態修改業務規則，從而快速響應需求變更，大大提高了對復雜邏輯代碼的可維護性。
- 規則引擎是相對獨立的，只關心業務規則，使得業務分析人員也可以參與編輯、維護系統的業務規則。
- 減少了硬編碼業務規則的成本和風險。
- 使用規則引擎提供的規則編輯工具，使復雜的業務規則實現變得簡單。
規則引擎的作用
- 流程控制
- 數據校驗
規則引擎的分類實現
規則引擎在系統中根據事中，事后可以的實現方式
- 事中：驗證系統流程產生的入參和返回值是否符合規則要求；
- 事后：通過大數據技術棧，對多個數據源進行比對，進行數據審計；
事中規則實現
- 規則引擎關注的是時延，不能進行跨進程調用問題，盡量不訪問數據庫和外部內存，直接使用機器內存
- 規則較多，盡量使用并行執行，不如有依賴，可以分析依賴樹，然后并行執行
事后規則實現
規則引擎有哪些功能
- 規則配置-可視化
- 腳本語言編寫規則
- 規則優先級執行
- 可視化規則流
- 版本發布，回滾
- 灰度發布
- 評分卡
- 決策表
- 決策樹
- 黑白灰名單
- 標簽管理
- 可視化決策流編輯
- 規則監控
- 用戶權限管理
- AB測試
- 冠軍挑戰
- 規則效果分析
- 本地化(和業務系統在一個進程中)和服務化(單獨部署)
核心挑戰
- 規則的易變性 規則頻繁變動，硬編碼死板問題和動態加載的性能問題，如何快速的下發規則
- 規則的定制化 因為用戶畫像不同導致千人千面的策略，有一定的定制特點
- 時延要求低 幾乎每個核心業務動作都會調用風控接口，如何保證業務的無感
未來趨勢
- 更高階的風控決策引擎，在現有的風控決策引擎上融入了自言語言處理平臺、流計算平臺、實時預警、深度學習、可視化科學計算等，提升了現有決策引擎的算力和處理時效。
- 隨著技術的革新，未來的決策引擎，會向著功能更加豐富，性能更加優良，決策更加智能的風控智能實時規則系統演進
應用場景
對于一些存在比較復雜得業務規則并且業務規則會頻繁變動的系統比較適合使用規則引擎
- 風險控制系統----風險貸款、風險評估
- 反欺詐項目----銀行貸款、征信驗證
- 決策平臺系統----財務計算
- 促銷平臺系統----滿減、打折、加價購 等等
典型場景-信用卡授信
規則引擎調研
- JBoss Drools
- Mandarax
- OpenRules
- JEOPS
- InfoSapient
- Roolie
- Apache Camel
- ODM(ILOG)
- Oracle Business Rules
- 旗正規則引擎
- Jess（可研究，商用收費）
- TopRules
- 明策智能決策
- Blaze
- 益博睿決策引擎
ILOG調研
ilog是一套功能完備的規則引擎，支持普通規則、決策表、決策樹、評分卡、規則流，可以以自然語言的方式編寫規則，同時在版本管理上提供基線、規則集管理的功能，核心引擎采用智能專家推理算法，能夠高效的執行規則匹配。
ILOG流程演示
- 定義規則
- 定義決策表
- 定義規則流
- 部署多版本支持
- 測試執行結果
- 統計執行結果
ILOG優勢和劣勢
優點
- 有規則的自然語言
- 快速的執行速度
- 支持普通規則、決策表、決策樹、評分卡、規則流
- 具有版本管理功能
- 具有規則集管理功能
- 比較成熟，產品周期較長，客戶較多
缺點
- 網上資料很少，出了問題很難獨立維護
- 需要支付大量的安裝和部署費用，而且有長期的維護費用
- 比較成熟的方案都是商業軟件，例如F5,webspere,Oracle等
- 安裝包非常大，幾G數據，只支持windows安裝，windows開發部署規則等
- 不支持聚合類策略，一般是在外面服務處理好，ODM支持，但是沒有用過
- 規則沒有擴容方案，只能單庫
- ILOG是商業版本，沒有支持開源框架，也沒有微服務化，很難和公司現有的spring-cloud相融合
- 由于不能和公司現有的spring-cloud相融合，就不能調用公司體系的服務作為判斷因子
- 黑白灰名單，這些數據的訪問必須前置一個規則系統
Drools
Drools 是用 Java 語言編寫的開放源碼規則引擎，使用 Rete 算法對所編寫的規則求值。Drools 允許使用聲明方式表達業務邏輯。可以使用非 XML 的本地語言編寫規則，從而便于學習和理解。并且，還可以將 Java 代碼直接嵌入到規則文件中，這令 Drools 的學習更加吸引人。
優點
- 非常活躍的社區支持
- 易用
- 快速的執行速度
- 在 Java 開發人員中流行
- 與 Java Rule Engine API（JSR 94）兼容
缺點
- 業務分析師無法獨立完成規則配置：由于規則主體DSL是編程語言（支持Java, Groovy, Python），因此仍然需要開發工程師維護
- 規則規模變大以后也會變得不好維護，相對硬編碼的優勢便不復存在
- 規則的語法僅適合扁平的規則，對于嵌套條件語義（then里嵌套when…then子句）的規則只能將條件進行笛卡爾積組合以后進行配置，不利于維護
整體設計
代碼示例
URule
URule是一款純Java規則引擎，它以RETE算法為基礎，提供了向導式規則集、腳本式規則集、決策表、交叉決策表(PRO版提供)、決策樹、評分卡及決策流共六種類型的規則定義方式，配合基于WEB的設計器，可快速實現規則的定義、維護與發布。
URule提供了兩個版本：一個是基于Apache-2.0協議開源免費版本，URule開源版本第一款基于Apache-2.0協議開源的中式規則引擎；另一個是商用PRO版本。
整體設計
功能設計
開源和商業版本比較
基于Aviator的表達式
Aviator 的基本過程是將表達式直接翻譯成對應的 java 字節碼執行，整個過程最多掃兩趟（開啟執行優先模式，如果是編譯優先模式下就一趟），這樣就保證了它的性能超越絕大部分解釋性的表達式引擎，測試也證明如此；其次，除了依賴 commons-beanutils 這個庫之外（用于做反射）不依賴任何第三方庫，因此整體非常輕量級，整個 jar 包大小哪怕發展到現在 5.0 這個大版本，也才 430K。同時， Aviator 內置的函數庫非常“節制”，除了必須的字符串處理、數學函數和集合處理之外，類似文件 IO、網絡等等你都是沒法使用的，這樣能保證運行期的安全，如果你需要這些高階能力，可以通過開放的自定義函數來接入
特點
- 高性能
- 輕量級
- 一些比較有特色的特點：
- 開放能力：包括自定義函數接入以及各種定制選項
一期時間人員規劃
一期功能-2.5個月 3個后端
- 規則配置由研發來完成
- 策略執行根據業務調用動態執行
- 引入事件，場景，規則，因子概念
- 規則在場景中按照優先級執行，暫時不支持分支判斷
- 規則支持版本發布
- 不支持決策表，評分卡等
- 支持簡單聚合規則
- 支持黑白名單，不支持灰名單
自研規劃
結論
基于Aviator自研，隨著業務一起迭代。2個月左右可以上線第一版，設計出整體的模型框架，支持普通的規則和規則集執行，可以滿足業務需要。
總結
- 上一篇： 如何实现shardSDK分享以及自定义图
- 下一篇： 民营医院不做竞价,做啥能带业绩