了解JBoss Drools Engine

說一個自己比較喜歡的開源產品 JBoss Drools , 很多企業內部大型項目都在使用的規則引擎

該怎么理解規則引擎，到底是個什么東西，我好像沒聽過，我們能用么。

它是配有內置算法及對應數據結構的計算容器，在容器內部可以寫我們的業務規則或計算規則。這套算法在規則引擎內的規則數爆增的情況下，可保計算速率不會有明顯影響。 光是這點，就足夠有吸引力。自己純寫代碼不能避免這個問題。舉個例子，比如有一個場景根據受保人的信息及車況信息來計算他下一年要交多少車險。略想一下，這個問題很簡單么，就是建一個Java Pojo Bean Customer類，然后去針對這個Customer類的各個屬性值在哪個區間內給出對應的車險金額。那我們可以這樣寫：

if((customer.getAge>24||customer.age<40)and (customer.getLoyaltyLevel()==Rang.GOLD) and (customer.getCarAge()<5) abd customer.getCarHit()==0)

{

payment = 2000;

}

else if(...)

else if(...)

else if(...)

...

else

{

}

好，當我們寫了十幾、二十個的else if，這條業務才寫完，然后也沒錯，我們意大利式面條的代碼就出現了，看著有木有好揪心，有密集恐懼癥的童鞋就碰也不想碰這套業務了。

那這種寫法的 大O記號為O(n) ，但如果這些業務規則寫在規則引擎內，它的大O記號一定是O(1)<x<O(2)，而且 很有可能無限趨近于O(1) ，這是因為Drools engine的 ReteOO+Phreak 算法，可以做Node Index, Node Sharing, 對某些運算符優化，消除無用的部分匹配等等。這就是為什么規則數爆增的情況下，計算速率不會有明顯影響。有興趣可以去看看這兩個算法。

那更多的業務情況不會有這么簡單，更多的是幾套子業務規則拼成一個完整的業務，一般情況是，先從前面的子業務規則做收納，把可能有效的信息放在一個集合內。那在后面的業務規則再去把這個集合內的對象遍歷一遍做減法，該修改的修改，該移除移除的。然后得出一個最優解。那代碼就變成 if()else if()...else() + for(if()else if()...else())...，好吧，這又是一份意大利面。說好編程是門藝術呢？怎么編程變成意大利烹飪技呢？？？

然后Drools的規則語法是聲明式的，不是解釋式的。只有把每個業務規則寫進去，把要計算的對象放進Working Memory中，規則引擎自己幫咱們算，我們不需要寫if else，不需要寫for或while。因為Drools的working memory的每個對象會被自動的去匹配所有的規則，它內部的事情就交給Drools的算法吧。我們只要告訴它有什么樣的業務規則就好。Just care what to do, don't worry how to do.

有一次在我把基于Drool寫出來的項目給一客戶看，他面露喜色，這東西很巧嘛。 嘿嘿，靈巧之處還不僅僅在于此。

它 能線上修改業務規則，不需要啟停服務 。在Drools中，業務規則沒有放在Java代碼內，是以單獨的文件形式存放，比如drl(其實是txt)、csv、excel。業務與代碼，業務與數據分離了。只要咱們的Model沒變，只變業務規則，比方說，正好感上公司十周年慶，全場5折，僅限本周。這個需求一下來，我們就得開始去屢我們的意大利面，然后找到修改的地方，改完以后發QA測，產品人員驗收，打包上線。 然而在Drools中，負責產品的人員就可以直接做了，不需要開發人員及QA的介入。有時候產品和開發、QA得解釋半天要上線的規則，開發和QA才能聽明白。這一套流程下來，一兩天去了。如果產品自己做，幾分鐘或半小時就能搞定。 在互聯網+的今天，時間就是市場。

有些人可能覺得這是不是有點夸張，其實真的可以，我們只需要為產品做一個規則管理的Web系統，這套管理系統能檢索到所有的規則，并能增刪改查及仿真。只有產品不要求開發改數據模型，就真心沒開發QA什么事了。有人說，如果我把規則直接放數據庫就好了，為什么還要用Drools？很好，但是您要加的規則不是模板化的怎么辦？如果是多個對象協同計算怎么辦？您是不是要去修改表結構？您也別忽略了Drools 算法的可優化性及潛力。

說了Drools這么多好處，它的缺點也不能不談，它既然內置了一套算法和數據結構，說明它就是有開銷的。它能把Java代碼以外的規則文件并入到JVM內一起協作，也是有開銷的。但是這些開銷是只是業務規則小，計算量小的時候才能體現出來是個問題，如果業務規則復雜和計算量大可以靠它的算法去優化，它的價值就體現出來了。而且這些開銷僅僅是在規則加載的時候比較明顯。 要不說架構是演變出來的，從來就沒有一顆銀彈。

所以不是所有的應用都適合用它，如果只有一個或幾個簡單的規則還是不要用了，為了幾個簡單的業務去學習一個新產品，不值當。它適合比較復雜的業務及業務規則需要實時修改的，它能幫上很多忙。

這里只講了Drools Engine的粗枝大葉，Drools 還有其它的組件，下次再聊。