轻量级规则引擎调研

我们基于Flink实现了云端的规则引擎，以flink on yarn方式在运行，依赖hadoop和zookeeper，对于边缘侧来说比较重，所以打算调研下轻量级的规则引擎，我们的业务诉求如下：

业务需求背景

1、轻量级

2、支持海量规则

4、便捷的规则启停

5、动态加载

从如下几方面对比目前比较流行的几个规则引擎框架：

drools

1、社区活跃度

drools（3.7k），比较活跃的社区。三者中遥遥领先。

2、SQL支持度

不支持，通过DSL定义规则。有开发工具，生成drl文件。

3、开箱即用（支持JAVA API直接调用）

可直接maven引入依赖，开箱即用。规则需要预先加载，环境初始化比较慢2秒左右。需要自己写规则调度。

4、部署方式

可部署多个kie-server，kie-server为单机模式。

Siddhi

1、社区活跃度

Siddhi（1.2k）。

2、SQL支持度

与flink sql类似，流式处理。定义source、sink，支持多流join。丰富的插件：kafka、redis等。通过类SQL的语言描述事件流任务。

3、开箱即用（支持JAVA API直接调用）

可直接maven引入依赖，开箱即用。规则需要预先加载，环境初始化比较慢2秒左右。需要自己写规则调度。

4、部署方式

第一种方式：Standard Deployment  ，单机部署，与drools的kie-server的部署方式类似。

第二种方式：完整的分布式部署

此部署规模已经很接近flink了，但是没有checkpoint的机制。

esper

esper的社区活跃度真不高esper（699），所以我们直接略过。

几个主流的规则引擎其实实现机制都差不多，功能都能满足我们的业务场景，drools在sql支持方面比较弱，优势在社区活跃度。Siddhi的部署方式已经接近Flink，网上都说它比较轻量级，我是真的没看出来。最终打算采用drools，直接通过java api进行调用。自己写个简单的调度，如果上了它的执行调度模块，还不如直接使用flink，flink在这方面成熟多了，有checkpoint、status等机制。对于drools的动态加载，我会单独开一篇文章来详细说明，这个是我们的痛点，基于flink目前机制实现不了的。

urule

官网

上海锐道信息技术有限公司

文档 1.1. 简介 · GitBook

商用版地址： weiqun.jiang/urule-pro-boot

开源地址：https://github.com/youseries/urule

轻量级规则引擎调研淡淡的小番茄关注0.8682021.06.25 20:30:59字数 689阅读 1,141我们基于Flink实现了云端的规则引擎，以flink on yarn方式在运行，依赖hadoop和zookeeper，对于边缘侧来说比较重，所以打算调研下轻量级的规则引擎，我们的业务诉求如下：业务需求背景1、轻量级2、支持海量规则4、便捷的规则启停5、动态加载从如下几方面对比目前比较流行的几个规则引擎框架：drools1、社区活跃度drools（3.7 我们公司由于业务的极具扩大，每天经过系统的金额也达到了20亿美金左右，这个时候对资金的管控就不能像以前那样分散在不同的系统，由不同的部门负责了。所以说，我们成立了风控部门，必须成立了专门的研发团队负责风控需求，要开始做风控了。我受命去 调研 如何做风控。发现风控平台一般都需要一个叫 规则引擎 的东西，那么我就去 调研 了 规则引擎 的一些现状。 目前公司内部规则执行现状 if(f1){ if(a||b||c||d) if(f2){ if(a&b&d){ 当规则较少、变动不频繁时 Drools这个 规则引擎 其实不怎么好用，但是总比if-else强，虽然用着憋屈，但需要的时候也是没办法。 在网上找过很多文章和视频，要不就是实用性不高的Demo，要不就是粗略归纳，看的云里雾里的水文。我自己也是被这个东西恶心到了，所以完成之后决定写一个实用的Demo，希望可以帮助到需要的人。 一：Drools的使用 其实Drools的使用方式我觉得有3种： 基于Web页面的WorkBench 优点：web页面，操作简单，可动态配置修改规则文件，不影响项目的运行 缺点：web页面卡顿。。..