lua与规则引擎的构思(一)

1. 规则引擎的应用场景
2. 规则引擎项目的结构及运行原理
3. 使用lua作为规则语言的优点与缺点

 

1 规则引擎的应用场景

　　我们知道，一切万物都是在不断发展，当然也包括我们的任何计算机系统，商业规则在不断的改变，而我们也要跟着改变，往往是由业务来驱动系统的改变。这就造成我们非常的被动，商业规则可能是一月一变，甚至于可能是一日一变，而我们的业务系统显然不可能这么跟着如此频率变化。生活中常见的超市打折扣，是否折上折，是否个别商品不进行折扣；又如，在保险行业里，行业公会或者是保监局有一个新的监管要求；又如国家为了防止通货紧缩而进行宽松的货币政策，而放贷的要求明显降低等等。这些要求都是多变的，且是易变的，经常不定时的调整，甚至于还有地区性的差异。

　　企业越来越依赖于信息技术 (IT) 来管理他们的业务，IT 部门需要开发更复杂的应用程序，同时还要适应其所支持的应用程序的快速变更。通常，在这些应用程序内实施公司的业务策略对于传统的软件体系结构而言过于复杂、庞大，变化也过快。

　　如果我们还按照以前的思维对核心业务系统进行调整的话，将导致很多问题：

1. 因此类需求很多，导致，系统经常调整，伤害系统的稳定性，系统的稳定性往往是最重要的
2. 测试难以进行，因此类业务系统往往维度很多，难以在每次改造都进行覆盖率很高的测试，难以进行单元测试
3. 需求难以实现，不管是老的c/c++系统，还是java/c#等新系统，对于业务的描述毕竟与自然语言差异巨大，难以表述，更别指望能对业务进行可视化设计
4. 此类业务控制可能遍布整个项目，从而难以进行代码的迭代优化及升级换代

　　我们随便列举了以上几点，基本上可以说明规则引擎应用的好处。开发人员和架构设计者可以从应用程序传统代码中提取业务逻辑。如果业务策略是硬编码到企业应用程序中的，则更新系统的过程需要专门的编程人员，并且会使系统稳定性面临风险，同时需要花费较长的时间。通过用业务规则将业务逻辑提取到业务应用程序外，IT 用户可以独立于应用程序来进行业务逻辑的开发和运行。完整的BRMS(即业务规则管理系统)实施甚至可以做得更多，并可使业务用户能够在有限依赖于 IT 部门的情况下直接管理业务策略。依赖的程度范围从通过 IT 实施的策略的业务用户进行的有限复查到业务用户完全控制策略的规范、创建、测试和部署。

　　IT 周期由开发和维护此基础结构的时间组成。未使用规则引擎前，IT周期显示与业务周期是不一致的。在规则引擎解决方案中，我们可以把原来业务系统理解为应用程序、业务规则应用；业务规则管理周期和应用程序开发生命周期可以并行发展。业务策略可以按需发展，不会额外增加应用程序开发的负担。每次应用程序得以发展，业务策略实施都会与应用程序保持同步。通过这种分离，业务策略和应用程序体系结构可以异步管理。例如，应用程序开发人员可能工作的周期为半年，在此周期内每六个月将开发出一个新的应用程序版本以应对不断更改的应用程序基础结构（例如，JDK 和 RDBMS 版本）及其他核心业务需求。同时，策略管理人员可能工作周期为一周，在此周期内交付业务策略的新版本以应对不断发展的市场、新客户或不断更改的规则环境。

　　另一方面，业务用户不关注应用程序开发的细节，而是对定义、测试和管理良好定义的决策（实施表示为应用程序内的业务规则的业务策略）感兴趣。因此，他们需要可在总体策略的上下文内简化组织、搜索和编写规则的工具。 开发人员按照自己的速度在自己的环境中工作，业务用户也是如此，这两方面的工作可以轻松进行同步及合并。 最后，IT 和业务用户都需要访问规则执行环境来部署规则。对于开发人员，规则部署是应用程序测试的一部分。对于业务用户，规则部署是规范、验证和将新的或更改的策略投入生产的一部分。

 

示意图(摘自JRule6.6 quickstart)

2 规则引擎项目的结构及运行原理

2.1 规则引擎关键名词

　　任何程序都是算法与数据结构，而规则引擎也不例外。这些商业规则实际上也是程序，那他自然也要关心这些数据结构。规则引擎中关注的数据结构，我们称之为BOM（Business Object Modal），即：商业对象模型；规则引擎中关注的算法就是规则了。

　　现在关注一下规则引擎中关键的几个名词：

• DTO(Data Translate Object，即数据传输对象)
• BOM(Business Object Modal，即商业对象模型)
• Ruleset(规则集)
• Ruleset Execute Flow(规则集执行流)
• Rule Runtime Context 运行时上下文环境
• 决策表
• 决策树

　　

　　

 

2.2 规则引擎的模块

　　我们主要把规则引擎分为接口层、适配层、核心、数据层、规则管理层，下图显示各层次之间的关系

　　当一次请求进入规则引擎时，即DTO，DTO具体的样式，可能是一份xml文档，或者是一段内存，序列化的对象等等；当然，这具体与规则引擎与应用程序的调用方式相关，比如使用http post请求：web service，或者是简单的xml对象模型的，当然也可以将之嵌入应用程序等，此是后话。当DTO经过适配层时，由适配层负责去访问其他的接口，或者是数据库，进行填充数据。为什么需要这个步骤呢？在这里举一个例子，这是一个计算购物折扣率的应用，应用程序过来的DTO中，肯定包含了购物车中的具体信息，包括所购商量的数量及价格，以及会员信息，但是，肯定不包含该会员的历史购买记录，如果这个时候，有这么一条规则，注册至今购买金额超过1W给予9折的优惠，那就得访问DB，统计该会员的注册至今的购买金额，并组成在规则中需要的BOM。

　　规则引擎核心得到BOM之后，将该对象（LUA中的Table)传入运行的上下文环境，然后对规则进行逐条运算，最终得到运算结果的输出BOM，中间可能也得经过适配层并访问DB填充数据成为DTO并返回给应用程序。

3.使用Lua作为规则描述语言的优缺点

　　首先，lua有非常成熟的实现，而且在游戏行业中作为嵌入的脚本的应用也有非常成熟的应用。lua是使用纯C实现的开源项目（当然，如果是java/c#等，也可以用相应的语言实现），可以移植到任何平台，可以与任何项目相结合，并且免费易用。

　　其次，从lua这个语言本身出发，语言简单易懂，甚至可以对业务人员进行简单的培训之后迅速的介入开发，让业务人员自己来写规则脚本。lua的脚本执行效率高，可以保证适应复杂的规则而不影响效率。lua是非面向对象的语言，在适合编写逻辑的同时，保持最简单的语法。如果想实现可视化设计逻辑规则的话，相对于其他脚本语言（如，python、ruby)等，可有一个更简单的实现。与成熟的规则引擎(如JRule)的规则语言相比较，lua更适合程序员使用，工作效率更高，且是文本，易维护。

　　lua作为普通的脚本语言并非为了规则而生，因为如果要实现类似Jrule的中文描述规则将会有难度，并且如果要实现可视化设计逻辑，像设计流程图等等，在实现上要给lua脚本设计一个代码格式，代码标准，以使我们的编辑器实现可视化设计。因此，就我目前的理解而言，lua作为规则描述语言最大的缺点就在于可视化实现，当然也并非不可实现，但真的要费很大的劲。