计划开始做规则引擎时进行过调研 ， 发现很多类似的平台都会使用drools 。而我们从一开始就放弃了drools而全部使用groovy脚本实现 ， 主要是有以下几点考虑：
- drools相对来说有点重 ， 而且它的规则语言不管对于开发还是运营来说都有学习成本
- drools使用起来没有groovy脚本灵活 。groovy可以和spring完美结合 ， 并且可以自定义各种组件实现插件化开发 。
- 当规则集变得复杂起来时 ， 使用drools管理起来有点力不从心 。
规则引擎模块是整个平台的核心 ， 我们将整个模块分成了以下几个部分：
文章插图
规则引擎在设计中也碰到了一些问题 ， 这里给大家分享下一些心得：
- 使用插件的方式加载各种组件到上下文中 ， 极大的方便了功能开发的灵活性 。
- 使用预加载的方式加载已有的规则 ， 并将加载后的对象缓存起来 ， 每次规则变更时重新load整条规则 ， 极大的提升了引擎的执行效率
- 计数器引入AtomicLongFieldUpdater工具类 ， 来减少计数器的内存消耗
- 灵活的上下文使用方式 ， 方便定制规则执行的流程（规则执行顺序、同步异步执行、跳过某些规则、规则集短路等） ， 灵活定义返回结果（可以返回整个上下文 ， 可以返回每条规则的结果 ， 也可以返回最后一条规则的结果） ， 这些都可以通过设置上下文来实现 。
- groovy的方法查找策略 ， 默认是从metaClass里面查找 ， 再从上下文里找 ， 为了提升性能 ， 我们重写了metaClass ， 修改了这个查询逻辑：先从上下文里找 ， 再从metaClass里面找 。
文章插图
未来规划
后面规则引擎平台主要会围绕下面几点来做：
- 指标存储计划从redis切换到hbase 。目前的指标计算方式会导致缓存key的暴涨 ， 获取一个指标值可能需要N个key来做累加 ， 而换成hbase之后 ， 一个指标就只需要一条记录来维护 ， 使用hbase的列族来实现滑动窗口的计算 。
- 规则的灰度上线 。当一条新规则创建后 ， 如果不进行灰度的测试 ， 直接上线是可能会带来灾难的 。后面再规则上线流程中新增灰度上线环节 ， 整个引擎会根据配置的灰度比例 ， 复制一定的流量到灰度规则中 ， 并对灰度规则的效果进行展示 ， 达到预期效果并稳定后才能审批上线 。
- 事件接入的自动化 。dubbo这块可以采用泛化调用 ， http接口需要统一调用标准 ， 消息需要统一格式 。有了统一的标准就可以实现事件自动接入而不需要修改代码上线 ， 这样也可以保证整个引擎的稳定性 。
- 模型生命周期管理 。目前模型这块都是通过在猛犸平台上提交jar包的方式 ， 离线跑一个model出来 ， 没有一个统一的平台去管控整个模型的生命周期 。现在杭研已经有类似的平台了 ， 后续需要考虑如何介入 。
- 数据展示优化 。现在整个平台的数字化做的比较弱 ， 没法形成数据驱动业务 。而风控的运营往往是需要大量的数据去驱动规则的优化的 ， 比如规则阈值的调试、规则命中率、风险大盘等都需要大量数据的支撑 。
推荐阅读
- 时间线桌游具体规则
- 只言片语桌游游戏玩法及规则
- shopee运营规则?shopee平台规则怎么样
- 考拉功能性灭绝什么意思 考拉为什么没有灭绝
- amd处理器编号含义-amd cpu型号命名规则-
- 大富翁纸牌游戏规则说明
- 大学生|工作能力强为何不能成为领导？升职后才发现，不是因为“潜规则”
- 羽毛球单打比赛规则
- 古玩市场交易需要遵守的规则
- 春秋时期打仗规则 春秋时期的战争礼仪
