在实际工作中，有关于达标推断的业务逻辑
就是谁谁谁 消费满了多少钱。就返多少钱的优惠券
声明：不是drools不好，仅仅是在我遇到的场景下，不合适，不够好
在使用drools的时候发现有例如以下问题：
1、效率低。这是最严重的问题。实际业务环境，用户数量要几十万。还有非常多业务相关的数据。他们要组合推断。实际情况是，插入working memory的fact数量超过万级，程序就開始hang住，gc日志打开后发现，系统不停的gc，用内存查看工具。发现drools生成了大量的内部对象。甚至有内存泄露的趋势。
这里推測。应该是drools为了实现通用性，会把全部的自己定义的实体。转化为它内部的节点。然后还有相关的一大堆附属。可是做得不够好，所以导致了上面的现象
这简直就是没法用了，时间有限，花大把时间把他源代码搞清楚，再看看有没有留出钩子，或者重写源代码，有这时间，还不如我自己实现达标推断了逻辑了呢，这样效率又能得到保证，运维成本还不高。毕竟关系到用户的钱，不能给算错了，遇到问题须要立即定位问题，万一遇到了一个drools的内部问题，说不定要多耽误事呢
实际自己实现的达标推断过程，在万级以内（就是在drools能承受的范围内）。我自己优化后的算法。要比drools实现快10倍
2、不方便。详细体如今数据insert的过程，为了可以满足drl文件里所描写叙述的数据结构以及他们的关系。必须提前构造相关的数据结构。非常费力。
并且这部分逻辑，写不好的话，也会写成一坨。尽管drl鼓吹的更易读，可是带来的副作用就是，外面的工作量非常大
另外就是数据装载，一般都是从数据库读取数据，这里也没有一些api对这里做支持。它的api很多其它是面向内存对象的，并没有考虑到这点
3、社区支持。
这个是我要吐槽的
说是社区活跃文档多啥啥啥的，太tm扯淡了。有个在线聊天的答疑的，进去喊话，从来没人吱声
文档写的那叫一个烂。就是堆砌，根本没考虑到读者的学习路径