基于docker微服務(wù)架構(gòu)

基于微服務(wù)的流架構(gòu)與開源規(guī)則引擎相結(jié)合，使實(shí)時(shí)業(yè)務(wù)規(guī)則變得容易

這篇文章旨在詳細(xì)介紹我將OSS業(yè)務(wù)規(guī)則引擎與Kafka風(fēng)格的現(xiàn)代流消息傳遞系統(tǒng)集成在一起的項(xiàng)目。 該項(xiàng)目的目標(biāo)（即眾所周知的復(fù)雜事件處理（CEP））旨在實(shí)現(xiàn)對(duì)流數(shù)據(jù)的實(shí)時(shí)決策，例如在IoT用例中。

經(jīng)過大量的寫作，我決定將文章分為兩部分。 在第一部分中，我將重點(diǎn)介紹什么是CEP，為什么有用，并解釋體系結(jié)構(gòu)解決方案以及為什么我們認(rèn)為這對(duì)于許多有用的生產(chǎn)用例都是一個(gè)好主意。

在第二篇文章中，我將展示一個(gè)基于道路交通監(jiān)控系統(tǒng)的具體示例，并盡可能詳細(xì)地說明其制作方式。

因此，事不宜遲，繼續(xù)第1部分！

總覽

根據(jù)Gartner Inc.的數(shù)據(jù)，截至2015年，全球企業(yè)應(yīng)用軟件市場(chǎng)價(jià)值約為1500億美元。這是一個(gè)巨大的市場(chǎng)，其中最常見的應(yīng)用程序類型之一就是圍繞將某種業(yè)務(wù)邏輯應(yīng)用于從各個(gè)方面生成的數(shù)據(jù)這生意。

如今，現(xiàn)代企業(yè)應(yīng)用程序需要連接到越來越多的數(shù)據(jù)源類型，隨數(shù)據(jù)大小和用戶數(shù)量擴(kuò)展，可靠并快速執(zhí)行。 隨著業(yè)務(wù)需求和條件的變化，長(zhǎng)達(dá)一年或更長(zhǎng)的自定義應(yīng)用程序開發(fā)周期并不吸引人，從而使該應(yīng)用程序甚至在投入生產(chǎn)之前就已過時(shí)。

在大型，全國(guó)性，區(qū)域性或全球性組織中，或在金融，醫(yī)療保健或IT等行業(yè)中使用大量數(shù)據(jù)的組織中，需求保持不變，但必須使用大數(shù)據(jù)技術(shù)來滿足。 這帶來了一系列全新的難題，這些難題使大規(guī)模開發(fā)企業(yè)應(yīng)用程序的成本變得極為昂貴，并且在IT基礎(chǔ)架構(gòu)和專有技術(shù)要求方面設(shè)置了很高的障礙。

因此，需要一種方法來對(duì)各種來源收集的數(shù)據(jù)運(yùn)行業(yè)務(wù)邏輯，這可能是非常大規(guī)模的，理想情況下是實(shí)時(shí)的，例如物聯(lián)網(wǎng)類型的應(yīng)用程序。

了解復(fù)雜事件處理（CEP）

顧名思義，復(fù)雜事件處理（簡(jiǎn)稱CEP）并不那么復(fù)雜。 從根本上講，CEP是關(guān)于將業(yè)務(wù)規(guī)則應(yīng)用于流事件數(shù)據(jù)。 事件數(shù)據(jù)只是帶有時(shí)間戳字段的數(shù)據(jù)。 此類數(shù)據(jù)的示例可能是Web服務(wù)器的日志條目，來自購買的收據(jù)或傳感器數(shù)據(jù)，所有這些都可以視為恒定的事件流。 在此流數(shù)據(jù)上應(yīng)用規(guī)則使響應(yīng)時(shí)可以采取有用的操作。

這是一個(gè)智能家居的示例，該智能家居的門口有傳感器，智能WiFi路由器和房間移動(dòng)探測(cè)器。 通過CEP將所有數(shù)據(jù)流式傳輸?shù)郊彝シ?wù)器中，用戶可以制定一些規(guī)則，如下所示：

如果是白天，并且門關(guān)著，并且沒有電話連接到WiFi，請(qǐng)將房屋設(shè)置為“沒人回家”

如果沒有人在家并且門已解鎖，則鎖上門并打開警報(bào)器

如果沒有人在家并且是冬天，請(qǐng)將房屋溫度降低到18C

如果沒有人在家，那是夏天，請(qǐng)關(guān)閉空調(diào)

如果沒有人在家并且門被家庭成員打開，則關(guān)閉警報(bào)并將房屋設(shè)置為“人們?cè)诩摇?

擁有一堆這樣的簡(jiǎn)單規(guī)則，確實(shí)會(huì)很快使一個(gè)聰明的家庭加起來。 實(shí)際上，在一些競(jìng)爭(zhēng)性智能家居“集線器”設(shè)備中已經(jīng)可以購買到這種功能，這些設(shè)備使用通用協(xié)議從房屋周圍的兼容傳感器設(shè)備中讀取信息，然后在滿足某些規(guī)則時(shí)將操作推回去。

這種示例可以輕松地移植到許多其他域。 例如，在零售中，購買歷史記錄和信標(biāo)可用于生成個(gè)性化，位置敏感的消息或優(yōu)惠券。 在工業(yè)應(yīng)用中，可以通過使用相對(duì)簡(jiǎn)單的邏輯規(guī)則（例如，“如果該機(jī)器的紅色按鈕點(diǎn)亮，則必須將其停止”）的組合來更輕松地操作和維護(hù)許多機(jī)床。

CEP規(guī)則引擎與手動(dòng)編碼

到目前為止，閱讀這些信息的工程師可能不會(huì)留下深刻的印象，因?yàn)榱魇录m用簡(jiǎn)單的規(guī)則。 諸如上述的智能家居用例可以很容易地（完全可以做到）完全通過使用Python進(jìn)行手工編碼來處理，并且可以在舊用途的PC或Raspberry Pi上運(yùn)行。

這種項(xiàng)目有哪些部分？

數(shù)據(jù)提取

定義數(shù)據(jù)規(guī)則

執(zhí)行規(guī)則

滿足條件時(shí)從規(guī)則中采取措施。

良好的軟件體系結(jié)構(gòu)要求嘗試使最容易更改的部分易于更改，但要以增加其他部分的難度為代價(jià)。 最需要改變的部分是什么？ 數(shù)據(jù)攝取僅在添加新傳感器時(shí)才會(huì)更改，但是給定傳感器的數(shù)據(jù)不會(huì)突然更改。 摘要中的執(zhí)行規(guī)則始終相同； 變化的是規(guī)則本身。 編碼并可以正常工作的動(dòng)作并沒有真正改變，但是隨著時(shí)間的推移添加新動(dòng)作應(yīng)該很容易。

當(dāng)用例開始擴(kuò)展并且規(guī)則數(shù)量增加時(shí)，規(guī)則處理引擎的效率開始變得重要。 此外，當(dāng)規(guī)則數(shù)量增加時(shí)，使規(guī)則易于編輯不僅是“必備”功能，而且是核心要求。

另一個(gè)經(jīng)常使用的論點(diǎn)是業(yè)務(wù)邏輯與SDLC的分離。 業(yè)務(wù)需要比軟件開發(fā)更快。 通過使用規(guī)則引擎，兩個(gè)流在很大程度上可以獨(dú)立移動(dòng)。

CEP被“植入”物聯(lián)網(wǎng)應(yīng)用

CEP幾乎是任何種類的物聯(lián)網(wǎng)應(yīng)用程序的要求，例如智能家居，智能農(nóng)業(yè)，工業(yè)4.0或電信數(shù)據(jù)。 從某種意義上說，這是一項(xiàng)要求，即拋開功能的實(shí)現(xiàn)方式，物聯(lián)網(wǎng)需要將規(guī)則應(yīng)用于流事件數(shù)據(jù)。 無論是在單個(gè)私人住宅中進(jìn)行小規(guī)模生產(chǎn)，還是在遍布全球的數(shù)家工廠中進(jìn)行大規(guī)模生產(chǎn)，都是如此。

根據(jù)我們剛剛描述的內(nèi)容，理想的設(shè)計(jì)會(huì)反對(duì)手動(dòng)編碼的解決方案，并使用所謂的“業(yè)務(wù)規(guī)則處理引擎”。 開源世界中存在著幾種，最著名的是Drools。

Drools：開源業(yè)務(wù)規(guī)則引擎

Drools是在開源項(xiàng)目的JBoss框架下開發(fā)的一個(gè)開源項(xiàng)目。 這是一個(gè)具有長(zhǎng)期活躍開發(fā)歷史的項(xiàng)目，當(dāng)前版本為6.5.0。最終版本為Beta 7。 它相當(dāng)現(xiàn)代，因?yàn)樗С諮ava 8大大改進(jìn)的API。

Drools具有我們正在尋找的所有特征，其中包括規(guī)則引擎，具有定義良好的DSL來定義規(guī)則以及基于RETE算法的規(guī)則引擎，該引擎經(jīng)過了優(yōu)化和非常快速。 此外，該文檔非常詳盡，并且有大量書籍可用來學(xué)習(xí)有關(guān)如何使用此強(qiáng)大框架的所有知識(shí)。

最后，Drools帶有一個(gè)稱為Workbench的GUI，它使我們可以直觀地創(chuàng)建和編輯規(guī)則，而無需編寫代碼。 這是一項(xiàng)殺手級(jí)功能，它將規(guī)則的功能置于業(yè)務(wù)分析的范圍之內(nèi)。

流傳輸架構(gòu)為大數(shù)據(jù)啟用CEP

流架構(gòu)是CEP的關(guān)鍵組件。 CEP的全部重點(diǎn)是通過流數(shù)據(jù)（近）實(shí)時(shí)做出決策，而不是像批處理那樣對(duì)歷史數(shù)據(jù)進(jìn)行分析來采取措施。

CEP涉及敏捷性，并且由于大量簡(jiǎn)單規(guī)則的相互作用而導(dǎo)致潛在的復(fù)雜行為，這些規(guī)則都實(shí)時(shí)應(yīng)用于內(nèi)存中的數(shù)據(jù)。 流式，基于微服務(wù)的體系結(jié)構(gòu)正成為現(xiàn)代大規(guī)模體系結(jié)構(gòu)的標(biāo)準(zhǔn)。

O'Reilly出版的Ted Dunning和Ellen Friedman的Streaming Architecture一書中詳細(xì)探討了流架構(gòu)的好處，該書可免費(fèi)在線獲得 。 我還在2016年新加坡Strata大會(huì)上發(fā)表了關(guān)于這一主題的演講。 請(qǐng)去Slideshare看一看 。

一般而言，解決方案將類似于上圖。 收集數(shù)據(jù)源（例如傳感器，收銀機(jī)或日志），并使用輕型ETL將其添加到流中。 然后，數(shù)據(jù)將被一個(gè)程序使用，該程序?qū)⑹聦?shí)數(shù)據(jù)簡(jiǎn)單地傳遞到Drools KieSession中。 這是內(nèi)存中的工作空間，規(guī)則引擎使用模式匹配來根據(jù)內(nèi)存中存在的事實(shí)查看可以觸發(fā)哪些規(guī)則。

在我們提出的體系結(jié)構(gòu)中，規(guī)則駐留在Drools Workbench中，它是一個(gè)GUI規(guī)則編輯器，還可以用作版本控制和要部署到生產(chǎn)中的規(guī)則的存儲(chǔ)庫。

這種方法的主要好處是將維護(hù)應(yīng)用程序本身的過程與編輯為業(yè)務(wù)創(chuàng)造價(jià)值的規(guī)則的過程完全獨(dú)立。 工程師的任務(wù)很明確，即確保系統(tǒng)性能良好且穩(wěn)定，而業(yè)務(wù)方面則可以專注于規(guī)則。

在上圖中，我們可以看到使用MapR集群的實(shí)現(xiàn)看起來更具體。 對(duì)于特定的應(yīng)用程序，在其位置使用Kafka集群同樣有效，盡管這會(huì)導(dǎo)致出現(xiàn)新用例的可能性降低，并增加系統(tǒng)管理的負(fù)擔(dān)。 這樣做的原因是，Kafka集群嚴(yán)格限于支持流傳輸，而使用聚合集群則允許在同一集群上存在其他用例，無論是操作還是分析用例。

這里的一個(gè)關(guān)鍵點(diǎn)是從CEP引擎的第二個(gè)箭頭回去流。 它說明了將流用于輸入和輸出的重要概念，這是流體系結(jié)構(gòu)的核心。 這也就是為什么顯示企業(yè)IT系統(tǒng)也從流中獲取其數(shù)據(jù)的原因。

數(shù)據(jù)流如下所示：

數(shù)據(jù)從數(shù)據(jù)源流到事件生產(chǎn)者，后者只是一個(gè)流生產(chǎn)者，或者使用新的Kafka REST Proxy調(diào)用REST端點(diǎn)。 新發(fā)布的MapR Ecosystem Pack 2.0中的 MapR Streams也支持REST代理。

CEP引擎可以從流中讀取數(shù)據(jù)，并從Drools Workbench獲取其規(guī)則。 從流架構(gòu)的角度來看，Drools Workbench和CEP Engine是一個(gè)單元，可以說是一個(gè)微服務(wù)，因?yàn)樗鼈兪峭耆?dú)立的，并且沒有任何外部依賴性。

在規(guī)則處理算法中觸發(fā)規(guī)則時(shí)，需要采取一些外部措施。 這些操作可能是在公司數(shù)據(jù)庫中插入或更新表，索引到Elasticsearch以將數(shù)據(jù)提供給Kibana儀表板，發(fā)送通知。 但是，我們不是通過直接從CEP Engine到外部系統(tǒng)進(jìn)行調(diào)用來將系統(tǒng)緊密耦合在一起，而是將CEP Engine中的數(shù)據(jù)輸出回流中的另一個(gè)主題。 另一個(gè)微服務(wù)或應(yīng)用程序（例如Cask.co或Streamsets ）將處理該流。

結(jié)論

復(fù)雜事件處理已經(jīng)存在了一段時(shí)間，但現(xiàn)在終于有了自己的應(yīng)用。 在硬件方面，具有大量?jī)?nèi)存的服務(wù)更為普遍。 在軟件方面，有可能完全在OSS之外創(chuàng)建有用的生產(chǎn)級(jí)CEP系統(tǒng)，而無需訴諸昂貴的，自定義編碼的流應(yīng)用程序。

將Kafka風(fēng)格的流消息傳遞系統(tǒng)與Drools結(jié)合在一起，為組織提供了非常需要的敏捷性，以區(qū)分創(chuàng)建和維護(hù)企業(yè)流應(yīng)用程序的非常不同的任務(wù)，以及為實(shí)時(shí)決策定義和編輯業(yè)務(wù)邏輯。

在下一篇博客文章中，我們將介紹一個(gè)具體的用例，將所有這些都付諸實(shí)踐，并說明如何僅使用Java，MapR集群和在Wildfly應(yīng)用程序服務(wù)器上運(yùn)行的Drools Workbench即可實(shí)現(xiàn)這種系統(tǒng)。

翻譯自: https://www.javacodegeeks.com/2017/01/better-complex-event-processing-scale-using-microservices-based-streaming-architecture-part-1.html

基于docker微服務(wù)架構(gòu)

總結(jié)

以上是生活随笔為你收集整理的基于docker微服务架构_使用基于微服务的流架构更好地进行大规模的复杂事件处理（第1部分）...的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。