1. 阿里巴巴演算法工程師需要掌握什麼技能
1、熟悉java，有大訪問量系統開發經驗；
2、熟練使用Spring、Mybatis等開源框架，熱愛開源技術；
3、熟悉Linux，熟悉MySQL或其他資料庫並了解SQL優化，對NoSQL、消息隊列等有深入的理解；
4、熟悉TCP/IP、HTTP等網路協議；
5、對Elasticsearch、Drools、Dubbo、JVM、服務治理等技術
6、熟練mvc的設計和開發工作，熟悉2種以上的php開發框架，如zend，yii，laravel，熟悉laravel 優先；
7、熟悉PHP+MySQL開發和維護，熟悉LAMP／LNMP環境下的開發工作
8、熟悉laravel框架，了解php composer優先考慮；
9、熟悉前端開發技術，如html5、css3、javascript等；
10、熟悉rest 。
2. 如何成為阿里巴巴演算法工程師
1、熟悉Java，有大訪問量系統開發經驗；2、熟練使用Spring、Mybatis等開源框架，熱愛開源技術；3、熟悉Linux，熟悉MySQL或其他資料庫並了解SQL優化，對NoSQL、消息隊列等有深入的理解；4、熟悉TCP/IP、HTTP等網路協議；5、對Elasticsearch、Drools、Dubbo、JVM、服務治理等技術6、熟練mvc的設計和開發工作，熟悉2種以上的php開發框架，如zend，yii，laravel，熟悉laravel優先；7、熟悉PHP+MySQL開發和維護，熟悉LAMP／LNMP環境下的開發工作8、熟悉laravel框架，了解phpcomposer優先考慮；9、熟悉前端開發技術，如html5、css3、javascript等；10、熟悉rest。
3. 究竟什麼才是真正的規則引擎
可能很多人還不了解規則引擎是什麼東西，或者不知道規則引擎究竟有什麼用。我們都知道工作流引擎，也聽說過JBoss下面有個Drools，或者我們知道 weblogic或者Oracle也有自己的Business Rule，我們可能還聽說過ILOG被IBM收購了，如果我們研究微軟的WWF，可能也知道其中有RuleSet等內容。國內的一些web快速開發平台，也提到了規則引擎。
在我們的印象中，我們感覺規則引擎就是解決業務邏輯層的實現問題的。因此我們理所當然的覺得工作流中的某個節點的邏輯處理，應該可以用規則引擎來解決，那麼工作流本身的邏輯也應該可以由規則引擎來解決。另外我們也會覺得，平時項目當中的業務邏輯應該都可以用規則引擎來解決。
但是當我們在使用上述這些規則引擎，卻發現很難和我們實際應用的業務邏輯層的業務邏輯實現相對應。
我們以JBoss的Drools為例，由於其規則引擎使用了匹配規則的方式來進行，因此在應用這些規則引擎時。首先需要將我們具體應用中的業務邏輯做抽象，抽象成一條條規則之後，再打包成一個規則包。一個規則包相當於一個智能塊。當數據傳遞給這個智能塊後，系統會以匹配的方式應用滿足條件的邏輯處理。
當採用這種方式時，應該說邏輯更抽象了，在一個更高的層次加以抽象化的定義。但是也使得規則引擎的應用得到了很大的限制。
首先這種抽象本身需要一個復雜的分析過程，這需要有很強的分析設計能力。另外我們平時具體應用中的業務邏輯層，大量的邏輯都是對實際數據的處理，很多時候還是一個批量數據的處理，甚至有些邏輯需要的參數我們並不能定義在規則中，而是在資料庫表中進行配置。因此我們常見的業務邏輯層的開發，並不能先設計出一個數據模型，然後再在此基礎上抽象邏輯。
因此我們發現Drools等規則引擎很難用，根本不是我們所需要的那樣。
我們研究規則引擎也有一段時間了。有時候我們發現自己做的規則引擎並不是一個規則引擎。因為我們和像Drools這些規則引擎有很大的差別。但我們確實解決了業務邏輯層的業務邏輯配置問題。應該說我們的更實用一些。但是我們卻沒法去實現JSR94標准。我們不光處理業務邏輯，還把所有業務邏輯層需要處理的操作全部採用規則配置的形式，包括資料庫處理邏輯等。
4. 求Rete演算法實現代碼
Rete 在拉丁語中是 」net」 ，有網路的意思。 RETE 演算法可以分為兩部分：規則編譯（ rule compilation ）和運行時執行（ runtime execution ）。
編譯演算法描述了規則如何在 Proction Memory 中產生一個有效的辨別網路。用一個非技術性的詞來說，一個辨別網路就是用來過濾數據。方法是通過數據在網路中的傳播來過濾數據。在頂端節點將會有很多匹配的數據。當我們順著網路向下走，匹配的數據將會越來越少。在網路的最底部是終端節點（ terminal nodes ）。在 Dr Forgy 的 1982 年的論文中，他描述了 4 種基本節點： root , 1-input, 2-input and terminal 。下圖是 Drools 中的 RETE 節點類型：
Figure 1. Rete Nodes
根節點（ RootNode ）是所有的對象進入網路的入口。然後，從根節點立即進入到 ObjectTypeNode 。 ObjectTypeNode 的作用是使引擎只做它需要做的事情。例如，我們有兩個對象集： Account 和 Order 。如果規則引擎需要對每個對象都進行一個周期的評估，那會浪費很多的時間。為了提高效率，引擎將只讓匹配 object type 的對象通過到達節點。通過這種方法，如果一個應用 assert 一個新的 account ，它不會將 Order 對象傳遞到節點中。很多現代 RETE 實現都有專門的 ObjectTypeNode 。在一些情況下， ObjectTypeNode 被用散列法進一步優化。
Figure 2 . ObjectTypeNodes
ObjectTypeNode 能夠傳播到 AlphaNodes, LeftInputAdapterNodes 和 BetaNodes 。
1-input 節點通常被稱為 AlphaNode 。 AlphaNodes 被用來評估字面條件（ literal conditions ）。雖然， 1982 年的論文只提到了相等條件（指的字面上相等），很多 RETE 實現支持其他的操作。例如， Account.name = = 「Mr Trout」 是一個字面條件。當一條規則對於一種 object type 有多條的字面條件，這些字面條件將被鏈接在一起。這是說，如果一個應用 assert 一個 account 對象，在它能到達下一個 AlphaNode 之前，它必須先滿足第一個字面條件。在 Dr. Forgy 的論文中，他用 IntraElement conditions 來表述。下面的圖說明了 Cheese 的 AlphaNode 組合（ name = = 「cheddar」 ， strength = = 「strong」 ）：
Figure 3. AlphaNodes
Drools 通過散列法優化了從 ObjectTypeNode 到 AlphaNode 的傳播。每次一個 AlphaNode 被加到一個 ObjectTypeNode 的時候，就以字面值（ literal value ）作為 key ，以 AlphaNode 作為 value 加入 HashMap 。當一個新的實例進入 ObjectTypeNode 的時候，不用傳遞到每一個 AlphaNode ，它可以直接從 HashMap 中獲得正確的 AlphaNode ，避免了不必要的字面檢查。
<!--[if !supportEmptyParas]-->
2-input 節點通常被稱為 BetaNode 。 Drools 中有兩種 BetaNode ： JoinNode 和 NotNode 。 BetaNodes 被用來對 2 個對象進行對比。這兩個對象可以是同種類型，也可以是不同類型。
我們約定 BetaNodes 的 2 個輸入稱為左邊（ left ）和右邊（ right ）。一個 BetaNode 的左邊輸入通常是 a list of objects 。在 Drools 中，這是一個數組。右邊輸入是 a single object 。兩個 NotNode 可以完成『 exists 』檢查。 Drools 通過將索引應用在 BetaNodes 上擴展了 RETE 演算法。下圖展示了一個 JoinNode 的使用：
Figure 4 . JoinNode
注意到圖中的左邊輸入用到了一個 LeftInputAdapterNode ，這個節點的作用是將一個 single Object 轉化為一個單對象數組（ single Object Tuple ），傳播到 JoinNode 節點。因為我們上面提到過左邊輸入通常是 a list of objects 。
<!--[if !supportEmptyParas]-->
Terminal nodes 被用來表明一條規則已經匹配了它的所有條件（ conditions ）。 在這點，我們說這條規則有了一個完全匹配（ full match ）。在一些情況下，一條帶有「或」條件的規則可以有超過一個的 terminal node 。
Drools 通過節點的共享來提高規則引擎的性能。因為很多的規則可能存在部分相同的模式，節點的共享允許我們對內存中的節點數量進行壓縮，以提供遍歷節點的過程。下面的兩個規則就共享了部分節點：
這里我們先不探討這兩條 rule 到的是什麼意思，單從一個直觀的感覺，這兩條 rule 在它們的 LHS 中基本都是一樣的，只是最後的 favouriteCheese ，一條規則是等於 $cheddar ，而另一條規則是不等於 $cheddar 。下面是這兩條規則的節點圖：
Figure 5 . Node Sharing
從圖上可以看到，編譯後的 RETE 網路中， AlphaNode 是共享的，而 BetaNode 不是共享的。上面說的相等和不相等就體現在 BetaNode 的不同。然後這兩條規則有各自的 Terminal Node 。
<!--[if !supportEmptyParas]-->
RETE 演算法的第二個部分是運行時（ runtime ）。當一個應用 assert 一個對象，引擎將數據傳遞到 root node 。從那裡，它進入 ObjectTypeNode 並 沿著網路向下傳播。當數據匹配一個節點的條件，節點就將它記錄到相應的內存中。這樣做的原因有以下幾點：主要的原因是可以帶來更快的性能。雖然記住完全或 部分匹配的對象需要內存，它提供了速度和可伸縮性的特點。當一條規則的所有條件都滿足，這就是完全匹配。而只有部分條件滿足，就是部分匹配。（我覺得引擎 在每個節點都有其對應的內存來儲存滿足該節點條件的對象，這就造成了如果一個對象是完全匹配，那這個對象就會在每個節點的對應內存中都存有其映象。）
2. Leaps 演算法：
Proction systems 的 Leaps 演算法使用了一種「 lazy 」方法來評估條件（ conditions ）。一種 Leaps 演算法的修改版本的實現，作為 Drools v3 的一部分，嘗試結合 Leaps 和 RETE 方法的最好的特點來處理 Working Memory 中的 facts 。
古典的 Leaps 方法將所有的 asserted 的 facts ，按照其被 asserted 在 Working Memory 中的順序（ FIFO ），放在主堆棧中。它一個個的檢查 facts ，通過迭代匹配 data type 的 facts 集合來找出每一個相關規則的匹配。當一個匹配的數據被發現時，系統記住此時的迭代位置以備待會的繼續迭代，並且激發規則結果（ consequence ）。當結果（ consequence ）執行完成以後，系統就會繼續處理處於主堆棧頂部的 fact 。如此反復。
rule
when
Cheese( $chedddar : name == " cheddar " )
$person : Person( favouriteCheese != $cheddar )
then
System.out.println( $person.getName() + " does likes cheddar " );
end
rule
when
Cheese( $chedddar : name == " cheddar " )
$person : Person( favouriteCheese == $cheddar )
then
System.out.println( $person.getName() + " likes cheddar " );
end
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/icefishchwd/archive/2007/01/22/1489668.aspx
5. 誰能介紹一些關於規則引擎方面的書籍，論文參考用！
基於規則引擎的企業服務開發模式
陶曉俊,朱敏
(華東師范大學 信息科學技術學院 計算中心,上海 200062)
摘要:本文圍繞規則引擎技術分離業務流程和業務規則的思想,探討並提出一套有效使用規則引擎技術開發企業服務應用系統時所遵循的開發模式,其中包括設計一種基於規則引擎的企業服務模型;提出實際開發過程中緊密結合規則引擎思想,使用規則引擎技術實現企業服務應用的具體步驟和方法.
關鍵詞:規則引擎 JSR-94 Rete演算法 Drools
Pattern of Building Enterprise Services with Rule Engine
TAO Xiao-jun,ZHU Min
(Computer Center, East China Normal University, Shanghai, 200062, China)
Abstract:This article will study and advance a pattern which is based on the idea of rule engine for practical building enterprise services that using rule engine technology effectively and handy. The pattern includes a model of enterprise services based on rule engine, and the step and process of developing enterprise services using rule engine technology.
Key Words:Rule Engine JSR-94 Rete Arithmetic Drools
1. 引言
規則引擎是用以管理和自動實現業務規則的軟體系統,其主要實現的功能是存儲,分類和管理規則,驗證規則的一致性,通過規則推斷其它規則,聯系規則和執行這些規則的應用程序,其中的規則主要是指企業或商務業務邏輯,法律條款,企業政策等.規則引擎概念的思想是從軟體的應用邏輯中分離出商業規則,以實現商業應用的靈活性.在傳統的企業服務應用程序開發模式下,業務邏輯被直接固定在應用程序代碼中,這使得應用程序維護復雜並且代價昂貴,變化的商業規則和業務流程總是引起對應用程序的頻繁修改,尤其面臨動態商業模型和業務流程的挑戰時,傳統模式下開發的應用程序往往面臨全面和代價高昂的修改,甚至設計變化.解決這個問題就需要採用新的開發模式,將業務邏輯從代碼層剝離.使用規則引擎恰恰提供了一個將業務處理和業務規則處理分離,共用和統一管理維護業務規則的系統開發構架.本文以下探討的就是基於規則引擎的企業服務應用開發模式,其中包括基於規則引擎的企業服務模型和基本的開發步驟和方法.
2. 基於規則引擎的企業服務模型
設計明確和有效的系統模型是企業服務系統得以順利進行的前提.圖1設計了一個簡單的基於使用符合JSR-94標準的規則引擎及其模式開發的企業服務應用程序的體系結構.
圖1
"圖1"描述的企業服務體系分為三個部分:
應用程序/數據獲得系統:捕獲和存儲應用程序提交的所有數據,是業務服務的使用者.主要功能是提交業務請求和處理業務判定.
業務服務:通過具體實現的可調用的網路伺服器或者API,調用選定的規則引擎來執行業務規則邏輯或對業務規則邏輯進行運算,產生反饋信息和數據.同時也提供方便和有效維護業務規則邏輯的功能.
支持服務:提供業務服務使用者所提交的相關數據,即規則引擎執行業務規則或運算業務規則所需要的相關數據或應用程序或服務介面.
3. 基於規則引擎的企業服務開發模式中的步驟和方法
在基於規則引擎的企業服務開發模式中,至關重要的原則是:(1)分離工作流程和業務規則;(2)形式化地描述業務規則.在這個開發模式過程中,這兩個原則貫穿始終.分離工作流程和業務規則的目的在於將關鍵的業務判斷規則和業務事件響應提取出來,置於系統的公共部位(業務服務),供不同的應用程序工作流程使用,並且便於維護和管理.這是此模式下開發系統得以順利進行的前提.形式化地描述業務規則的目的則是將業務規則以一種能夠被規則引擎處理的形式描述和表示,使業務規則可被運算化,使應用程序可以按照即定義的約定通過一個服務層來訪問這些規則.
以下提及和討論的開發模式中的方法和原則都圍繞著以上兩個原則展開.
3.1 使用決策表提取規則
在基於規則引擎的企業服務開發模式中首先要解決的問題是明確企業應用中有哪些規則以及對應的業務判定.商業事務中條件元素的集合構成規則,規則決定判定和反饋,在散亂的企業業務中初步提取規則和對應的判定可以使用決策表的方法.
規則1
規則2
……
規則i
條件1
條件值
條件2
……
條件j
判定1
是否反饋
判定2
……
判定k
表1
"表1"給出的是決策表的一般格式.參照"圖一"所示模型,其中條件將成為系統中的數據域,條件值則是對應的數據,是支持服務管理和維護的對象,同時是應用程序/數據獲得系統捕獲和提交的對象.若干條件及其值的集合構成規則,是業務服務管理和維護的對象,也是規則引擎處理的根據.判定是業務服務通過規則引擎處理給出的反饋,最後由應用程序/數據獲得系統接收.
下面使用一個企業決定銷售人員當月銷售獎金的例子來進一步說明決策表的使用:
A
B
C
D
E
F
G
1
rule1
rule2
rule3
rule4
rule5
rule6
2
achieveTarget
N
N
N
Y
Y
Y
3
saleVolume
preMonth
>=10k
<10k
=10k
4
warn
Y
N
N
N
Y
N
5
amortization
0%
1%
2%
2%
2%
3%
表2
表2中的"achieveTarget"表示條件"完成銷售指標";"saleVolume"表示條件"銷售額";"amortization" 表示判定"提成";"warn"表示判定"提出警告";"preVolume"表示數據"上月銷售額".
在"表2"中,列A描述了應用中所涉及的條件和系統處理後的判定,與各個條件或者判定同行的單元格中的值組合構成列B至列G,列B至列G中的每一列都是通過決策表得以分離的規則,規則通過條件值集合和判定反饋值的形式得以描述.例如規則2(rule2)描述的業務規則是:若沒有完成銷售指標,且銷售額大於上月銷售額,那麼不給警告,並且判定提成比率為1%.規則5(rule5)描述的業務規則是:若完成銷售指標,且銷售額小於或等於上月銷售額,那麼給予警告,並且判定提成比率為1%.在實際的應用中可以通過對企業成文或不成文商業規則的總結和歸納來生成決策表,在必要時,例如商業規則不明確時也可以通過對條件組合的窮舉來制定決策表,在以後的開發過程中再進行精簡.
分離商業規則是基於規則引擎開發企業應用的前提,它是基於規則引擎的企業服務開發模式中的第一步,也是必須和最重要的步驟.如果使用本文提供的決策表方法可以比較方便地分離業務邏輯和商業規則,比較清晰准確地描敘規則,並且具有與基於規則引擎的企業服務模型結合比較緊密的特點,這一特性使其可以對後續開發步驟中問題的解決提供有力支持.
3.2 分析和解決規則沖突.
在分離和提取出規則之後,必須考慮規則之間的沖突,這里提到的沖突主要是指由於規則之間同一條件的值域相交而引起的判定歧義.如果規則之間存在沖突而沒有得到解決將造成判定結果的不確定,使規則引擎的處理不能正確進行.我們可以通過使用決策網格來偵測規則之間的沖突.具體的做法是將各條規則依次置於網格的行首和列首,網格中的每一個單元表示對應規則的交叉點,用以記錄相交的規則或者規則集合為真時,反饋值是否發生歧義.判斷規則是否沖突的依據是相交規則所包含條件值域的交集以及各個判定的反饋值,具體流程如"圖2"所示:
圖2
以2.1中得到的規則為例,使用決策網格分析對於判定amortization的反饋,各條規則之間的沖突情況,結果如"表3"所示.
rule1
rule2
rule3
rule4
rule5
rule6
rule1
NC
Y[1,2]
N
N
N
N
rule2
Y[1,2]
NC
Y[2]
N
N
N
rule3
N
Y[2]
NC
N
N
N
rule4
N
N
N
NC
Y[1]
N
rule5
N
N
N
Y[1]
NC
Y[1,2]
rule6
N
N
N
N
Y[1,2]
NC
表3
"表3"清晰地描述了各條規則之間的沖突情況,其中Y表示規則可能同時為真,並且有沖突,跟隨其後的"[]"中指出具體發生沖突的判定名,判定序號或判定的描述;N表示規則沒有沖突或者不可能同時發生.
在明確了規則之間的沖突關系之後,自然必須考慮如何解決沖突.在本文中我們提出三種解決規則沖突的方案:(1)優先順序模式;(2)隊列模式;(3)常用模式
優先順序模式:設定規則的優先順序順序,在規則發生沖突時採納較高優先順序規則的判定反饋.有利於保持業務處理結果的長期穩定性,適用於業務處理規則比較明確的企業應用
隊列模式:先進先出原則,即先使用原則.在一個時間段內集中批處理業務時,若發生規則沖突,則採納先使用(前一次或第一次處理已使用)規則的判定反饋.有利於保證統一批次業務處理結果的一致性,適用於有業務高峰的企業應用.
常用模式:記錄和參考業務處理中規則的使用頻率(規則為真的頻率),在發生規則沖突時採納使用頻率較高或較低的規則反饋.有利於根據業務開展情況靈活適用規則,適用於業務開展情況多變的企業應用.
在一個企業應用服務中,以上提出的規則沖突解決方案可以單一使用也可以結合使用,以構成企業應用的規則沖突解決機制.在沒有採取規則沖突解決方案的情況下,一般規則引擎會採用LIFO (last in, first out)原則解決規則沖突,但是對於一個成功的基於規則引擎開發的企業應用,一套規則沖突解決機制是必不可少的.
3.3 形式化描述規則
規則集的沖突問題得到解決之後,基於規則引擎的企業服務開發模式的下一步是要形式化地描述規則,使其具有可代碼化和可運算化的性質.當前的規則引擎一般都是基於Dr. Charles L. Forgy 於1979年提出的Rete演算法(網路演算法).Rete演算法的基本思想是組織一個有效的辨別網路,通過數據在網路中的傳播來過濾數據.Rete演算法的具體做法是首先建立一個根結點(root node)作為數據對象進入辨別網路的入口,根據規則所包含的條件建立測試結點構成辨別網路,在網路的最底層構建若干終結點(terminal node)描述相應的規則.數據對象進入辨別網路之後經過途徑結點,最終到達某個終結點,激活這個終結點所描述的規則.根據Rete演算法的特性,要求將規則分割為LHS(left hand side)和RHS(right hand side),LHS由規則的條件部分組成,決定辨別網路中測試結點的生成,RHS由規則的判定部分組成,決定辨別網路中終結點的生成.
以2.1中得到的規則為例,可以採用在提取規則步驟中得到的決策表來解決問題,對於各個規則,其所在的列條件值構成它的LHS,判定反饋值則構成它的RHS.由此,每一條規則都可以被形式化地描述為:
形式化地描述規則為基於規則引擎的企業服務開發模式中後續的將規則代碼化過程做了鋪墊.
3.4 設計業務流程
與通常的設計模式相同,基於規則引擎的企業服務開發模式也包含和關注企業服務的業務流程設計.由於實現了業務流程與業務規則的分離,使得業務流程的設計得到很大的簡化,業務流程中不再需要設計繁瑣和龐大的條件判斷,大大減輕了業務程序的負擔.業務流程的設計原則應遵從"圖1"描述的服務模型,設計方法則採用與以往設計模式相同的UML方法,在本文中不作詳細的討論,只以2.1中提出的例子為例,給出相應的業務流程活動圖來直觀說明分離業務流程與業務規則之後使得業務流程設計得到簡化的程度.
圖3
從"圖3"中可以清晰地看到,業務流程已不包含業務邏輯,當業務邏輯改變時,不需要對業務流程作出改變.
3.5 業務規則代碼化和業務流程代碼化
代碼化的步驟既是企業服務具體得到實現的過程,簡而言之就是程序代碼實現的過程.在這個過程中,需要遵從前序步驟的設計和結果,並且圍繞"圖1"描述的服務模型展開.在此以2.1中提出的例子為例,選用Java語言和"Drools"規則引擎來實現代碼化.本文只給出需要實現的類及其簡述,而不給出具體實現代碼.
應用程序部分的實現
SellApplication.class 捕獲數據,提交業務判定請求,接收反饋,實現業務流程.
SalesPerson.class 記錄銷售人員相關數據的數據對象.
FeedBack.class 記錄判定和反饋數據.
支持服務部分的實現
AchieveTargetService.class 負責給出銷售人員完成銷售指標的情況.
SaleVolume.class 負責提供銷售人員月和上月的銷售額.
業務服務部分的實現
AmortizationService.class 接受業務判定請求,調用規則引擎服務,反饋判定
規則的代碼化
以"表1"中的rule1為例,其對應"Drools" 規則引擎的代碼如下
rule "rule1"
salience -100 //優先順序設定
when //LHS
SalesPerson(achieveTarget == false, SaleVolume <= 100000)
$sa: SellApplication()
$fb: FeedBack()
then //RHS
fb.setWarn(true);
fb.setAmortization("0%");
sa.setFeedBack(fb);
end
4.結束語
本文提出的基於規則引擎構架的企業服務開發模式緊密地與規則引擎思想相結合,提出的步驟和方法能夠很好地幫助開發人員在開發企業應用服務過程中分離業務流程和業務規則,明確業務規則,並且使得這些業務規則具有可描述化,可用化的性質,最終得以在應用服務中實現作用.雖然規則引擎的應用還不廣泛,不深入,但是其概念和理論已經比較成熟,針對於企業服務應用,尤其在動態商業模式下的企業應用有著明顯的優勢.在實際的企業應用服務開發過程中,引入基於規則引擎構架的企業服務開發模式將使得企業服務應用具有更高的可維護性和更高的靈活性,具有推廣使用的價值.
參考文獻:
[1] Malcolm Chisholm.How to Build a Business Rules Engine [M]. USA:Morgan Kaufmann,2003.11
[2] Ian Graham.Business Rules Management and Service Oriented Architecture [M]. USA:Wiley,2007.01
[3] (美)伽瑪 等著,李英軍 等譯.設計模式[M]. 北京:機械工業出版社,2005.06
[4] (美)迪達等 著,李宏東等 譯,模式分類(原書第2版)[M]. 北京:機械工業出版社,2003.09
6. drools 是什麼
Drools（JBoss Rules ）具有一個易於訪問企業策略、易於調整以及易於管理的開源業務規則引擎，符合業內標准，速度快、效率高。業務分析師或審核人員可以利用它輕松查看業務規則，從而檢驗是否已編碼的規則執行了所需的業務規則。
JBoss Rules 的前身是Codehaus的一個開源項目叫Drools。最近被納入JBoss門下，更名為JBoss Rules，成為了JBoss應用伺服器的規則引擎。
Drools是為Java量身定製的基於Charles Forgy的RETE演算法的規則引擎的實現。具有了OO介面的RETE,使得商業規則有了更自然的表達
7. 關於發動機引擎書籍
內燃機工作原理方面的書籍很多，有海伍德的《internal combustion engine fundamental是》英文版、《Internal Combustion Engine Handbook: Basics, Components, Systems, and Perspectives》等。你可以到MIT或者網上搜，關於內燃機的書很多，每本書的側重點不同，根據自己的需要，合理地選擇適合自己的書。
關於內燃機製造工藝方面的書籍，我不了解。據說馬勒出過這方面的書。
國外比較權威的汽車書籍出版有SAE，你可以去官網查查。
僅供參考
8. drools規則的性能跟if else比較哪個好
1.一樣的If--Then 句式與Rete引擎
三者都會把原來混亂不堪的if---else---elseif----else謎團，
拆成N條帶優先順序的"If 條件語句 then 執行語句" 的句式。
三者都主要使用foreward-chaining的Rete引擎，按優先順序匹配條件語句，執行規則語句。
規則執行後會引發事實的變化，引擎又會重新進行條件匹配，直到不能再匹配為止，Rete的演算法保證了效率的最高。
2.開發人員使用的規則語言
2.1 Drools的XML框架+Java/Groovy/Python嵌入語言
Drools的用XML的<Conditons>、<Consequence> 節點表達If--Then句式，而裡面可以嵌入上述語言的代碼作為判斷語句和執行語句。
其中Java代碼會使用Antlr進行解釋，而Groovy和Python本身就是腳本語言，可以直接調用。
Drools的聰明之處在於，用XML節點來規范If--Then句式和事實的定義，使引擎干起活來很舒服。
而使用Java,Groovy等原生語言來做判斷和執行語句，讓程序員很容易過渡、移植，學習曲線很低。