当我们在对复杂的业务进行开发时，程序本身逻辑代码和业务代码互相嵌套、错综复杂，同时维护成本高，可拓展性差。
规则引擎即是：可降低复杂业务逻辑组件复杂性、降低应用程序的维护和可扩展性成本的组件！
如下图：
规则引擎实际上就是一个推理引擎，用于匹配facts（事实，我们可以理解为输入数据）和rules（规则），以推出结论。
背景：业务规则经常变化，系统需依据业务的变化，实现快速、低成本的迭代更新。
因此，为了快速、低成本的更新，我们需将逻辑代码和业务代码进行解耦：
研发人员（不需懂业务）开发维护程序部分，同时测试通过后，后续不会经常变化改动；业务人员可直接管理这些业务规则，同时不需要研发人员的参与。因此它具有以下优点：
业务人员和研发人员各司其职；稳定层和变化层分离，这是一种优秀的设计模式；变化层支持可视化或配置化的方式，快速进行业务规则的增删改操作，甚至支持热插拔和热更新。以减少冗长的开发和测试周期；部分规则引擎甚至带有设计器（如drools），还可解决我们 “简式建模” 的需求。 三、主流规则引擎市面上主流的规则引擎包括：
序号名称开源情况流行度运行模式备注1llog商业非常出名/价格昂贵，不推荐2drools开源github 3.2k嵌入式、分离式支持可视化等整个配套，是一个完整的BMRS系统（业务规则管理系统），同时其生态很活跃。3esayRule开源github 2.6k嵌入式支持yml、java、注解方式配置规则，但是后两者无法实现动态加载。4qlexpress开源github 2.3k嵌入式支持java方式书写规则，且支持动态加载，但加载比较耗时。后续还有Aviator、Vincio均是类似性质，故不予赘述。5uRule商业github 1.1k嵌入式、分离式除了部分开源外，其他方面基本和drools差不多，也是一套完整的 BMRS系统，且是国内开发，学习和使用门槛更低。6logstash开源出名分离式它不算规则引擎，但也放这儿了。想到它也是做数据处理，且支持正则、模式匹配等简单数据处理。也许某些公司某些场景，就刚刚就能用上。7甜美的曲奇商业文档巨少/不推荐8jruleengine开源国内几乎没咋用嵌入式不推荐9jlisa商业同上/不推荐10esper开源github 659嵌入式不推荐11自研////PS：
顶书在drools和esper权衡下，选择了drools！原因是自研需投入大量人力物力，做的稳定好用还需时间，所以自研被否了，而esper热度较低，担心没人维护。美团在drools和esayrule权衡下，选择了activi ^_^！
因此，我们下一篇文章主要看看drools的一个大体架构，以及踩坑笔记。
如果喜欢本文，请关注公众号：开猿笔记，里面会有持续更新噢！