如何设计一套规则引擎系统

很早以前就想写一篇关于「规则引擎」的文章，可是一直苦于没有时间。恰好最近给团队小伙伴梳理了我设计的引擎的使用和原理，正好借此机会在此写下咱们的心得。 「规则引擎」系统通常而言，在风控中使用较多，可是通过调研，咱们发现，其实在业务系统中，对于规则引擎系统的渴求度更大，甚至于，我在脉脉上都看到好几我的在咨询业务规则引擎系统应该如何设计和接入。

首先来聊一下痛点。为何对于规则引擎系统的渴求度这么大？

缺点

业务条件繁杂

试想一下，或者说正是你所经历的，在咱们的业务逻辑中，有不少不少不少的业务条件判断，而这些业务条件的修改每每又较为频繁，若是你的项目部署还比较耗时，那么“开发五分钟，部署一小时”的场景又会浮现。

业务配置修改频繁

在咱们的业务中，每每又有许多的业务配置嵌入其中，好比功能开关、白名单、黑名单等。而这些配置，若是你的项目有接入一些业务配置系统还好，若是没有，那么又是须要发一波代码。

业务咨询

代码对于咱们的业务方来讲是不可见的，遇到一些根本不是问题的问题时，老是会向技术人员咨询。而你若是了解项目还好，可是一旦忘记，又须要去梳理一次业务逻辑。

幸福的家庭老是类似的，不幸的家庭却各有各的不一样。处理这些看似不经意的小问题，老是会不经意间打断咱们的思考。天下苦秦久已。 梳理一下，咱们须要解决的事情至少有3点：

1. 业务规则配置化。规则代码的编写，支持拔插和热更新。
2. 业务配置可视化。业务配置应交由业务方自行处理。
3. 业务咨询可见性。当业务遇到不清楚的问题时，能够很是清晰的在某个地方了解到缘由所在。

通过调研，咱们发现MVEL手册表达式很是适合咱们去作这件事情。而支持MVEL表达式的开源规则引擎系统中，咱们认为easy-rules更贴合咱们的场景，一方面他支持MVEL，另外一方面，他也支持在Java中自定义Rule，另外，他还支持自定义规则引擎。

可是，仅靠easy-rules并不能直接在使用生产环境中，咱们须要针对本身的业务作一些调整，好比须要统一规则、须要统一属性注入、须要统一返回结构等等。

咱们大体画了一下咱们业务执行的主要流程。首先须要注意的是，在业务中，确定会有不一样场景的状况，所以咱们须要作好场景区隔，咱们不可能将全部的东西都在一个地方去执行。所以我设计的适合有些地方参考了Java I/O这块的设计思路，有一个EngineProviders负责调度分发到不一样的场景中。 每一个场景都实现了统一的接口，而这个调度过程也是动态化的，尽量较少咱们开发同窗所须要作的操做。

而在此以前，须要有一个统一的EngineService来统一的去获取咱们配置的规则，去注入到场景中。同时，也须要把咱们自定义的业务配置来注入到咱们的数据源中。以下图所示：

这里就是咱们自定义的一些规则了，由于业务关系，打上了部分马赛克，不过应该并不妨碍理解这里所要作的事情。

然而，咱们在实际的业务中，还有不少地方都须要抽象的统一规则，所以，咱们也能够借助easy-rules提供的能力来帮助咱们完成这种事情。

固然须要说明的是，还有一些细节没有补充上去，好比构参builder等，由于是根据咱们业务自定义的，因此即便补充上去参考价值也不大。

最后还有一点，缘由可视化的问题须要解决。其实这个相对而言就很是简单了，咱们仅须要在阻断的地方记录当时的参数，以及阻断的规则，而后将其可视化，业务方自行查阅便可。

欢迎关注个人公众号，每周至少一篇比较有深度的原创文章：