【正文】 在深入研究規(guī)則 之前，讓我們先看一下設(shè)置的數(shù)據(jù)以及最后安排的位置結(jié)果。這 5 個基準(zhǔn)分析也被發(fā)布在 Texas 大學(xué)中 . Manners 小姐的工作流程 在第一個座位被分配后，一個深度優(yōu)先遞歸不斷重復(fù)進(jìn)行正確的座位分配，直到最后的座位被分配。 Daniel P. Miranker 的論文 Effects of Database Size on Rule System Performance: Five Case Studies中提出了五個基準(zhǔn)分析。她最初設(shè)計男女相鄰而坐，接著她擔(dān)心大家沒有什么共同話題；一個好主人應(yīng)該怎么做呢？因此她決定標(biāo)記每個客人的興趣，這樣她可以不但將客人安排成男女相鄰而坐，并且 確信客人之間（或者左邊或者右邊）會有一個共同的話題。訪問 獲得更多關(guān)于 FIT 框架信息。你可以下載并獲得更多的資料，通過這個 Web 頁面： Fit for rules 下面的頁面顯示 FIT 規(guī)則框架的截圖 使用規(guī)則 FIT，你可以捕捉測試數(shù)據(jù)，將它傳遞到規(guī)則引擎，然后確認(rèn)結(jié)果（使用測試組建文檔）。 這個測試框架建立在 FIT 和 JSR94之上，對于 Jboos 規(guī)則來說是一個獨立的項目。因為輸入的格式對于熟悉規(guī)則的領(lǐng)域的人來說相當(dāng)簡單，它也對“情景測試”有幫助，對這些規(guī)則可以使用不同的情景。因為測試被保存在文檔中，這些方法和需求能夠被保存在同樣的文檔中，為規(guī)則行為的提供一個單獨的真實性約束。它允許規(guī)則測試套件 （功能）在 Word 文檔中捕捉，或 Excel 電子表格中（實際上任何可以保存為 HTML 的工具）。下一節(jié)介紹了一個規(guī)則測試組件。當(dāng)然，最好的想法是讓測試關(guān)注規(guī)則的核心特性，這樣就不需要隨時改變。 . 測試框架 對應(yīng)程序員來說， Junit（或 TestNG）是開發(fā)測試代碼的常用工具，它們也可以用來測試規(guī)則。當(dāng)然，規(guī)則的改變也可能就是會引起測試的錯誤，這種情況下需要編寫新的測試來覆蓋新的規(guī)則行為。更進(jìn)一步說，測試在規(guī)則頻繁變動的環(huán)境下，比規(guī)則更重要。在某方面來說，規(guī)則是編碼（雖然在更高的級別），測試驅(qū)動開發(fā)的許多原則同樣適用。 . 未來的期望 Drools 的將來版本將提供一個規(guī)則庫組件，將直接支持以上的摸式，以及更多。一種相反的可能是使用 XSD/WSDL 產(chǎn)生器產(chǎn)生對這些處理構(gòu)建的類（操作對應(yīng)的規(guī)則）的 XML 綁定。 . Web Services 一種發(fā)布規(guī)則的可能方式是將規(guī)則暴露為 Web 服務(wù)。 . Push 推風(fēng)格 在這種方式中，規(guī)則部署進(jìn)程 /規(guī)則庫推規(guī)則到運行系統(tǒng)中（規(guī)則可能是源碼或二進(jìn)制格式）。拉規(guī)則的觸發(fā)器可以是一個定時任務(wù)（檢查變更），或一個發(fā)到運行時系統(tǒng)的請求（可能使用 JMX 接口）。 . Pull 拉風(fēng)格 在這種方法中，規(guī)則從規(guī)則庫中被拉到運行系統(tǒng)中。 . 一些部署方法 這節(jié)包含一些部署的建議。你接著可以序列化 Package 到一個文件（使用 java 標(biāo)準(zhǔn)序列化）。它也意味著所有編譯錯誤可以在部署到運行系統(tǒng)前獲得并處理。 . 進(jìn)程外規(guī)則構(gòu)建 在這種情況下，規(guī)則在運行時系統(tǒng)外被構(gòu)建成二進(jìn)制格式（例如在一個部署服務(wù)器中）。系統(tǒng)包含 droolspiler規(guī)則編譯器組件構(gòu)建規(guī)則。如果存在錯誤， 你可以從 Package Builder 中獲得它們，好過在部署的時候才發(fā)現(xiàn)問題。因此它通?？梢赃M(jìn)行遠(yuǎn)程發(fā)布，并且綁定規(guī)則到 JNDI 中，就像在容器中使用它們一樣。 RuleBase, RuleBaseLoader . Serializing 序列化 事實上在 Drools 中所有與 RuleBase 有聯(lián)系的對象都是可序列化的。當(dāng) RuleBase 被整體更新時，這是一個有用的選項，對短期存在的 working memory。 PackageBuilder, RuleBase, . RuleBase 編譯好的 Package 被加入 RuleBase。 RuleBase 保存著 Package 的列表，并且合并到其中一個 Package，你需要知道哪一個是你需要合并的 Package（顯然，只有在同樣包名中的規(guī)則可以被合并）。這意味著 package 可能包含一個單獨的新規(guī)則，或?qū)ΜF(xiàn)有規(guī)則的更改；可以建立這樣的 package 然后與在 RuleBase 中的現(xiàn)有 package 合并。在這種情況下，使用 PackageBuilder 從 DRL 源碼建立Package，但是它是可以被部署的二進(jìn)制 Package 對象。如果需要，你當(dāng)然也可以使用 XML 格式的規(guī)則。一個類似的方法是部署 PackageDescr對象，這意味著規(guī)則被預(yù)先解析好（對語法錯誤），但是沒有被編譯成二進(jìn)制格式。 . DRL 和 PackageDescr 一種辦法是將規(guī)則部署為源碼格式。例如說，規(guī)則可以從一個有許多使用中的 working memory 的 rulebase中刪除， RETE網(wǎng)絡(luò)將自動調(diào)整以刪除該規(guī)則而不需要將其它 fact重新設(shè)置一次。為了更新rulebase，需要重新裝載一個新的 rulebase，然后交換出緩 存的 rulebase(任何正在使用舊的 rulebase 的線程可以繼續(xù)使用直到結(jié)束，在這個情況下 rulebase最終會被垃圾處理器收集 )。這個 rulebase 可以被線程共享，每個線程中產(chǎn)生新的 working memory 來處理事務(wù)（然后 working memory 被拋棄）。但 是，因為規(guī)則可以包含相當(dāng)多的強(qiáng)大的邏輯，應(yīng)當(dāng)使用正確的測試、確認(rèn)流程來控制規(guī)則的改變，在將規(guī)則發(fā)布出去之前要確認(rèn)它們正確。許多組織對于產(chǎn)品線的更改有配置管理流程。 Drools 的未來版本將會有一個規(guī)則服務(wù)器組件，用來管理規(guī)則的多個版本（包括鎖定和自動部署）。 規(guī)則引擎為規(guī)則部署開放了很多選項。規(guī)則的特點是用來允許應(yīng)用程序的改變而不用重新部署整個應(yīng)用。這個模塊中有許多例子。 第 8 章 . 示例 . 獲得示例 在 Drools 源代碼中一些示例被當(dāng)作集成測試包含。這 意味著使用 64 位 JVM 在一臺至少 8GB 內(nèi)存的機(jī)器上。這個辦法依賴于環(huán)境是否允許。當(dāng)節(jié)點被共享后，它將減少內(nèi)存的占用，并提升性能。第二種方法是將通用條件放在規(guī)則的開始部分。通用的規(guī)則通過設(shè)置一個新的 fact 觸發(fā)后來的規(guī)則。最好的辦法是使用鏈接重寫規(guī)則。這個方法不一定每次都能適用。簡單地說，在規(guī)則中使用大量的扁平對象導(dǎo)致與硬編碼常數(shù)同樣的問題。大多數(shù)項目有嚴(yán)格的計劃，開發(fā)者通常不可能有時間這樣做。 In a procedural engine, one can build a decision tree and end the evaluation once the data fails to satisfy the conditions at a given level. As the rule count increases, there are more rules the engine has to evaluate. In a procedural approach, the rules have to be sequenced in the optimal order to get the best results. The limitation of sorting the rules in optimal sequence is that many cases it39。通過對兩者評估，可以得到通用性的規(guī)則比硬編碼常量規(guī)則的速度更快。如果我們使用一個RETE 規(guī)則引擎，硬編碼的規(guī)則導(dǎo)致與少數(shù)規(guī)則更少的關(guān)聯(lián)。在一個程序路徑上，規(guī)則必須按照最佳的順序排列，以獲得最好的結(jié)果。為什么會這樣？讓我們看一下兩種不同的規(guī)則 引擎：流程型（ procedural）和 Rete 算法型 在一個流程型引擎中，一旦數(shù)據(jù)無法滿足在給定級別上的條件，引擎可以建立一個決策樹并且結(jié)束評估。 Say we run a mega online store and customers can define their favorites in each of the categories (books, videos, music, toys, electronics, clothing). What happens if a customer has different levels for each category. Using the hard coded approach, one might have to add more rules. If we change the rule and make it more generalized, the same rule can handle multiple categories. If ?lvl // 綁定 remendation level 到 lvl 變量 ?rcat // 綁定 remendation category 到 rcat ?id // 綁定 account id 到 id ?id // 通過 id 找到 favorites 列表 ?rcat // 將 favorite 匹配到 remendation category ?lvl // 匹配 favorite level 到 remendation level Then remend all items in the favorites 如此看來，使規(guī)則具有動態(tài)性，并由數(shù)據(jù)驅(qū)動的價值在哪里呢？顯然，硬編碼規(guī)則要比讓規(guī)則具有通用性更快，但是會影響性能。如果對每一個客戶在分類中有不同的級別，會發(fā)生什么事情？如果使用硬編碼，將不得不增加更多的規(guī)則。讓我們在這個示例上更進(jìn)一步，定義 customer 的 type屬性從 level1 到 level10。 If == level2 ?id // 綁定 到變量 ?id // 通過綁定變量查找 favorites 的列表 Then remend all items in the favorites 通過這樣的改變，能夠顯著的減少規(guī)則的數(shù)量。我們不希望將所有 Customer 都裝載到規(guī)則引擎中。 If == level2 == jackie chan Then remend movies with jackie chan If == level2 == jet li Then remend movies with jet li 我們這樣做的原因一目了然。雖然 accountId 更改了，規(guī)則可以有效地忽略它。讓我們使用更具體的例子說明： If == peter == level2 == jackie chan Then remend movies with jackie chan If == peter == level2 == jet li Then remend movies with jet li 查看示例，第一個問題是“這些規(guī)則是 否應(yīng)用到所有 Customer”，如果確認(rèn)是，則規(guī)則中的第一個條件 是無意義的。 If == abcd == basic ..... Then // do something 上面規(guī)則示例的基本問題是，規(guī)則有太多硬編碼值。管理 100,000 甚至 1,000,000 規(guī)則是非常讓人頭疼的，盡量避免它。有很多問題可以尋找。當(dāng)前描述主要集中在商業(yè)規(guī)則上。這些情況是在智能 AI 系統(tǒng)中，其中的規(guī)則引擎在執(zhí)行時將產(chǎn)生新的規(guī)則，術(shù)語和 Fact。 Employee (name == $aName, department == $aDepartment) (除非你工作在一個部門比人員更多的組織中，這時可以考慮將 department 放在前面 ) 另一些增強(qiáng)正在被開發(fā)，將在未來版本中進(jìn)行說明。 . 重新安排約束條件順序 另一個提高性能辦法的提示是，當(dāng)編寫規(guī)則時，盡量將嚴(yán)格的約束條件放在相對不嚴(yán)格的約束條件前面。因此如果我們反過來，啟用右輸入索引而關(guān)閉左輸入索引，我們獲得下面結(jié)果： Manners 64 僅使用 BetaNode 右輸入內(nèi)存索引 : 8765 毫秒運行時間 現(xiàn)在我們獲得了最佳效果。例如在“ Manners 64 example”測試中，如果我們關(guān)閉右輸入內(nèi)存索引，我們可以獲得下面的結(jié)果 Manners 64 僅使用 BetaNode 左輸入內(nèi)存索引 : 142020 毫秒運行時間 以上甚至比不使用索引更糟糕。這里我們不分析內(nèi)存受限環(huán)境。這里的并不是一個詳細(xì)的基準(zhǔn)測試，只是一些簡單的概括，使得你更容易理解。 Drools 實現(xiàn)一 個自動的索引策略來建立 BetaNode 內(nèi)存的索引。一旦所以被定義，當(dāng)查詢被執(zhí)行后，一個查詢計劃組件被數(shù)據(jù)庫系統(tǒng)用來評估運行該查詢的最佳性能的辦法，有時使用索引，有時不用。另外，也會引起內(nèi)存的消耗。雖然，在某些特殊情況下，用戶可能受限于系統(tǒng)內(nèi)存或其它原因不想啟用索引功能，索引可以單獨在各內(nèi)存上被禁止，通過設(shè)置如下的系統(tǒng)屬性： 例