最近在某些機緣下認識了規則引擎，以華文介紹規則引擎的文章好像不多，這邊試著粗淺的記下我對規則引擎的認識。
在程式的世界，規則引擎通常以套件的方式存在，在系統內藉由規引擎套件的引入，可以利用規則引擎提供的特定方法來定義一系列的商業邏輯，包括每個商業邏輯被觸發的條件，以及被觸發後的行為。
一個最典型的例子：評分機制，九十分以上的為甲級，享有某些特殊優惠；七十至九十分的為乙級，享有略低於甲級的優惠；七十分以下的為丙級，不享有優惠。生活中常見的會員分級、銀行的信用評分都是類似的評分機制的實際應用。
上面的例子看起來好像用原生的 if / else 或 switch / case 就可以做到同樣的事？然而在某些不同的場景上，用 if / else 是不適合的。
首先是關注的焦點不同，不論是 if / else 或 switch / case，他們的語法都專為判斷程式運作邏輯而設計，並不適合拿來做商業邏輯的判斷，因為商業邏輯的規則往往更複雜；規則引擎的關注焦點就是商業邏輯而非程式邏輯。硬要用 if / else 來做商業邏輯很有可能長出多層巢狀的 if / else，並且在商業邏輯上，隨著規則的複雜化，系統要做的可能不只是單純的判斷，而是推斷，根據一系列的指標數據由系統協助推斷後續的動作，以銀行系統為例，根據客戶的各項指標（年齡、職業、性別、家庭、地區、資產、收入、信用、健康）來推斷他的風險值，並進一步決定他的借貸利率，像這樣的規則引擎的應用被稱為專家系統，專家系統的推斷可以用演算法或是人工智慧的方式實現。
第二點，規則引擎提供更靈活的參數調整方式，在 if / else 裡面的判斷條件都是死的，難以被開發者以外的營運人員變更，或是必須由開發者手動刻出參數調整的程式、介面，而規則引擎在這方面都提供更靈活的調整方法，可能是用讀入特定格式的檔案（csv 或 xls 或 json）來實現規則的設定，並且這些格式同時是人機可讀的，讓營運人員更簡易的自行調控。第二種做法就是由規則引擎提供程式介面，由開發人員實現操作介面給營運人員使用，這當然有一定的複雜度，需要花費心力去讀規則引擎的文件，但以一個商業用系統的長遠來看，用規則引擎來實現應該是可以有更低的長期維運成本。
以上這些系統的共同特色：參數多、規則複雜。
規則引擎在 Java 生態系內是最多的，大概是因為上面的應用大多是大型系統，而大型系統也都是 Java 的世界的緣故吧！不過其實其它語言也都有規則引擎套件，去 PyPI、npm、Crates.io、RubyGems 等站台搜尋 rules engine 應該都會有相對應的套件，不過成熟度、維護程度各異，服用前需要評估。
前面提到過，規則引擎在各語言都有，並且是以第三方套件的形式提供，但以每個規則引擎套件的實做方式來說，有兩大種分別：是否以 Rete 演算法為基礎。
較簡單的規則引擎套件並不以 Rete 演算法實現，而是用作者自己的做法實現，通常這種規則引擎不會具有自行推斷的能力，而只是實現了一層較適合商業邏輯的設定與撰寫的程式介面供我們使用，較好上手功能也較少，較適合簡單的商業場景。
第二種規則引擎套件即以 Rete 演算法為基礎實現，關於 Rete 演算法，可以簡單的理解為用於比對多個事實（條件）與多個規則，並做出最終推斷的一種演算法，這種規則引擎適用於更複雜的場景。
商業化的產品因為是要賣錢錢的，不會只有 rules engine，而是再加上一些人機介面輔助等等的週邊元件包裝成完整的產品。
leonh
iThome鐵人賽
看影片追技術