前言
物聯網的強大功能主要來自於它使我們能夠實時做出更準確的決策的能力，這些在通知、自動化和預測性維護上都有所體現。因此我們需要能對實時資料進行實時響應的工具，答案就是規則引擎。規則引擎可以通過攝取實時資料，對該資料進行推理並根據該推理過程的結果呼叫自動操作或者第三方API來履行職責。
IoT案例探討
這裡有一個智慧農業的場景：
如果某種植物的生長需要維持恆溫恆溼的環境，溫度為18～20℃，相對溼度為85~90%。如果溫度低於18℃，我們需要升溫並對溼度進行補充；當高於20℃，我們需要降溫並對溼度進行檢查。
您可以在應用程式中輕鬆實現上述的規則或邏輯。但是，如果您將接到了其他一些需求，例如:
- 如果存在大量邏輯，那麼您將如何有效的編寫和處理它們? (很好的程式碼設計模式)
- 如果邏輯經常更改，並且您通常在應用程式中編寫邏輯程式碼，那麼您將如何管理或頻繁更改程式碼? (避免頻繁部署)
- 設計應用程式以便讓業務人員可以輕鬆維護和理解。（非技術成員使用）
- 如果您必須將所有業務邏輯都放在一個專案中，和其他所有應用程式分開，那麼您將在哪裡儲存它? （微服務架構）
為了在我們的應用程式中滿足所有這些要求，但是在啟動規則引擎之前，讓我們先了解一下規則引擎是什麼?
什麼是規則引擎？
下面是來自Martin Fowler的一篇文章“我應該使用規則引擎嗎？”
規則引擎是一種工具，可以更輕鬆地使用此計算模型進行程式設計。它可能是完整的開發環境，也可能是可與傳統平臺一起使用的框架。近年來，我所見的大多數工具都是設計為適合現有平臺的工具。曾經有一種想法是使用這樣的工具來構建整個系統，但是現在人們（明智地）傾向於僅將規則引擎用於系統的各個部分。生產規則計算模型最適合僅解決一部分計算問題，因此規則引擎可以更好地嵌入到較大的系統中。
您可以自己構建一個簡單的規則引擎。您所需要做的就是建立一堆帶有條件和動作的物件，將它們儲存在一個集合中，然後遍歷它們以評估條件並執行這些動作。但是大多數情況下，當人們提到“規則引擎”時，它們是指專門用來幫助您構建和執行規則引擎的產品。用於指定規則的技術可能有所不同，包括人們將API描述為Java物件的API，表達規則的DSL或允許人們輸入規則的GUI。高效的執行引擎有助於使用專門的演算法（例如Rete演算法）快速評估數百條規則的條件。
規則引擎的一個重要屬性是連結 -一條規則的操作部分以改變另一條規則的條件部分的值的方式更改系統狀態。連結聽起來很吸引人，因為它支援更復雜的行為，但很容易導致很難推理和除錯。
這是一個執行在資料上的系統程式, 如果任何條件匹配，那麼它就會執行相應的操作。
在上圖中，顯示了我們以規則(if-then)的形式收集知識並將其儲存在任何地方。規則可以儲存在檔案或資料庫之類的任何儲存中。現在，規則引擎根據需求選擇規則，並在輸入資料或查詢上執行它們。如果有任何模式/條件匹配，則它將執行相應的操作並返回結果或解決方案。
規則引擎的型別
前向連結(Forward-Chaining)引擎
使用前向連結的推理引擎應用一組規則和事實來推導結論，搜尋規則，直到發現IF子句為真為止。根據規則匹配新的或現有事實的過程稱為模式匹配，它是由前向連結推理引擎通過各種演算法執行的，如Linear、Rete、Treat、Leaps等。
當發現條件為真時，引擎將執行THEN子句，這將導致向其資料集新增新資訊。換句話說，引擎從大量事實開始，並應用規則從這些事實中得出所有可能的結論。這就是“前向連結”這一名稱的由來——即推理引擎從資料開始，通過推理向前得到答案，這與反向連結相反，後者的工作方式是相反的。
應用案例：目前市場上的大多數物聯網平臺實際上都有這種型別的規則引擎。下面是幾個基於前向連結引擎的自動化工具的例子，這些工具在我們寫這篇部落格的時候已經在市場上出現了:Redhat Drools, Cumulocity, Eclipse Smart Home, AWS Rules, Thingsboard等等。
條件動作(Condition-Action)引擎
基於條件-動作(CA)規則引擎屬於前向連結引擎，但存在一些相關的差異，特別是在物聯網領域。與前向連結引擎相比，條件-動作規則引擎不允許多個條件，這使得它們一方面在邏輯表達能力上非常有限，另一方面——可伸縮性更強。條件操作規則引擎(如果-那麼)有時使用ELSE語句進行擴充套件(如果-那麼- 或者 - 那麼)。
應用案例：物聯網領域中這種規則引擎最流行的例子之一是ifttt.com服務。
流處理(flow processing)引擎
基於流的程式設計是一種將應用程式定義為“黑盒”流程網路的程式設計正規化。這些程式，即函式，被表示為節點，通過訊息傳遞在預定義的連線之間交換資料。節點可以被不斷地重新連線，從而形成不同的應用程式，而不必更改它們相關聯的功能。
基於流的程式設計(FBP)自然是“面向元件的”。FBP的好處包括:
- 更改連線接線而不重寫元件。
- 本質上是併發的——適合多核CPU世界。
應用案例：
Yahoo! Pipes和Node-RED是使用基於流的程式設計構建的規則引擎的兩個例子。隨著“serverless”計算的引入，基於流的程式設計變得更加流行，在“serverless”計算中，可以通過連結函式構建雲應用程式。
IBM的OpenWhisk是一個基於流的程式設計示例，它通過連結雲函式(IBM稱之為動作)實現程式設計。另一種無伺服器編排方法(如AWS step functions)基於有限狀態機規則引擎。
決策樹(decision trees)引擎
捕獲條件規則複雜性的一種流行方法是使用決策樹，決策樹是使用分支方法來說明決策的每一個可能結果的圖。
應用案例：
Drools主要以其基於前向連結的規則引擎而聞名，它有一個可與決策表整合的擴充套件，可以將excel表與嵌入程式碼片段結合使用，以容納任何額外的邏輯或所需的閾值。
有限狀態機(finite state machines)引擎
狀態機可用於根據系統經歷的一組狀態來描述系統。狀態是對等待執行轉換的系統狀態的描述。過渡是在滿足條件或接收到事件時要執行的一組動作。
FSM的概念易於由不同型別的使用者掌握。BRE（業務規則引擎）的主要銷售論點是BRE軟體允許非程式設計師在業務流程管理（BPM）系統中實現業務邏輯。
FSM經常忽略的一件事是狀態暗含著過渡，也就是說，將某種事物建模為狀態的唯一目的是導航特定的決策流程。
這樣做的直接結果是，FSM缺乏可讀性，因為規則變得更加複雜，或者需要將特定的極端情況建模為狀態。由於FSM一次只能執行一個轉換，因此當使用者嘗試引入在某些條件下可能發生的事件時，她需要新增一個新狀態。當狀態數過多時，狀態機的可讀性會大大下降。
規則引擎的優勢
我們可以將給定示例中的所有上述特定要求視為規則引擎的優勢。
- 規則很容易被業務分析師，客戶團隊等任何非技術人員閱讀和編碼。在這裡，您必須專注於“該做什麼”，而不是“該怎麼做”。
- 您可以將所有規則儲存在中心儲存中。這意味著您將擁有所有業務規則和邏輯的中心位置。這將是您的真理之源。
- 邏輯與核心應用程式邏輯分開管理，因此可以對其進行管理和重用。
- 在規則引擎中，我們使用不同的模式匹配和衝突解決演算法，可提供高效能。
- 對於經常變化的需求，我們可以輕鬆地更新規則。無需更改程式碼。
- 如果程式碼包含許多決策點，則程式碼的複雜性會更高。規則引擎可以更好地處理它，因為它們使用業務規則的一致表示形式。
- 不同的應用程式可以將相同的規則引擎用於相同的邏輯。它提高了可重用性。
