规则引擎的行业概况

主要应用

规则引擎使用于

• 规则复杂度中等（状态语义的规则少）。如果状态语义非常复杂，那么对用户而言，使用规则引擎的成本就会和使用代码类似
• 规则数量多
• 规则变化频繁的场景。

最典型的场景就是金融风控&其他风控领域。

• 风控：规则数据比较多，而且牵扯到用户核心敏感数据，会涉及外部数据采集，当天实时数据累计等，不能进行T+1的预计算。特别是金融风控领域。

• 社交网站过滤等。比如UGC。每天大量的新增规则和配置。

• 营销：相对来规则讲比较简单，主要是依据于预计算的人物标签就可以。更关心吞吐量，毕竟营销活动一般都是要挂在首页上的。当然营销一样会有实时场景，比如说反作弊，建议采取异步链路去加黑。

• 其他规则密密集变动型应用：比如说税务核算，话费计算等等。

• 其他业务。互联网的每一个部门，应该都有自己可配置的逻辑执行中心。但是相对于上面的场景，这些规则引擎往往更简单（纯粹）。

各种规则引擎

国外的规则引擎更多是提供一种脚本。而国内的一半提供一种平台，以开源脚本为基础，提供拖拉拽或者配置式图形界面。
具体使用哪种语言，取决于用户的知识背景和习惯。

底层编辑模式

drools

drools也支持CEP
https://www.jb51.net/article/157770.htm

aviator

基于java的表达式解析。国内大牛开源。

MVEL

基于java的表达式解析。

SpEL(Spring表达式语言)

        Map dataMap = new HashMap<>();
        dataMap.put("test", new Test());
        String result = spelExcetor.doneInSpringContext(dataMap, "#test.getName().concat(\" world\").substring(0, 4)");

easyRules

继承了MVEL，后续支持Spel

rulesEngine.fire(rules, facts);

SQL

PMML

URULE PRO

号称是【业内首创的纯浏览器编辑模式】。有点夸张。我觉得大部分互联网公司公司做客户端软件的能力恐怕还不急做网站的能力的。

SMARTS

• SMARTS还支持导入使用SAS、Python、R或SPSS创建的PMML模型

VisualRules

传说中的国家队。

JRules

很久很久以前有一家叫做IBM的公司搞的。其实那时候的规则引擎都是连续输入有状态的。

企业内部自定义DSL方案

calcite方案

大家都知道Flink的SQL引擎是基于Calcite来实现的。

java方案

干脆什么都不做，让用户直接写源代码

数美

规则引擎没有什么特别的，但是可以顺便在规则引擎中打包购买一些内部的特征。

同盾

规则引擎没有什么特别的，但是可以顺便在规则引擎中打包购买一些内部的特征。

阿里云

规则引擎没有什么特别的，但是可以顺便在规则引擎中打包购买一些内部的特征。

部署方式

云模式

近端模式

• 利用文件系统进行部署的模式
• 利用数据库进行部署的模式

近线模式

业界常见的是基于Flink进行部署。
https://developer.aliyun.com/article/739612

离线模式

业界常见的是基于各种MapReduce执行框架进行执行。

多层部署模式

使用

一般适用于java服务，事件流处理，还有离线大数据计算的情况。

大公司的解决方案

• 阿里巴巴CRO
  霸下 + MTEE
  http://www.360doc.com/content/20/0611/17/70433361_917811571.shtml

• 支付宝CRO（大安全）
  累计服务velocity ， CTU风控大脑
  AlphaRisk
  https://www.sohu.com/a/230705152_629652

我们看下蚂蚁招股书的介绍

• 美团Zeus
  https://tech.meituan.com/2020/05/14/meituan-security-zeus.html

总结

• 正确性。
  必须要正确，不然什么都没有了。要保证100%的正确，每一套逻辑分支的正确。这需要测试。大数据量的离线测试。这显然需要耗时。所以，一般来讲，正确性和开发速度是最后的矛盾。

• 速度。
  编辑规则总是很快。但问题是（1）如何设计规则，（2）设计规则后又如何去评价规则。

  • 设计规则不属于规则引擎的内容。业务同学会使用SQL，SPSS，SAS，R，PYTHON进行数据分析。但是，当他们产生一个可行的规则后，原始的数据已经面目全非，中间经过了N次转换，他现在还要把这个东西还原给你吗？再讲一遍，大家都很累。

  • 针对上一点，实在过于复杂的逻辑一定不要使用规则引擎。而是要求业务方导出模型进行部署。目前大企业中，让业务方同学直接提供python脚本在服务器上用jython跑有点不现实。使用sklearn_porter。在java上还是推荐PMML。当然也可以有些SAS包，pytorch提供的导出能力都可以。

  • 我们都说可以使用过去的业务数据进行真实模拟。但是过去的数据一定有吗？比如，我们的大数据同学发现一个人的贷款几率和他当天累计消费有很大关系，过去的数据我们理论上可以得到。但是极为复杂。需要依赖过去的实时累计能力。可能会有和时间

• 市面上规则引擎的共同弱点之一，那就是将多版本并行，旁路，切流，灰度都推给客户来做。而这些，本来就应该1是规则引擎的基本能力。

• 市面上规则引擎的共同弱点之二，就是规则引擎和数据获取是分离的。而不是集中在规则引擎里作为能力。这其实让我们难以追踪数据的血缘，无法评价数据质量，无法做数据的统一管控。

• 或许的人工智能？可不可能实现规则的自动上下线？基于此，可不可以实现模型的自动参数优化？

  • 其实这个问题展开来说技术没有难度，就是依赖于你场景的反馈速度。如果借出去一笔贷款要一年才能判断实质性风险，那么也就谈不到依据业务结果快速进行调整。

• 更加快速的部署？秒级别？

  • 这个问题的不是特别有意义。我们真的会有那种一秒生一秒死的情况吗？如果真的如此惊心动魄，反而更应该慎重
  • 但是，比如说调试等场景，我们当然希望反应迅速。此时，我们应该轻量化运行规则引擎的核心。

• 所见即所得？规则引擎彻底淘汰自己的道路就是让规则研发人员在数据分析的同时完成部署。

其他

图计算

geabase，离线预计算，流图融合

联合建模

https://www.sohu.com/a/226131004_99930730

这玩意说白了，不就是一个芝麻分嘛。
但是人家的语句叫做
【多边安全计算等来实现数据不出域的同时能够共同对客户做一些画像和建模的能力。】
当然，肯定有另一部人在真正的研究
比如说经典的百万富翁问题

张三找10个一模一样的箱子，按照1～10的顺序摆好，并按照自己的财富值分别往里面放入苹果梨和香蕉，具体放法为：如果序号小于自己的财富之，放入苹果，相等，则放入梨，大于自己的财富值，放入香蕉；
把10个盒子都叫上锁；并叫李四过来（或者寄给李四）
李四根据自己的财富值对相应的箱子再加一把锁。然后把其他所有箱子销毁。并把这个选择的箱子送给张三。
张三看到送回来的箱子，但他不知道李四选择的是第几个箱子，因为每个箱子都是一样的
张三李四分别开锁，看里面是什么水果：
-- 如果是苹果，张三比李四富有；
-- 如果是梨，两人一样有钱
-- 如果是香蕉，李四比张三富有

是输出规则配置平台的SAAS？还是在输出用户隐私？

这个灵魂拷问留给各大想在风控引擎赚一把的公司。

未来

• 易用性和灵活性的拆分。适应不同背景的用户。但是保证相同的底层架构。灵活一定要建立在可追溯，可管理的基础上，不然我们就不要做规则引擎了，直接做一个热发布平台就完事了。