背景
我们公司由于业务的极具扩大，每天经过系统的金额也达到了20亿美金左右，这个时候对资金的管控就不能像以前那样分散在不同的系统，由不同的部门负责了。所以说，我们成立了风控部门，必须成立了专门的研发团队负责风控需求，要开始做风控了。我受命去调研如何做风控。发现风控平台一般都需要一个叫规则引擎的东西，那么我就去调研了规则引擎的一些现状。
目前公司内部规则执行现状
if(f1){
if(a||b||c||d)
}
if(f2){
}
if(a&b&d){
}
- 优点
当规则较少、变动不频繁时，开发效率非常高。
稳定性较佳：语法级别错误不会出现，由编译系统保证。
没有外部依赖，执行速度很快
- 缺点
规则迭代成本高：对规则的少量改动就需要走全流程（排期，开发、测试、部署）。
当存量规则较多时，可维护性差。
规则开发和维护门槛高：规则对业务分析人员不可见
没有规则效果分析，很难感知规则的效果
规则引擎简介
规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。–来自百度百科
这个定义我感觉比较清晰了，但是我们做的不一定要有推理模块。如果只是互联网化的简单规则执行，其实不需要推理，也能做到非常高的性能。
为啥要用规则引擎
- 规则的变更非常方便，从而实现业务规则的随需应便。
- 业务规则与系统代码分离，实现业务规则的集中管理。
- 在不重启服务的情况下可随时对业务规则进行扩展和维护。
- 可以动态修改业务规则，从而快速响应需求变更，大大提高了对复杂逻辑代码的可维护性。
- 规则引擎是相对独立的，只关心业务规则，使得业务分析人员也可以参与编辑、维护系统的业务规则。
- 减少了硬编码业务规则的成本和风险。
- 使用规则引擎提供的规则编辑工具，使复杂的业务规则实现变得简单。
规则引擎的作用
规则引擎的分类实现
规则引擎在系统中根据事中，事后可以的实现方式
- 事中：验证系统流程产生的入参和返回值是否符合规则要求；
- 事后：通过大数据技术栈，对多个数据源进行比对，进行数据审计；
事中规则实现
- 规则配置，规则配置系统，主要是对一些表达式进行封装。然后将表达式交给规则解析程序/库
- 规则下发，规则建立好了之后实现规则下发，规则下发的方案有很多，可以根据自己系统要求进行实现，比如：
1. 数据库+缓存；
2. 缓存；
3. Mq订阅；
4. Zookeeper的Watcher；
- 规则执行
- 规则引擎关注的是时延，不能进行跨进程调用问题，尽量不访问数据库和外部内存，直接使用机器内存
- 规则较多，尽量使用并行执行，不如有依赖，可以分析依赖树，然后并行执行
事后规则实现
- 主要通过大数据技术栈对多数据源数据在Hive中进行聚合，对于执行实现可以接收一定的延迟，或者采用流式处理降低时延
- 对于一些时间窗口的处理，使用flink进行聚合
规则引擎有哪些功能
- 规则配置-可视化
- 脚本语言编写规则
- 规则优先级执行
- 可视化规则流
- 版本发布，回滚
- 灰度发布
- 评分卡
- 决策表
- 决策树
- 黑白灰名单
- 标签管理
- 可视化决策流编辑
- 规则监控
- 用户权限管理
- AB测试
- 冠军挑战
- 规则效果分析
- 本地化(和业务系统在一个进程中)和服务化(单独部署)
核心挑战
- 规则的易变性 规则频繁变动，硬编码死板问题和动态加载的性能问题，如何快速的下发规则
- 规则的定制化 因为用户画像不同导致千人千面的策略，有一定的定制特点
- 时延要求低 几乎每个核心业务动作都会调用风控接口，如何保证业务的无感
未来趋势
- 更高阶的风控决策引擎，在现有的风控决策引擎上融入了自言语言处理平台、流计算平台、实时预警、深度学习、可视化科学计算等，提升了现有决策引擎的算力和处理时效。
- 随着技术的革新，未来的决策引擎，会向着功能更加丰富，性能更加优良，决策更加智能的风控智能实时规则系统演进
应用场景
对于一些存在比较复杂得业务规则并且业务规则会频繁变动的系统比较适合使用规则引擎
- 风险控制系统----风险贷款、风险评估
- 反欺诈项目----银行贷款、征信验证
- 决策平台系统----财务计算
- 促销平台系统----满减、打折、加价购 等等
典型场景-信用卡授信
规则引擎调研
- 开源规则引擎
- JBoss Drools
- Mandarax
- OpenRules
- JEOPS
- InfoSapient
- Roolie
- Apache Camel
- 商业规则引擎
- ODM(ILOG)
- Oracle Business Rules
- 旗正规则引擎
- Jess（可研究，商用收费）
- TopRules
- 明策智能决策
- Blaze
- 益博睿决策引擎
ILOG调研
ilog是一套功能完备的规则引擎，支持普通规则、决策表、决策树、评分卡、规则流，可以以自然语言的方式编写规则，同时在版本管理上提供基线、规则集管理的功能，核心引擎采用智能专家推理算法，能够高效的执行规则匹配。
ILOG流程演示
- 定义规则
- 定义决策表
- 定义规则流
- 部署多版本支持
- 测试执行结果
- 统计执行结果
ILOG优势和劣势
优点
- 有规则的自然语言
- 快速的执行速度
- 支持普通规则、决策表、决策树、评分卡、规则流
- 具有版本管理功能
- 具有规则集管理功能
- 比较成熟，产品周期较长，客户较多
缺点
- 网上资料很少，出了问题很难独立维护
- 需要支付大量的安装和部署费用，而且有长期的维护费用
- 比较成熟的方案都是商业软件，例如F5,webspere,Oracle等
- 安装包非常大，几G数据，只支持windows安装，windows开发部署规则等
- 不支持聚合类策略，一般是在外面服务处理好，ODM支持，但是没有用过
- 规则没有扩容方案，只能单库
- ILOG是商业版本，没有支持开源框架，也没有微服务化，很难和公司现有的spring-cloud相融合
- 由于不能和公司现有的spring-cloud相融合，就不能调用公司体系的服务作为判断因子
- 黑白灰名单，这些数据的访问必须前置一个规则系统
Drools
Drools 是用 Java 语言编写的开放源码规则引擎，使用 Rete 算法对所编写的规则求值。Drools 允许使用声明方式表达业务逻辑。可以使用非 XML 的本地语言编写规则，从而便于学习和理解。并且，还可以将 Java 代码直接嵌入到规则文件中，这令 Drools 的学习更加吸引人。
优点
- 非常活跃的社区支持
- 易用
- 快速的执行速度
- 在 Java 开发人员中流行
- 与 Java Rule Engine API（JSR 94）兼容
缺点
- 业务分析师无法独立完成规则配置：由于规则主体DSL是编程语言（支持Java, Groovy, Python），因此仍然需要开发工程师维护
- 规则规模变大以后也会变得不好维护，相对硬编码的优势便不复存在
- 规则的语法仅适合扁平的规则，对于嵌套条件语义（then里嵌套when…then子句）的规则只能将条件进行笛卡尔积组合以后进行配置，不利于维护
整体设计
代码示例
URule
URule是一款纯Java规则引擎，它以RETE算法为基础，提供了向导式规则集、脚本式规则集、决策表、交叉决策表(PRO版提供)、决策树、评分卡及决策流共六种类型的规则定义方式，配合基于WEB的设计器，可快速实现规则的定义、维护与发布。
URule提供了两个版本：一个是基于Apache-2.0协议开源免费版本，URule开源版本第一款基于Apache-2.0协议开源的中式规则引擎；另一个是商用PRO版本。
整体设计
功能设计
开源和商业版本比较
基于Aviator的表达式
Aviator 的基本过程是将表达式直接翻译成对应的 java 字节码执行，整个过程最多扫两趟（开启执行优先模式，如果是编译优先模式下就一趟），这样就保证了它的性能超越绝大部分解释性的表达式引擎，测试也证明如此；其次，除了依赖 commons-beanutils 这个库之外（用于做反射）不依赖任何第三方库，因此整体非常轻量级，整个 jar 包大小哪怕发展到现在 5.0 这个大版本，也才 430K。同时， Aviator 内置的函数库非常“节制”，除了必须的字符串处理、数学函数和集合处理之外，类似文件 IO、网络等等你都是没法使用的，这样能保证运行期的安全，如果你需要这些高阶能力，可以通过开放的自定义函数来接入
特点
- 支持运算符重载
- 原生支持大整数和 BigDecimal 类型及运算，并且通过运算符重载和一般数字类型保持一致的运算方式。
- 原生支持正则表达式类型及匹配运算符 =~
- 类 clojure 的 seq 库及 lambda 支持，可以灵活地处理各种集合
一期时间人员规划
一期功能-2.5个月 3个后端
- 规则配置由研发来完成
- 策略执行根据业务调用动态执行
- 引入事件，场景，规则，因子概念
- 规则在场景中按照优先级执行，暂时不支持分支判断
- 规则支持版本发布
- 不支持决策表，评分卡等
- 支持简单聚合规则
- 支持黑白名单，不支持灰名单
自研规划
结论
基于Aviator自研，随着业务一起迭代。2个月左右可以上线第一版，设计出整体的模型框架，支持普通的规则和规则集执行，可以满足业务需要。
