思路拓展：再见了IF-ELSE，拥抱规则引擎

引言

简单的业务if-else硬编码最简单实用，业务复杂后维护成本就会变高，也违反了开闭原则，

if(AgentProcess==A){
	// 代加工
}else if(AgentProcess == B){
    // 非代加工

}else{

}

–>方式一：设计模式大法替代if-else，如策略、工厂、模板等 – 适合流程性的 粒度大的，比如保存、批准；

–>方式二：规则引擎 – 非流程性的，细粒度的 具体的复杂多变的业务规则

设计模式的缺点

// 以策略模式为例 
dispatch(AgentProcess){
	switch(AgentProcess):{
		// 路由到具体的处理类
		case 'A':return "agentProcessHandle";
		case 'B':return "otherHandle";
		default :return "defaultHandle";
	}
}

设计模式解决if-else，基本上最终变成如下的思路：
1、新建一个子类去处理if-else中的逻辑，
2、实际执行时动态匹配具体的类；

基于以上思路就会有如下问题:
1、流程不能经常变，否则模板或者dispatch的维度就很难抽象 ，
2、分支不能太多，否则类文件就会太多，难以维护-- 所以维度多、粒度太小的就不太适合了

其中阿里的cola架构，能支持到三个维度，“业务身份”，“用例”，“场景” ，如tmall.placeOrder.88vip

设计模式无法照顾的场景

2、hard code的代价非常大，随着业务的膨胀会使开发人员和规则需求方非常的疲惫。— 设计模式会变成过度设计

ibm开源规则引擎drools示例

		// 执行规格引擎
		public BigDecimal calculateFare(TaxiRide taxiRide, TaxiFare rideFare) {
	        KieSession kieSession = kieContainer.newKieSession();
	        kieSession.setGlobal("rideFare", rideFare);
	        kieSession.insert(taxiRide);
	        kieSession.fireAllRules();
	        kieSession.dispose();
	        return rideFare.total();
	    }

规则文件 MY_RULE.drl

global com.softdev.system.demo.entity.TaxiFare rideFare;
import com.softdev.system.demo.entity.TaxiRide;
import java.math.BigDecimal;

dialect  "mvel"

/**
*  的士打表计价Drools 
* @Author by zhengkai.blog.csdn.net
*/
rule "Calculate Taxi Fare - Output "
salience 100
    when
        $taxiRide:TaxiRide();
    then
        System.out.println("#公里数 : "+$taxiRide.getDistanceInMile);
        System.out.println("#起步价 : "+12);
        rideFare.setNightSurcharge(BigDecimal.ZERO);
        rideFare.setRideFare(BigDecimal.ZERO);
end 

        
rule "Calculate Taxi Fare - Less than three kilometers"
salience 99
    when
    	//起步价：首3公里12元;  不论白天黑夜 || distanceInMile = 3
        $taxiRide:TaxiRide(distanceInMile <= 3);
    then
        rideFare.setRideFare(new BigDecimal(12));
end

drools原理

事实（入参POJO）会和规则（if/else）进行匹配，以推断相应的规则结果，这个过程称为模式匹配。

Drools 规则引擎将业务规则转换成执行树

规则引擎的推理步骤如下：
将初始数据（fact）输入至工作内存(Working Memory)。
使用Pattern Matcher将规则库(Rules repository)的规则（rule）和数据（fact）比较。
如果执行规则存在冲突（conflict），即同时激活了多个规则，将冲突的规则放入冲突集合。
解决冲突，将激活的规则按顺序放入Agenda。
执行Agenda中的规则。
重复步骤2至5，直到执行完毕Agenda中的所有规则。

阿里开源QLExpress/美团自研规则引擎Zeus

最终效果如下 配置规则条件和规则执行结果

适用场景

当没有传统的编程方式适合解决问题的时候
非流程性的，细粒度的 具体的复杂多变的业务规则

手机运营商资费套餐
超市、商场，商城等等积分计算规则
寿险车险理赔
工资计算（ScriptEngine）

其他优点 - 快速交付、面向运营人员

a、逼迫系统开发人员和业务专家梳理业务，定义统一的BOM（业务对象模型）。

b、业务专家可以快速的制定修改规则，然后交由规则引擎自动化地来处理分析。

c、规则引擎代替系统开发人员，解决由规则条件关联动作变化带来的开发工作。
d、大部分规则引擎能实现热编译，即时生效

参考链接
规则引擎概述

规则引擎技术选型-阿里qlExpress

美团自有规则引擎Zeus（中文名“宙斯”）

QLExpress 规则引擎使用介绍
规则引擎的优缺点