使用基于微服务的流架构更好地进行大规模的复杂事件处理（第1部分）
基于微服務的流架構與開源規則引擎相結合，使實時業務規則變得容易
這篇文章旨在詳細說明我將OSS業務規則引擎與Kafka風格的現代流消息傳遞系統集成在一起的項目。 該項目的目標（即眾所周知的復雜事件處理（CEP））旨在實現對流數據的實時決策，例如在IoT用例中。
經過大量的寫作，我決定將文章分為兩部分。 在第一部分中，我將重點介紹什么是CEP，為什么有用，并解釋體系結構解決方案以及為什么我們認為對于許多有用的生產用例來說，這是一個好主意。
在第二篇文章中，我將展示一個基于道路交通監控系統的具體示例，并盡可能詳細地說明其制作方式。
因此，事不宜遲，繼續第1部分！
總覽
根據Gartner Inc.的數據，截至2015年，全球企業應用軟件市場價值約為1500億美元。這是一個巨大的市場，其中最常見的應用程序類型之一就是圍繞將某種業務邏輯應用于從各個方面生成的數據這生意。
如今，現代企業應用程序需要連接到更多類型的數據源，隨數據大小和用戶數量擴展，可靠并快速執行。 隨著業務需求和條件的變化，長達一年或更長的自定義應用程序開發周期不具有吸引力，因此甚至在應用程序投入生產之前就已過時。
在大型，全國性，區域性或全球性組織中，或在金融，醫療保健或IT等行業中使用大量數據的組織中，需求保持不變，但必須使用大數據技術來滿足。 這帶來了一系列全新的難題，這些難題使大規模開發企業應用程序的成本變得極為昂貴，并且在IT基礎結構和專有技術要求方面也設置了很高的障礙。
因此，需要一種方法來對各種來源收集的數據運行業務邏輯，這可能是非常大規模的，理想情況下是實時的，例如物聯網類型的應用程序。
了解復雜事件處理（CEP）
顧名思義，復雜事件處理（簡稱CEP）并不那么復雜。 從根本上講，CEP是關于將業務規則應用于流事件數據。 事件數據只是帶有時間戳字段的數據。 此類數據的示例可能是Web服務器的日志條目，購買收據或傳感器數據，所有這些都可以視為恒定的事件流。 在此流數據上應用規則使響應時可以采取有用的操作。
這是一個智能家居的示例，該智能家居的門口有傳感器，智能WiFi路由器和房間移動探測器。 通過CEP將所有數據流式傳輸到家庭服務器中，用戶可以制定如下規則：
擁有一堆這樣的簡單規則，確實會很快使一個聰明的家庭加起來。 實際上，在一些競爭性智能家居“集線器”設備中已經可以購買到這種功能，這些設備使用通用協議從房屋周圍的兼容傳感器設備中讀取信息，然后在滿足某些規則時將操作推回去。
這種示例可以輕松地移植到許多其他域。 例如，在零售中，購買歷史記錄和信標可用于生成個性化，位置敏感的消息或優惠券。 在工業應用中，可以使用相對簡單的邏輯規則（例如，“如果該機器的紅色按鈕點亮，則必須停止它”）組合起來，更容易操作和維護許多機床。
CEP規則引擎與手動編碼
到目前為止，閱讀這些信息的工程師可能不會留下深刻的印象，因為流事件適用簡單的規則。 諸如上述的智能家居用例可以很容易地（很好地說）完全通過使用Python進行手工編碼并在舊用途的PC或Raspberry Pi上運行來處理。
這類項目有哪些部分？
好的軟件體系結構要求嘗試使最容易更改的部分易于更改，但要付出使其他部分更加困難的代價。 最需要改變的部分是什么？ 數據攝取僅在添加新傳感器時才會更改，但是給定傳感器的數據不會突然更改。 摘要中的執行規則始終相同； 變化的是規則本身。 編碼并可以執行的動作并沒有真正改變，但是隨著時間的推移添加新動作應該很容易。
當用例開始擴展并且規則數量增加時，規則處理引擎的效率開始變得重要。 此外，當規則數量增加時，使規則易于編輯不僅是“必備”功能，而且是核心要求。
另一個經常使用的論點是業務邏輯與SDLC的分離。 業務需要比軟件開發更快。 通過使用規則引擎，兩個流在很大程度上可以獨立移動。
CEP被“植入”物聯網應用
CEP幾乎是任何種類的物聯網應用程序的要求，例如智能家居，智能農業，工業4.0或電信數據。 從某種意義上說，這是一項要求，即拋開功能的實現方式，物聯網需要將規則應用于流事件數據。 無論是在單個私人住宅中進行小規模生產，還是在遍布全球的數家工廠中進行大規模生產，都是如此。
根據我們剛剛描述的內容，理想的設計會反對手動編碼的解決方案，并使用所謂的“業務規則處理引擎”。 開源世界中存在著幾種，最著名的是Drools。
Drools：開源業務規則引擎
Drools是在開源項目的JBoss框架下開發的一個開源項目。 這是一個具有長期活躍開發歷史的項目，當前版本為6.5.0。最終版本為Beta 7。 它相當現代，因為它支持Java 8大大改進的API。
Drools具有我們正在尋找的所有特征，其中包括規則引擎，定義良好的DSL定義規則以及基于RETE算法的規則引擎，該引擎經過了優化和非常快速。 此外，文檔非常詳盡，并且有大量書籍可以學習有關如何使用此強大框架的所有知識。
最后，Drools帶有一個稱為Workbench的GUI，它使我們可以可視地創建和編輯規則，而無需編寫代碼。 這是一項致命功能，它將規則的功能置于業務分析的范圍之內。
流傳輸架構為大數據啟用CEP
流架構是CEP的關鍵組件。 CEP的全部重點是通過流數據（近）實時做出決策，而不是像批處理那樣對歷史數據進行分析來采取行動。
CEP涉及敏捷性，并且由于大量簡單規則的相互作用而導致潛在的復雜行為，這些規則都實時應用于內存中的數據。 基于微服務的流式傳輸體系結構正成為現代大規模體系結構的標準。
奧德利（O'Reilly）出版的Ted Dunning和埃倫·弗里德曼（Ellen Friedman）的《流傳輸體系結構》一書詳細探討了流體系結構的優點，該書可免費在線獲得 。 我還在2016年新加坡Strata大會上就這一主題發表了演講。 請去Slideshare看一看 。
一般而言，解決方案將類似于上圖。 收集數據源（例如傳感器，收銀機或日志），并使用輕型ETL將其添加到流中。 然后，數據將被程序使用，該程序將事實數據直接傳遞到Drools KieSession中。 這是內存中的工作空間，規則引擎使用模式匹配來根據內存中存在的事實查看可以觸發哪些規則。
在我們提出的體系結構中，規則駐留在Drools Workbench中，它是一個GUI規則編輯器，還可以用作版本控制和要部署到生產中的規則的存儲庫。
這種方法的主要好處是將維護應用程序本身的過程與編輯為業務創造價值的規則的過程完全獨立。 工程師的任務很明確，即確保系統性能良好且穩定，而業務方面則可以專注于規則。
在上圖中，我們可以看到使用MapR集群的實現可能看起來更具體。 對于該特定應用程序，在其位置使用Kafka集群同樣有效，盡管這樣做會導致出現新用例的可能性降低，并增加系統管理的負擔。 這樣做的原因是，Kafka集群嚴格限于支持流傳輸，而使用聚合集群則允許在同一集群上存在其他用例，無論是操作還是分析用例。
這里的一個關鍵點是從CEP引擎的第二個箭頭回去流。 它說明了將流用于輸入和輸出的重要概念，這是流體系結構的核心。 這也是為什么顯示企業IT系統也從流中獲取其數據的原因。
數據流如下所示：
數據從數據源流到事件生產者，后者只是一個流生產者，或者使用新的Kafka REST Proxy調用REST端點。 新發行的MapR Ecosystem Pack 2.0中的 MapR Streams也支持REST代理。
CEP引擎可以從流中讀取數據，并從Drools Workbench獲取其規則。 從流架構的角度來看，Drools Workbench和CEP Engine是一個單元，可以說是一個微服務，因為它們是完全獨立的，并且沒有任何外部依賴性。
當規則在規則處理算法中觸發時，將需要采取一些外部動作。 這些操作可能是在公司數據庫中插入或更新表，索引到Elasticsearch以將數據提供給Kibana儀表板，發送通知。 但是，我們不是通過直接從CEP Engine到外部系統進行調用來將系統緊密耦合在一起，而是將CEP Engine的數據輸出回流中的另一個主題。 另一個微服務或應用程序（例如Cask.co或Streamsets ）將處理該流。
結論
復雜事件處理已經存在了很長一段時間，但是現在終于有了它。 在硬件方面，具有大量內存的服務更為普遍。 在軟件方面，有可能完全在OSS之外創建有用的生產級CEP系統，而無需訴諸昂貴的，自定義編碼的流應用程序。
將Kafka風格的流消息傳遞系統與Drools結合在一起，為組織提供了非常需要的敏捷性，以區分非常不同的任務，以創建和維護企業流應用程序，以及定義和編輯業務邏輯以進行實時決策。
在下一篇博客文章中，我們將介紹一個具體的用例，將所有這些都付諸實踐，并說明如何僅使用Java，MapR集群和在Wildfly應用程序服務器上運行的Drools Workbench即可實現這種系統。
翻譯自: https://www.javacodegeeks.com/2017/01/better-complex-event-processing-scale-using-microservices-based-streaming-architecture-part-1.html
總結
以上是生活随笔為你收集整理的使用基于微服务的流架构更好地进行大规模的复杂事件处理（第1部分）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： apache camel_发掘Apach
- 下一篇： osgi java_使普通的旧Java