最近在某些机缘下认识了规则引擎,以华文介绍规则引擎的文章好像不多,这边试着粗浅的记下我对规则引擎的认识。
在程序的世界,规则引擎通常以套件的方式存在,在系统内藉由规引擎套件的引入,可以利用规则引擎提供的特定方法来定义一系列的商业逻辑,包括每个商业逻辑被触发的条件,以及被触发後的行为。
一个最典型的例子:评分机制,九十分以上的为甲级,享有某些特殊优惠;七十至九十分的为乙级,享有略低於甲级的优惠;七十分以下的为丙级,不享有优惠。生活中常见的会员分级、银行的信用评分都是类似的评分机制的实际应用。
上面的例子看起来好像用原生的 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,而是再加上一些人机介面辅助等等的周边元件包装成完整的产品。
<<: [Bonus 系列] - 使用 useCallback & useMemo 的正确时机是什麽?
前言 除了在Day6上面写的功能,发现合约还有很多东西可以玩。 概况 登入後,直接使用api.Con...
“我们做专题报导,深入报导,比别人花更多时间去找资料,查证。 做那麽爽还不是三分钟就被别的新闻台抄去...
在phpmyadmin介面修改密码 点选Edit privileges後点选Change passw...
前言 因工作需求碰到ODOO这套ERP,藉由铁人赛纪录所学与遇到的问题,若有错误也欢迎不吝指出。 O...
强型闯入DenoLand[31] - MongoDB 安装教学 本章会分为两个部分: MongoD...