企業事件驅動架構指南 - wiprodigital

“事件驅動架構（EDA）是一種設計範例，其中軟體元件響應收到一個或多個事件通知而執行。”
–加特納

將敏捷方法論與可以快速響應實時事件的平臺相結合，使企業能夠做出手動或自動的智慧決策，並實現真正的企業敏捷性。然後，可以利用從伺服器到可穿戴裝置的各種來源的事件來支援許多工業用例。
 

 
採用此類架構的大型組織需要將事件以及其API和業務服務視為其平臺的一流公民。
本指南描述了事件驅動架構（EDA）如何使組織受益，採用基於OpenSource技術的EDA的逐步方法，可支援快速創新的敏捷實踐以及一些實際用例。
 

事件驅動的架構採用模式
擁抱事件驅動架構的企業可以利用可擴充套件且可靠的實時通訊的優勢。這可以幫助推動跨IoT，電子商務，跨系統，資料和應用程式的資料整合，邊緣和財務欺詐檢測等眾多戰略計劃。
 
在其系統和應用程式中新增事件驅動的體系結構的公司可以提高應用程式的可伸縮性和響應能力。他們還可以訪問更好的業務決策所需的資料和上下文，例如流處理，資料整合或網站活動跟蹤。
 
事件是從一系列事件源中捕獲的。從總體上講，這些事件被分類為業務/功能或技術。

部署事件驅動參考體系結構指南
所有企業都以一種形式或另一種形式產生事件。他們可能只是沒有一個可以利用這些事件來產生有形業務價值的系統。當企業開始採用EDA時，對於他們而言，在構建正確的體系結構時確定其特定要求很重要。這些事件可能跨越各種模式，例如實時事件和決策，流處理和複雜事件處理。
 
建立這樣的事件平臺以開始獲取事件驅動的架構的好處可能很簡單，但是像每次旅行一樣，擁有一張到達目的地的地圖會有所幫助。以下指南概述了組織應考慮和考慮的事項，以及為建立可滿足多種模式和業務需求的可靠的EDA而應採取的措施。
 

1.定義：架構與技術
第一步解決構成事件網格執行時的核心技術元件。這包括攝取，排隊，處理，儲存和提供事件的技術。典型的大型企業可能具有一個或多個Pub-Sub Message Broker平臺，事件流平臺，雲訊息傳遞平臺以及分佈在各種技術和位置的事件消費者和生產者。這些平臺往往位於筒倉中，不被視為統一事件網格的一部分。為了解決這個問題，組織應該：

• 確定圍繞事件驅動的架構的需求，這些需求可能在整合，應用程式架構和分析組之間存在
• 建立具有所有現有元件的統一事件網格的願景
• 制定計劃以填補滿足組織的事件處理要求所需的技術能力中可能存在的空白。
• 設定參考體系結構並定義模式的參考實現，例如用於管理跨多個資料庫的邏輯事務和資料完整性，事件源和CQRS的模式。
• 該技術工具包可能是使用Kafka，JMS代理或訊息代理或AMQ Interconnect來構建大規模訊息網路的跨訊息流的多個元件的組合。

流媒體
Apache Kafka擁有堅如磐石且超快速的事件流主幹，仍然是所有流用例的預設選擇。它可實現多種用途，包括活動跟蹤，日誌聚合，流處理，更改資料捕獲，物聯網（IoT）遙測等。紅帽AMQ流小號可以很容易地執行，並透過上游專案Strimzi在Red Hat OpenShift本地管理Apache的卡夫卡。
 

事件流處理和複雜事件處理
事件平臺還需要處理框架，該框架提供諸如複雜事件處理（CEP）之類的處理樣式，更常見的事件流處理樣式以及包括SQL在內的多層程式設計抽象層，以查詢快速移動的資料。處理框架還應該能夠與機器學習框架整合以對模型進行評分。大多數流處理框架，Apache Flink/Spark/Kafka Stream 包括AMQ Streams，都為所有這些程式設計模型提供支援。
 

面向企業使用者的實時見解
大多數事件直接對映到業務概念，並且如果置於業務使用者的手中，它們將是實現業務敏捷性的強大工具。使用者介面允許使用者根據時間窗內事件或事件組合的發生來定義處理規則，這將是業務敏捷性的重要槓桿。
 

微服務作為事件的消費者
接收到事件後，它們需要由微服務進行消費和處理，以為組織帶來業務價值。Quarkus是超音速的，亞原子的Java，它是一種這樣的執行時，它允許命令式和反應式（事件）程式設計正規化的統一，對訊息傳遞具有強大的內建支援，非常適合構建需要高效能執行時的EDA微服務。
 

事件驅動的無伺服器架構
事件驅動的體系結構在無伺服器環境中也起著重要的作用。無伺服器應用程式可以響應需求，並根據需要自動縮放，可以透過事件驅動的執行模型進行。紅帽OpenShift Serverless提供了企業級的無伺服器平臺，可在混合和多雲環境中帶來可移植性和一致性。

 

2.設定：治理實踐
隨著採用事件驅動的體系結構的規模不斷擴大，其中釋出和使用了數十個事件，因此擁有正式的實踐和工具來管理事件的定義，設計，建立和使用就變得至關重要。這類似於API管理平臺為API提供的功能。
 

 
這些是建立治理和實踐以確保成功時的一些注意事項。

• 一種介面定義語言，提供事件的資料結構以及使用該事件的機制，協議和位置URL的可讀定義。諸如AsyncAPI之類的新興標準提供了此功能。也有相關的努力來擴充套件Open API，以增加對事件驅動API的支援。事件的結構將引用並重用企業資料定義。
• 所有事件的可搜尋登錄檔。與API一樣，事件登錄檔為事件的後設資料提供了可搜尋的儲存。登錄檔應能夠按業務域對事件進行分類和組織，並允許事件所有者為其事件設定可見性規則和訪問限制。
• 事件開發人員門戶，其中包括上述登錄檔以及提供開發人員和事件所有者之間的協作，提供對文件，最佳做法，模板，客戶端庫等的訪問的工具。
• 分析儀表盤，提供與事件的釋出和使用有關的執行時指標。

3.啟用：統一的操作和管理
下一步是建立統一的監視功能，以提供整個景觀中已釋出和使用的所有事件的檢視。此統一控制檯應為操作人員提供支援，以便（a）有效監視平臺，（b）監視失敗的事件，以及（c）編輯有效負載並再次從統一控制檯在所有Message Broker中重新發布它們。
 
另一個關鍵功能是事件沿襲圖的檢視，該圖顯示了事件，其父事件及其子事件之間的聯絡。該圖提供了跨多個服務和系統的整體事務的完整檢視，這些服務和系統使用事件驅動的互動來協調其工作。當需要重新發布事件並檢查此操作的下游副作用時，此功能也非常有用。
 

 
紅帽AMQ Streams還透過一套適用於AMQ Streams的Red Hat Operators框架，在Kubernetes平臺上支援自動安裝和配置。這些操作員負責部署和管理Apache Kafka叢集，Kafka主題和Kafka使用者。
 

採用事件驅動架構以獲取業務價值
傳統上，客戶非常依賴API，因為它們具有用於資料交換的標準介面，並且HTTP在開發人員中很流行。為了從EDA中獲得收益，重要的是提供正確的工具和統一的開發人員平臺，以幫助克服現有的技術限制並贏得開發人員。
 

 
讓我們討論一些建議，以便在遺留和未開發的架構中更快地採用事件。

• 確定業務驅動的用例，以建立將定義適當模式的試點，例如簡單事件，事件流，複雜事件處理。
• 從上一節中討論的參考體系結構中選擇正確的元件，以便根據業務需求構建合適的模式
• 透過內部支援和深入的培訓，提供對體系結構，技術和過程的訪問，從而使開發人員的採用變得容易。
• 在舊版應用程式中啟用EDA可以從事件平臺中獲得最大收益。
  
  • 透過更改資料捕獲（CDC）開始捕獲事件以建立資料庫驅動的事件
  • 使用現有應用程式中的增強功能和CR作為啟動器來建立所需事件
  • 從現有的舊版應用程式合成事件
• 使用參考體系結構中可用的技術工具包構建新的用例，以進一步加速業務轉型並獲得收益。

EDA推動業務價值：真實故事
1.透過新渠道建立新的商業模式
阿聯酋航空NBD在Red Hat OpenShift上使用Red Hat Fuse和Apache Kafka支援實時銀行業務和合作夥伴互動。
 
2.極大地改善了客戶體驗
一位全球金融服務領導者實施了實時廣告系列解決方案，該解決方案使廣告系列轉化率提高了約60％
 
3.可衡量和有效的運營改善
一家全球物流提供商使用事件結構來提供其廣泛的全球網路中貨運的實時可見性
 
4.在物聯網領域
一家全球電子裝置製造商使用基於事件的主動監視將服務維護呼叫的數量減少了45％。事件流分析有助於識別模式並確定警報響應的優先順序。
 
5.用於微服務間通訊的EDA
一家歐洲銀行使用事件驅動的體系結構來改善與客戶的關係。基於輕量級事件匯流排的解決方案有助於使應用程式保持同步，並提供客戶資料的單一檢視，從而簡化了客戶體驗。