微信公众号格式化工具
规则引擎大家可能不那么熟悉，但大数据或者业务复杂的朋友应该知道，比如风控系统，电商促销系统等，但它的作用其实远不于此，可以说他是人工智能方向的起点。
背景
思考
实施
总结
1,背景
昨天优化我之前写的自动化代码（刚来公司时，做一个新的项目，时间比较紧急，但后台接口和公众号接口都特别多，所以想偷懒把后台接口尽快做完，就写了一个可以的增删改查的自动化action代码【写一般的后台接口，只需要配置即可实现搜索查询，连表查询，新增，删除，修改操作，效果的话，当时是一下午写好了后台接口67个】），优化获取列表时，这里有很多的if语句(因为需要做各种封装,如是否存在排序，是否过滤等)，之前已经优化过一次（用的配置化的模板方法模式），但还是感觉不好，所以想继续抽离，所以就想到了规则引擎。
所以今天就给大家解析一下规则引擎。规则引擎主要用于流程化的东西，比如电商促销，根据用户的各种属性来做推荐商品或者优惠券发放，风控系统中根据用户的各种数据如年龄大于35岁，月收入3万到5万，则可贷款金额多少多少，或者评分多少多少，一般的这种业务判断逻辑我们会直接写在应用代码中，也就会出现很多的if 判断语句，当然也可以优化（策略模式），但如果业务人员需要调整规则，比如年龄大于35岁修改为年龄大于35岁且已婚，月收入3万到5万，则可贷款多少多少；那这就需要开发人员修改代码才行(如果开发人员忘了之前逻辑，还得去梳理下逻辑然后再修改代码)，那这种模式对于业务规则会经常变动且需要很快实施的场景就是很大的打击。
规则引擎就是用来应对这种场景的组件，而且其实它也是人工智能的基础（机器人按照给他的数据进行规则匹配，然后做出相应的处理）。如果有规则引擎的话，则业务人员可以直接在后台配置业务规则即可立即生效。
那规则引擎，我们该怎么做呢？
2,思考
分析：其实规则引擎就是：如果xxxx，那么yyyy这种场景，我们可以用一个容器专门来存储规则，然后加一个处理器专门处理（匹配每个规则，看数据是否满足条件，满足则再触发规则的策略），大致如下图：
大致流程是：数据源客户端都将数据上报到fact数据中心，fact数据中心将数据解析成统一格式(为什么要解析？因为要做到配置化，必定要有统一的格式，所以需要对数据进行清洗)，另外可以提供实时数据处理和离线数据处理，然后规则处理器从fact数据中心获取数据，进行处理，处理什么？答：判断是否满足规则，满足，则做相应处理(触发规则对应的处理策略)，那规则处理器的规则从哪里来？所以我们还需要一个规则中心，用来存储规则，所以规则是必须提前要注册到规则容器的，并且规则要有条件和处理(即:IF XXX THEN YYY)。
上面的话就是最简单的版本，要做得更加可扩展，那么我们可以把规则的condition和action抽离处理出来，因为condition其实就是fact数据的属性的各种表达式组合而已，而action就是对应处理。
将规则抽成可配置方式，即规则的condition处理成web网页的选择fact数据的条件表达式组合，而将action单独做成"策略中心", 策略中心对应具体的处理路径。如风控场景：策略1：拒绝该授信;策略2：拉入黑名单; 策略3：首次通过;等等，而配置规则时先选择条件，再选则对应策略。而且策略也可以直接做成插件形式更加可扩展和可维护(可支持版本号控制)。
规则的condition做成web网页选择配置，这里需要考虑转化关系，另外也可以提供dsl语言来处理（ps:这需要做词法分析和语法分析解析器[简单说其实就是一个命令模式器]，有兴趣的朋友可以看看AST[抽象语法树]）。
3,实施
本次的话，我用PHP写了最简单的第一版，后续会用golang编写上面的最后架构版本(会支持提供web可视化编写condition和dsl语言编写，具体架构会采用事件驱动架构方式处理)。代码地址：https://gitee.com/opjesus_snow/opjesus_rule_php
好了，今天的规则引擎实战告一段落，后续会有golang版本的完整版本，目前市场上的drool, urule, easy rule大家有兴趣可以去看一下，不论怎么变其实都是上面第一版的雏形，只是说对某些模块再次进行了拆分和处理。
点个关注吧~~~
关于我
