如何設計一套規則引擎系統

很早以前就想寫一篇關於「規則引擎」的文章，可是一直苦於沒有時間。恰好最近給團隊小夥伴梳理了我設計的引擎的使用和原理，正好藉此機會在此寫下咱們的心得。 「規則引擎」系統通常而言，在風控中使用較多，可是通過調研，咱們發現，其實在業務系統中，對於規則引擎系統的渴求度更大，甚至於，我在脈脈上都看到好幾我的在諮詢業務規則引擎系統應該如何設計和接入。

首先來聊一下痛點。爲何對於規則引擎系統的渴求度這麼大？

缺點

業務條件繁雜

試想一下，或者說正是你所經歷的，在咱們的業務邏輯中，有不少不少不少的業務條件判斷，而這些業務條件的修改每每又較爲頻繁，若是你的項目部署還比較耗時，那麼「開發五分鐘，部署一小時」的場景又會浮現。

業務配置修改頻繁

在咱們的業務中，每每又有許多的業務配置嵌入其中，好比功能開關、白名單、黑名單等。而這些配置，若是你的項目有接入一些業務配置系統還好，若是沒有，那麼又是須要發一波代碼。

業務諮詢

代碼對於咱們的業務方來講是不可見的，遇到一些根本不是問題的問題時，老是會向技術人員諮詢。而你若是瞭解項目還好，可是一旦忘記，又須要去梳理一次業務邏輯。

幸福的家庭老是類似的，不幸的家庭卻各有各的不一樣。處理這些看似不經意的小問題，老是會不經意間打斷咱們的思考。天下苦秦久已。 梳理一下，咱們須要解決的事情至少有3點：

1. 業務規則配置化。規則代碼的編寫，支持拔插和熱更新。
2. 業務配置可視化。業務配置應交由業務方自行處理。
3. 業務諮詢可見性。當業務遇到不清楚的問題時，能夠很是清晰的在某個地方瞭解到緣由所在。

通過調研，咱們發現MVEL手冊表達式很是適合咱們去作這件事情。而支持MVEL表達式的開源規則引擎系統中，咱們認爲easy-rules更貼合咱們的場景，一方面他支持MVEL，另外一方面，他也支持在Java中自定義Rule，另外，他還支持自定義規則引擎。

可是，僅靠easy-rules並不能直接在使用生產環境中，咱們須要針對本身的業務作一些調整，好比須要統一規則、須要統一屬性注入、須要統一返回結構等等。

咱們大體畫了一下咱們業務執行的主要流程。首先須要注意的是，在業務中，確定會有不一樣場景的狀況，所以咱們須要作好場景區隔，咱們不可能將全部的東西都在一個地方去執行。所以我設計的適合有些地方參考了Java I/O這塊的設計思路，有一個EngineProviders負責調度分發到不一樣的場景中。 每一個場景都實現了統一的接口，而這個調度過程也是動態化的，儘量較少咱們開發同窗所須要作的操做。

而在此以前，須要有一個統一的EngineService來統一的去獲取咱們配置的規則，去注入到場景中。同時，也須要把咱們自定義的業務配置來注入到咱們的數據源中。以下圖所示：

這裏就是咱們自定義的一些規則了，由於業務關係，打上了部分馬賽克，不過應該並不妨礙理解這裏所要作的事情。

然而，咱們在實際的業務中，還有不少地方都須要抽象的統一規則，所以，咱們也能夠藉助easy-rules提供的能力來幫助咱們完成這種事情。

固然須要說明的是，還有一些細節沒有補充上去，好比構參builder等，由於是根據咱們業務自定義的，因此即便補充上去參考價值也不大。

最後還有一點，緣由可視化的問題須要解決。其實這個相對而言就很是簡單了，咱們僅須要在阻斷的地方記錄當時的參數，以及阻斷的規則，而後將其可視化，業務方自行查閱便可。

歡迎關注個人公衆號，每週至少一篇比較有深度的原創文章：