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

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

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

缺点

业务条件繁杂

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

业务配置修改频繁

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

业务咨询

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

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

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

经过调研，我们发现MVEL手册表达式非常适合我们去做这件事情。而支持MVEL表达式的开源规则引擎系统中，我们认为<