规则引擎预研

我们要增加一个检查商户的输入商品介绍有没有不合规的单词的功能，淘宝也有类似的功能。这个规则是需要根据线上的用户输入不断更新的，这个逻辑放到代码里面是不合适的，需要查找一个规则引擎。
之前就了解过规则引擎，从网上搜了一下drools，看了它的优缺点，我觉得最主要的缺点是，1.学习成本高，有的人光学习部署他就花了3个月，规则语言学习起来和学习一门新的语言差不多了。2.规则生成的代码没有办法单步调试。因此考虑其他的规则引擎，规则最好是用我们比较熟悉的语言，在网上找来找去，搜索了js，python，sql，还真让我给搜到了sql在物联网上用于规则引擎，阿里，腾讯，百度，亚马逊都用它来实现规则引擎。我可以仿照他们，用mysql的存储过程来做规则引擎，可以按模块来组织代码，修改的时候，只测试改动的模块就好了。至于存储过程执行的效率没有规则引擎优化后的效率高，这点代价对于学习代价来说，可以忽略不计。至于存储过程的调用占用数据库的CPU，这个以后如果情况比较严重的话，可以把存储过程放到从库上面。到此算是把规则引擎的方案定下来了。
然后一个疑问就出来了，存储过程出来的时间应该比规则引擎出来的时间早，为什么其他人不用存储过程来做规则引擎，而是要重新定义规则引擎呢。我猜想,原因如下 1.Rete算法的出现，使人们觉得应该用rete算法实现一种规则引擎.2.设计系统的时候考虑尽可能不占用数据库的资源，能用应用服务器干的事情就不用数据库干.3.mysql存储过程出来的时间比较晚,没有存储过程这个选择。
到现在，各大互联网公司再制定规则引擎的时候，全部都选择程序员最熟悉的sql脚本，算是反思之后的优化吧
然后再反过来看网上介绍自己公司用drools做规则引擎的，只能说是没有深入了解，或是踩坑之后没后及时总结，寻找更好的解决办法，人云亦云的架构师。可以设想如果用drools来做互联网金融的规则引擎，初期的学习成本就不说了，每招一个人，都要教他如何写规则，由于不能单步调试，各种踩坑，整个公司的执行效率有多低，就可想而知了