相信很多人都听说过规则引擎，有些人或多或少都会在项目中使用过规则引擎。

最开始听说过规则引擎可能是一个类似于OA的系统中，通过规则配置，让一个审批流程得到配置化和规则化。

后来做过一个类似于规则引擎的项目是在推荐系统还不那么热的时候，当时系统中希望增加一个功能【猜你喜欢】，因为这个是易变的规则，运营同学在规则系统配置：如果用户买了a,b,c产品则推荐产品e,f,g。

这个还是一个比较简单的规则场景，随着系统越来越大，运营，产品同学期望对系统能有更系统的把控，规则引擎有了新的生命力。

后续接触的一些规则引擎常出现在一个大数据体系的系统中，我们的规则引擎出现在风控平台，大数据审计系统，优惠策略等系统中。

规则主要起到两个作用：流程控制，数据验证。

规则引擎在系统中根据事前，事中，事后可以的实现方式：

技术上可选的方案很多，将整个系统进行进一步抽离可以理解为两部分：

我们希望做到这样的效果，在规则平台进行规则配置，规则即可生效，之后规则下发，在系统执行到对应的业务场景时触发规则验证。

所以我们首先需要一个规则配置系统，实现方式可以采用开源的库，对一些表达式进行解析。或者采用之前写过的服务化配置的另一种可能，总之是将规则封装成一个便于解析的表达式，将表达式交给规则解析程序/库。

规则建立好了之后实现规则下发，规则下发的方案有很多，可以根据自己系统要求进行实现，比如：

规则属于非核心业务规则，为了避免因规则验证造成的时延，不建议放到缓存或者数据库中，比较会存在跨进程调用问题，可以放到本地内存进行提速。

内存中应用程序触发规则可以借助自定义注解，AOP，反射，字节码技术等进行实现，今天推送的文章涵盖了基本的技术。

事后的规则实现就比较简单了，主要通过大数据技术栈对多数据源数据在Hive中进行聚合，既然是事后的离线方式，对于执行实现可以接收一定的延迟，或者采用流式处理降低时延，总之在产生即时数据之后的处理措施都属于事后规则，常见于审计系统，风控系统等。