业务规则和规则引擎

1 规则引擎 Version 1 0 0 作者 Johnny Leon 发布日期 2016 08 08 2 目录 1业务规则 3 1 1什么是业务规则 3 1 2业务规则的例子 3 1 3业务规则的分类 3 1 4业务规则的特性 4 1 5业务规则的要素 4 2规则引擎 5 2 1规则引擎是什么 5 2 2规则引擎的组成 6 2 3规则引擎的推理 6 2 4规则引擎的应用 7 2 5业务规则的提取 9 2 6业务规则的管理 10 3典型案例 10 案例 1 信用卡申请 11 案例 2 企业薪资计算 13 案例 3 保险公司核保理赔 13 案例 4 快递产品报价 14 案例 5 电商促销 14 3 1 业务规则 1 1什么是业务规则 与业务相关的操作规范 管理章程 规章制度 行业标准等 都可以称为业务规则 Business Rules 简称 BR 业务规则描述了业务过程中重要的且值得记录的对象 关系 和活动 其中包括业务操作中的流程 规范与策略 业务规则保证了业务能满足其目标和义 务 业务规则实质上也可以理解为一组条件和在此条件下的操作 是一组准确凝练的语句 用于描述 约束及控制企业的结构 运作和战略 是应用程序中的一段业务逻辑 该业务逻 辑通常由业务人员 企业的管理人员和程序开发人员共同开发和修改 业务规则的理论基础是 设置一个条件集合 当满足这个条件集合时候 触发一个或者 多个动作 以规则形式捕捉策略语句能提供极大的灵活性和良好的适应性 是企业保持竞争优势的 决定性因素 在市场驱动的情况下 系统架构和模型必须对客户 竞争对手 合作伙伴和整 个市场情况的各种变更及时响应 同时将这些变更产生的需求作为业务规则体现到系统中去 业务规则技术的基本思想是将系统处理的业务逻辑从程序代码中抽取出来 将其转变为 简单的业务规则 以结构化的业务规则数据来表示业务行为 采用类自然语言来描述 并集 中存储在规则库中 业务规则由业务人员创建 实时更新和调试 业务规则之问的复杂逻辑 关系由规则引擎处理 业务规则技术改变了传统的 以过程形式处理业务逻辑的方式 1 2业务规则的例子 生活中的一些业务规则可能是 当顾客进入店内 最近的员工须向顾客打招呼说 欢迎来到 当客户兑换超过 200 元的奖券时 柜员须要求查看客户的身份证并复印 当兑换的奖券金额小于 25 元时 无需客户签字 早上第一个进办公室的人需要把饮水机加热按钮打开 找一些数据相关的业务规则 一些例子如下 只有当客户产生第一个订单时才创建该客户的记录 若一名学生没有选任何一门课程 把他的状态字段设为空 若销售员在一个月中卖出 10 套沙发 奖励 500 元 一个收件人必须至少有 1 个电话号码和 1 个收货地址 若一个订单的除税总额超过 1000 元则能有 5 的折扣 若一个订单的除税总额超过 500 元则免运费 员工购买本公司商品能有 5 的折扣 若仓库中某货品的存量低于上月卖出的总量时 则需要进货 1 3业务规则的分类 4 业务规则主要分为五类 第六类规则是术语 即专门定义的 对业务很重要的词 短语 或缩略词汇 通常在术语表中定义术语 1 事实 fact 通常是对业务的真实陈述 常常与重要的业务术语关联 事实也称为 不变量 关于数据实体及其属性的不可改变的真实情况 2 约束 constraint 约束限制了系统或它的用户可以执行哪些操作 例如 图书馆 的借阅者最多可以同时借 10 本书 3 动作触发规则 action enabler 在特定条件下触发某个动作的规则被称为动作触发规 则 例如 如果某瓶化学药品到了失效日期 则通知其当前持有人 4 推论 inference 推论是根据某个条件的真实性得出某些新事实的规则 通常用 如 果 则 的句式来表达 例如 如果到期 30 天后还没有偿还应付款 则该帐户是在拖 欠债务 5 计算 computation 使用特定的数学公式或算法进行的计算业务规则 例如 订 单的数量为 6 件 10 件 则单价降低 10 数量为 11 件 20 件 单价降低 20 1 4业务规则的特性 1 原子性 业务规则不可再分 每条规则只定义一种判断和操作 复杂的业务逻辑由多条 规则协同处理 2 独立性 业务规则彼此之问独立 复杂的逻辑关系由规则引擎来处理 业务规则存储在 规则库中 独立于数据和程序 3 简单性 业务规则用简单直接的类自然语言来描述 很容易被业务人员和技术人员所理 解 4 动态性 业务人员可以实时地修改业务规则 快捷地更新系统 低成本地维 护系统 5 逻辑性 业务规则至少包含条件和执行两个部分 条件是对业务数据作用的判定 执行 是对业务数据的处理 在基于业务规则的软件系统中 业务规则存储在规则库中 业务人员 可以进行查询 添加 更新 统计 可以不断积累经验 实现对业务行为的知识管理 这使 得业务规则与单位的数据信息一样成为单位的重要资产 1 5业务规则的要素 业务规则最基本的组成成份是用于表示它的语言 业务术语是人们用于定义事物的工具 例如术语表 一个组织的本质和运行结构可以用相关的术语来描述 如 客户借一笔 1 年期 流贷 类似 企业信用评级不可以低于 A 这样的规则则能够限定和控制企业的某些行为 此外 利用业务规则可以从一种知识推导出另一种知识 业务规则的属性包括名称 状态 被提议的 有效的 被核准的 终止的 有效日期 和终止日期 业务规则描述 表达式 触发事件等 其主要形式有决策表 决策树 规则语 言和脚本 决策表 以表格的形式表示业务规则 每一行表示一条规则 列表示条件或动作 当所 有条件满足时 执行动作 决策树 将一组业务规则以树型结构来表示 每一个分支表示一条决策路径 叶子节点 表示结果或动作 规则语言 使用类似自然语言的句法描述规则 目前有很多种规则语言 每种语言适合 解决其特定领域的问题 可以提供较好的性能 但比图形化的表示难于维护 5 脚本 模板 用于描述过程性的业务逻辑 是决策表 决策树 规则语言的基础 如 IF THEN ELSE 2 规则引擎 在很对行业的系统应用里 业务规则往往非常复杂 并且处于不断的更新变化之中 而 现有很多系统的做法 是将业务规则绑定在程序代码里 当业务规则变更时 对应的代码也 必须得跟着修改 每次即使很小的变更都需要经历开发 测试 验证 上线等过程 变更成 本比较大 长时间的规则变更 系统变得越来越难以维护 如此以往 系统变得僵化 新需 求插入也比较困难 上线周期也较长 另一方面 开发人员熟悉业务的程度远远比不上业务 人员 却需要承担将业务规则准确无误实现的重任 使用传统的应用系统开发和实施方法 业务规则相对固定不易改动 系统的每一项策略 规则的变化都需要开发人员对源代码进行修改 业务规则动态的特点使传统的解决方案越来 越难以满足电子商务业务系统的实际需求 限制了系统的灵活性和生命力 所以能否让我们的业务系统更灵活一点呢 将业务规则从技术实现中提取出来 实现技 术和业务的分离 开发人员处理技术 业务人员定义业务规则 各自做自己擅长的事 这个 方法就是所谓的规则引擎 以电子商务为例 电商促销是一种典型的业务规则需要频繁改动的应用 各电商平台为 了吸引用户 不断推出新的服务和优惠活动 以满足不同层次 不同时期用户的需求和业务 需要 为快速响应竞争 这些业务策略的改变需要在很短的时间内完成 比如几个小时 当 天或几天 这就意味着这些改变要由运营商自己的业务人员而不是软件的开发人员来实施 此外 电子商务业务处理的数据量巨大 每小时要处理的数据可能高达几千万条 引入规则引擎之后把业务规则从具体的程序代码中剥离出来 业务规则不再以程序代码 的形式驻留在系统中 取而代之的是处理规则的规则引擎 业务规则存储在规则库中 完全 独立于程序 业务人员可以像管理数据一样对业务规则进行管理 比如查询 添加 更新 统计 提交业务规则等 业务规则被加载到规则引擎中供应用系统调用 2 1规则引擎是什么 BRMS Business Rule Management System 业务规则管理系统 俗称规则引擎 是由推 理引擎发展而来的一种专家系统 专家系统是人工智能的一个分支 它模仿人类的推理方式 使用试探性的方法进行推理 并使用人类能理解的术语解释和证明它的推理结论 专家系统 有很多分类 神经网络 基于案例推理和基于规则系统等 规则引擎的主要思想是将应用程序中随着时间 空间动态易变的业务决策部分分离出来 并使用预定义的语义模块编写业务决策 由用户或开发者在需要时进行配置 管理 规则引擎实现了将业务决策从应用程序代码中分离出来 接受数据输入 解释业务规则 并根据业务规则做出业务决策 它可以为企业带来许多好处 分离商业决策者的商业决策逻辑和应用开发者的技术决策 能有效的提高实现复杂逻辑的代码的可维护性 在开发期间或部署后修复代码缺陷 应付特殊状况 即客户一开始没有提到要将业务逻辑考虑在内 6 符合组织对敏捷或迭代开发过程的使用 规则能作为知识被保留下来 不会随着关键人员的流失而流失 在规则引擎为企业带来的诸多好处中 最重要的三点 就是带来业务系统的敏捷性 企 业业务知识的沉淀以及为决策分析提供支持 要真正达到以上几点 就需要规则引擎产品能够 提供友好的规则设置界面 让业务人员自行设置规则 提供完善的管理功能 使用软件工程的思想管理规则的开发过程 提供良好的嵌入式架构 规则不仅能在 BRMS 中编辑 也能在业务系统中编辑 从而 真正做到规则管理无处不在 2 2规则引擎的组成 规则引擎的任务是把当前提交给引擎的数据对象与加载在引擎中的业务规则进行测试和 比对 激活那些符合当前数据状态下的业务规则 根据业务规则中声明的执行逻辑 触发应 用程序中对应的操作 它主要包括以下三部分 RuleBase 规则集 WorkingMemory 工作存储器 和 InferenceEngine 推理引擎 推理引擎包括三部分 PatternMatcher 匹配器 Agenda 议程 和 ExecutionEngine 执行引擎 它们的结构如下所示 1 规则集容器 用于存放从规则库中提取的对应当前问题的一组规则 这些规则将按照某 种数据结构组织 当工作区中的数据发生改变后 引擎需要迅速根据工作区中的对象现状 调整规则执行队列中的规则 2 工作存储器 即规则引擎的综合数据库 也称为事实库 用于存放规则系统运行时所需 要的各种信息 其中的信息用来与规则集容器中的规则进行匹配 3 匹配器 是规则引擎工作的上下文环境 用来关联规则集容器和工作存储器 将规则集 容器中的所有规则与工作存储器中的事实进行模式匹配 匹配成功的规则将被激活 并与前 面推理得到的所有激活规则构成规则冲突集 4 议程 议程中存放的是根据需要进行过排序的规则冲突集 对匹配生成的规则冲突集进 行排序的过程称为冲突消解 然后议程中首条规则的结论或动作部分将会执行 这可能会产 生新的事实 从而改变工作存储器的内容 整个过程将一直循环下去 最终得到执行结果 7 2 3规则引擎的推理 推理引擎通过决定哪些规则满足事实或目标 并授予规则优先级 满足事实或目标的规 则被加入议程 存在两者推理方式 演绎法 Forward Chaining 正向链 和归纳法 Backward Chaining 反向链 演绎法从一个初始的事实出发 不断地应用规则得出结论 或执行指定的动作 而归纳法则是从假设出发 不断地寻找符合假设的事实 规则引擎的推理步骤如下 a 将初始数据 fact 输入至工作内存 WorkingMemory b 使用 PatternMatcher 将规则库 Rulesrepository 中的规则 rule 和数据 fact 比较 c 如果执行规则存在冲突 conflict 即同时激活了多个规则 将冲突的规则放入冲突 集合 d 解决冲突 将激活的规则按顺序放入 Agenda e 执行 Agenda 中的规则 重复步骤 b 至 e 直到执行完毕 Agenda 中的所有规则 当引擎执行时 会根据规则执行队列中的优先顺序逐条执行规则执行实例 由于规则的 执行部分可能会改变工作存储器中的数据对象 从而会使队列中的某些规则执行实例因为条 件改变而失效 必须从队列中撤销 也可能会激活原来不满足条件的规则 生成新的规则执 行实例进入队列 于是就产生了一种 动态 的规则执行链 形成规则的推理机制 这种规 则的 链式 反应完全是由工作存储器中的数据驱动的 2 4规则引擎的应用 只要是 规则敏感 的地方都是 BRMS 的用武之地 例如 在计费系统中 BRMS 已 被国内外的运营商使用在计费的话单预处理 批价 帐务等不同阶段 在中国 BRMS 首 先应用在优惠和营销方面 8 大客户管理和渠道管理也是 BRMS 的应用热点 因为这些应用领域 由于不同客户 不同区域所使用的业务规则都不相同 如果采用传统的 按需编写程序 的方式 往往会使 系统开发和以后的维护成本急剧上升 但是使用 BRMS 开发商就有可能开发出一个稳定 的平台 而规则可以在不改动程序的前提下按需定制 在 OSS 方面 规则引擎主要使用在服务管理 网络管理方面等 例如 HP 著名的 OpenView Temip 就利用 ILOG Rules 实现了对告警的相关性分析和过滤 一些国内的电信设 备供应商和网络管理开发商也开发了不少基于规则引擎的网管系统 一个例子 抽象 9 那么 完成规则引擎的应用 需要哪些东西呢 1 可视化规则定义 负责业务规则的定义和实现 需要方便业务人员进行操作 业务人员 通过鼠标拖拽等方式 使用规则组件完成业务规则的定义 规则定义要支持智能检查 比如条件永远为真或假 自我矛盾 冗余 未完全覆盖等等 2 业务规则管理 负责业务规则的查询 添加 删除 修改以及规则冲突检测 以及业务 规则的生命周期管理 3 业务规则验证 负责对用户的规则定义和实现进行正确性和有效性验证 是业务规则投 入使用前正确运行的验证环节 是一个必要环节 4 业务规则引擎 业务规则的匹配 解析和执行 执行按照优先级顺序进行 5 规则执行监控 负责对正在执行的业务规则进行查看 暂停 中止 取消和设置优先级 6 外部数据接口 负责在业务规则匹配和执行中从数据源存取数据的接口 7 规则定义组件 以组件的方式方便业务人员进行规则的定义 组件负责定义业务实现中 的公共部分 用户通过组件的组装可以定义规则 2 5业务规则的提取 由于规则引擎应用的实质可看成是一些特殊的脚本语言解释器 因此它们在理论上可以 有任意的灵活性 可以对应用进行任意的扩展 但是 如果整个系统都由规则来实现 反而 在性能和可维护性上大大落后于普通的系统 因此 在系统中使用基于规则的方法时 首先 要限定规则的适用范围 即哪些是不适合用规则来实现的 10 基于业务规则的方法专注于真正和业务相关的部分 核心是将应用中的业务规则从程序 中抽取出来 以方便业务人员的对现有业务的理解 管理 修改或增加新的规则 业务规则 必须包含且只包含业务人员关心的业务信息 1 业务规则是关于业务的 而不是关于常识的 例如 手机浏览网站 0 03 元 KB 是业务规则 而一次上网费用等于总流量乘以单价则是常 识 如果是 20 元 100MB 套餐用户 则每月流量在 100MB 之内的总共收费 20 元 之外的 按照 0 03 元 KB 计算 这是业务规则 而一次上网的费用等于各服务类型费用之和则是常 识 2 业务规则是描述性的而不是过程性的 由于是给非技术人员用 业务规则不应使用条件分支 循环等技术性很强的结构 每条业务 规则都是描述性的 有唯一的名字 且可以分组 当规则之间或规则组之间有相关时 这种 相关性由独立的规则来描述 例如 某套餐用户每月手机上网有 2M 的夜间免费流量 还有 5M 的任意时间免费流量 这两条业务规则之间有这样的关系 如果在夜间的 2M 免费流量 还没用完 则先用这个 否则考虑 5M 免费流量 此关系可以用定义前一免费规则的优先级 高于后者来描述 3 业务规则是基于自然语言且面向所应用的领域的 由于业务规则是非技术人员来管理的 因此业务规则不能是任何一种抽象的程序设计语言 而是基于自然语言的易理解易操作的一种语言架构 便于用户使用 在一个应用系统中 常识部分一般变化较少 变化频繁且需业务人员自己快速处理的一 般都是业务相关的部分 通过把业务相关部分从程序中分离出来形成业务规则 由于使业务 规则的数目减少 并且业务规则又都是描述性的 因此 业务人员能方便地定义 修改和管 理这些业务规则 此外 业务规则数目的减少还降低了解释执行它们的开销 使得使用规则 方法带来的性能上的损失减少 因此 基于业务规则方法的一个关键就是抽象出该应用系统领域中的所有常识部分 在 应用程序中实现 并保证绝大部分的业务都可以在这些常识的基础上以业务规则来描述 2 6业务规则的管理 业务规则管理主要是建立规则生命周期的管理流程 其他还有版本管理 权限管理 规 则运行监控等 11 3 典型案例 案例 1 信用卡申请 12 13 案例 2 企业薪资计算 客户面临的问题 某大型快递公司员工达二十余万 公司在薪资计算方面面临岗位类别多 不同部门 不 同岗位的薪资计算方式不同 一线员工采用基本工资 派件计件制 收件计件制 派件计重制 收件计重制 大客户营销提成制等混合计薪方式 二 三线员工采用基本工资 绩效工资的计 薪方式 且员工绩效工资随着公司绩效指标的变化而变化 薪资计算量大 计算规则复杂多 变 原有的薪资计算系统不能满足薪资计算的要求 解决办法 通过在薪资计算系统中嵌入规则引擎 将薪资计算规则从应用程序代码中剥离 并通过 规则配置器对不同部门 不同岗位的薪资计算规则进行灵活快速地配置 快速准确地完成海 量数据的计算 14 案例 3 保险公司核保理赔 保险公司经营活动由一系列相互联系 彼此制约的环节组成 包括营销 承保 核保 理赔 合同维持 投资 计划与统计等 面对国民经济保持持续发展形势 积极拉动内需的 消费政策及开放的市场竞争形势 我国保险业将继续呈现快速增长态势 但是同时也面临了 很多的问题 而核保和理赔更是这些问题中的重点 1 定价核保规则日益复杂 频繁变动 2 渠道商和监管部门的压力 3 信息系统不稳定 差错率居高不下 并且新的系统测试周期长 联测效率更是低下 4 面对市场竞争需求变更响应速度慢 5 人员流失严重 IT 运营服务等 6 理赔速度慢 客户体验差 7 理赔欺诈风险带来的损失巨大 以上问题都严重影响了保险公司的服务水平提升 从而导致了客户流失 面对激烈的市 场竞争 这大大的制约了保险公司的更好发展 基于规则引擎的自动核保和理赔 通过提取保险公司的核保业务逻辑 把自动核保条件从程序代码中独立出来 保存为业 务规则 核保系统通过调用规则引擎运行这些业务规则规则 实现自动核保功能 这样当业 务规则发生变化的时候可以直接修改规则而不需要改动核保系统 这种方式为核保系统提供 了良好的灵活性和扩展性 保险理赔是一个广泛的用于车险理赔 人身伤残理赔 一种合理赔付等 基于规则引擎实现的自动化理赔系统主要有以下几个方面 1 人员清单导入 2 案件信息核对 3 案件理算 4 问题件处理 5 数据输出 案例 4 快递产品报价 从快递行业现状看 受益于网购电商崛起快递业高景气增长 2015 年快递业务量完成 206 亿件 同增 48 最高日处理量超过 1 6 亿件 快递业务收入完成 2760 亿元 同增 35 预计 2016 年业务量完成 275 亿件 同增 34 快递业务收入 3530 亿元 同增 28 在整个行业高速发展的同时 作为行业中主角的快递企业在伴随着行业高速发展过程中 也面对很多问题与挑战 如人员的快速扩充带来管理问题 客户更分散 服务产品门类更丰 富 产品定价更灵活等 现在的快递企业早已走过初期 单一产品服务所有客户的情况 现在的客户数量更多 群体更分散 个性化的需求更多 如何结合行业的发展 根据客户的需要制定出灵活 智能 的产品定价系统成为了所有快递企业的必须认真思考的问题 传统的快递企业定价系统采用原有的架构模式会存在如下问题 1 开发周期无法得到保障 2 业务总是在调整 变化 完全要求业务定型再构建系统不现实 3 系统无法灵活的调整 变更 15 4 系统无法满足区域和单独客户的定价和调整 5 后期调整和维护更是需要 IT 部门一直支持 采用规则引擎后 系统架构变的更加灵活 很多之前的问题都迎刃而解 1 系统建设更迅速 并且有保障 2 一改过去需求 设计 开发的传统模式 可以做到边调研边开发 3 系统变的更灵活 完全可以根据地域 客户 业务的发展需要进行随时随地的调整 4 基本区域和客户基本的调整 在后期业务人员自行调整就可 不过多的依赖 IT 人员 案例 5 电商促销 在电子商务网站中存在着纷繁复杂的促销规则 这些促销规则可以是作用在产品上 购 物车内若干产品或整个购物车 也可以是减免运费 额外赠送礼品 积分等 而且获得这些 促销规则存在获取资格 比如某个会员级别 甚至是指定的用户等 那么如何在电子商务系 统中通过一种统一的设计来实现各种各样的促销规则 并提供友好的扩展性方便以后挖掘的 更多的未知促销手段呢 常见促销规则和例子常见促销规则和例子 首先 让我们整理一下常见的促销规则和对应的例子 整张订单消费满 x 节省百分比 或 数值 y 适合全站促销 从指定的目录或者产品集合里 面选购满 x 减百分比 或 数值 比如图书分类 满 100 减 10 满 200 减 25 等 购买某个或指定范围的产品节省百分比 或 数值 符合某个条件赠送某个产品 符合某个条件赠送指定产品集合里面某个产品 任选一 比如满 98 元任选一赠品 买 x 则 y 免费 同上 买 x 后 若买 y 则节省 y 或某数值 这种和前面的不同 更加复杂 类似产品包优惠 某个产品特价 指定价格 减 免运费 无条件 减 免运费 有条件 比如订单满多少金额 或某个会员级别 满足某个条件则最便宜的免费 在指定的产品范围内 超过 3 件产品 则最便宜的免费 即最高折扣为 33 off 额外的积分赠送 免费的礼品包装 满 x 送 y 优惠券 使用优惠券 Coupon 获得指定的优惠 更多的或由上面的类型衍生出的促销类型 促销规则规律和设计分析促销规则规律和设计分析 16 这些促销类型让人眼花缭乱 接下来我们要进一步分析 整理出隐藏在这些类型后面的 规律 在这之前 要定义一个说明 促销规则是在购物车和结帐页面才会生效的 在结帐页面比购物车多出的是对运费的处理 比如某些省份才免运费 其它的和在购 物车内一致 只有在顾客将某个产品加入购物车后 基于购物车内的产品进行计算分析才会 得出折扣后的价格 赠送或其它信息 而在产品列表页面或详细页面 某些促销规则可以显示完整 如特价 某些则只能显 示适用的促销活动标题了 基于这个原则 将上述的促销规则分成下面的几部分 即每种促销类型均可以通过这些 部分来表示和维护 基本信息 包括标题 说明 图片等 规则有效时间 起始时间和结束时间 规则组编号和优先级 适用于除生效条件和规则优惠不同外 其它参数均相同的促销活动 关于分组和优先级的作用下面会详细阐述 规则适用产品范围 分为单个产品 多个产品 产品目录 产品种类 含多个目录 和全部产品 规则生效条件 最小数量 含 或金额 含 规则享受资格 全体会员 最低会员级别 含 会员组 一般是临时组 指定会员 规则优惠 节省 x 百分比值 节省 x 金额 赠送优惠券 选择 1 N 优惠券类型 减运费 金额