事件驅動架構EDA中的元件

banq發表於2022-05-10

最簡單技術架構是面向批處理和集中式單體系統;金融等行業,尤其​​是貿易和證券交易所等這些細分市場需要由實時資訊驅動,EDA由此誕生,然後是物聯網 (IoT)、社交、開源、PaaS/devops 和大資料等領域擴大了對EDA需求。

EDA概念
EDA 有時被稱為訊息系統。訊息只是一個事件,反之亦然,事件成為訊息。事件驅動系統的概念是它應該使所有感興趣的事物都收到這些事件的通知,這些事件可以從瞭解它中受益。因此,最早的實時事件驅動系統提出了釋出/訂閱的概念。

釋出/訂閱是描述面向事件的訊息傳遞的另一種方式。在釋出/訂閱正規化中,有釋出者和訂閱者。這些是所有釋出/訂閱系統的共同特徵。

  • 匿名性--釋出者不需要知道他們所釋出的資訊的訂閱者的任何情況,只需要知道他們有權接收該資訊。同樣,訂閱者也不需要知道關於釋出者的任何情況,只需要知道他們被認證為合法釋出者。
  • 資訊對所有訂閱者都是相同的。釋出/訂閱系統的力量部分來自於這樣一個事實,即每個訂閱者都得到相同的訊息。如果訊息必須為每個訂閱者定製,那就會給釋出者帶來很大的負擔,並且當新的訂閱者出現時需要進行修改。
  • 發現--釋出/訂閱系統應該支援一種機制,讓釋出者發現新的訂閱者,而訂閱者應該能夠在資訊的釋出者出現時立即找到他們。
  • 自我描述的有效載荷(JSON或XML)。
  • 保證交付--作為訂閱者,你需要知道,如果需要的話,你可以保證按照發布者發生的時間順序收到所有資訊(可靠性和安全性作為pub/sub的QoS)。
  • 低延遲/同步性--所有訂閱者應儘可能在同一時間得到事件的通知。
  • 主題--你應該能夠根據所需內容的助記詞描述(佇列或主題)來訂閱和過濾資訊。

這些概念被設計到第一批pub/sub系統中。這個正規化的關鍵概念是訊息和主題的單位,或者今天所說的主題或佇列。

一旦訊息在系統中飛舞,人們很快就發現,對其他應用程式來說,重用該事件是很有價值的。在股票交易大廳,一旦關於證券價格的資訊被使用pub/sub廣播,許多新的應用程式發現使用該資訊是有用的,所以新的資訊訂閱者不斷湧現出來。連環驅動系統的一個重要特點是,釋出者或訂閱者的負擔不應該因為只有一個或一百萬個而增加。

有時,新的訂閱者需要經過潤色的資訊,比原始資訊包含的資訊更多,或者是相關資訊的摘要。例如,訊息可能是某人買了100美元的東西。然而,新的應用程式可能想知道今天所有購買的總和。一段時間後,我們發現了企業中各種應用所需的行為模式。

EIP、ESB、BPS和BAM
這些被稱為企業整合模式(EIPs),所有基於訊息的系統都開始採用調解技術來規範這些EIPs。
企業服務匯流排(ESB)由此誕生。

ESB是路由轉發那些生命週期很短的訊息,也就是命令和事件,這些都不是需要長期執行的,事件響應都是立即執行。

同時,人們意識到他們可以使用一個訊息來觸發一個長期執行的處理某些事件的業務流程。
我們建立了業務流程伺服器(BPS)來整合事件和其他業務流程。

企業希望通過計算統計資料來監控其業務的健康狀況,並通過檢視訊息流量來尋找問題的指標。
這些被稱為業務活動監視器(BAM)。

隨著時間的推移,許多這些工具的標準被開發出來,它們成為EDA中的標準元件。

訊息代理(MB)
MB是一個提供pub/sub通訊和事務性語義的元件。所描述的大多陣列件不必支援真正的事務性語義,因為我們經常使用MB來提供這種功能。在一個典型的架構中,被認為是關鍵業務的訊息被髮送到一個MB,該MB儲存訊息並以可靠的、有保障的方式將其分配給相應的聽眾。如果一個元件在處理訊息之前發生故障,MB將在元件重新啟動後重新獲取訊息,或者將其傳遞給另一個可以處理它的類似伺服器。

MB處理兩種模式的訊息流;這兩種模式被稱為主題和佇列。

  1. 主題是為了傳遞給許多訂閱者。訂閱者表達他們對一個主題流的興趣,然後按照適當的順序傳送獨立的訊息流。
  2. 佇列只被傳送到能夠處理事務的若干處理者中的一個。在基於主題的協議中的所有訂閱者都得到訊息之前,訊息不能被釋放。在其中一個處理者確認處理該訊息之前,訊息不能被釋放。


企業服務匯流排(ESB)
ESB是訊息架構中的一個重要組成部分。ESB實現眾所周知的企業整合模式:這些包括向多個接收者傳送訊息,用來自其他服務的額外資訊增強訊息,以及檢測需要不同處理的特殊條件。
例如,低於一定數額的訂單可能由一種型別的流程處理,而大於該數額的訂單則由另一種型別的流程處理。
ESB應該非常善於可靠地處理大量的訊息:每天數十億的訊息應該可以由一個伺服器叢集輕鬆處理。

一個ESB應該能夠處理來自許多不同來源的資料事件,包括資料庫、檔案系統和傳統的通訊協議。因此,ESB是整合工作中的一個重要組成部分。

在物聯網世界中,ESB可以指定基本邏輯,併為裝置實現該邏輯。它不太適合複雜的事件序列,但對於簡單的事件及其反應,ESB是一個理想的地方,可以把所有裝置的邏輯放在一起。
ESB有一個適合非程式設計師的圖形編輯器,可以很容易地把邏輯、裝置和動作拖到一起。

業務流程伺服器(BPS)
BPS元件提供了一個圖形編輯器,用於設計和測試刺激事件的業務流程。這使得不是程式設計師的人也能設計業務流程並實施它們。它允許快速改變業務流程和跟蹤業務流程。BPS伺服器被設計用來處理回滾和改變業務流程,而交易是在一個流程的中間。BPS伺服器應該能夠同時處理數千甚至數百萬個待完成的長期執行的有狀態程式。

規則引擎
規則引擎是一種工具,可以處理分層的重疊規則集,以計算出業務問題的正確答案。規則引擎對於指定複雜的定價方案或複雜的PaaS擴充套件規則,以及基於複雜標準的權利決定非常有用,在這種情況下,通常你可能會說以一種方式做事,但背景可能會改變所做的選擇。由於規則引擎通常用於需要快速決定如何處理交易的情況,它們需要快速。它們還需要有一個直觀和簡單的使用者介面,以便業務人員能夠構建規則,並在規則實施之前看到交易將如何處理,以防規則的組合產生意外的結果。

一個規則引擎可以幫助指定圍繞物聯網裝置可能存在的複雜規則。例如,你可能想把你的家正常加熱到72度,除非今天晚些時候會很熱,或者現在能源處於需求高峰期,或者你在度假。

資料服務伺服器(DSS)
DSS用於圍繞資料庫或其他永續性(靜態資料)資料儲存機制建立服務,如無SQL資料庫或甚至各種型別的檔案系統。在一個多層架構中,應用程式不直接與資料庫表對話。相反,我們定義了具有直接業務相關性的表或表的更高層次的抽象。DSS提供了一個抽象化底層資料的服務。DSS可以提供與資料來源或底層資料儲存機制架構變化的隔離。

綜合應用

  • 長時間執行的流程使用 BPS:通過視覺化流程管理器改變處理訊息的方式,包括人工審批流程。
  • 較短的流程最好在 MB 中處理
  • 在 ESB 中處理無狀態事務
  • 在DSS資料服務中處理有狀態事務。
  • 快速變化的資料在規則引擎中處理:規則引擎可以讓線上商店根據折扣程式碼、客戶體驗、總價、數量或任何因素組合等一系列複雜因素輕鬆對商品進行定價,並在不經通知的情況下立即更改這些規則重新編碼。
  • 實時事件在大資料處理資料工程 技術中處理。


​​​​​​​互聯業務、互聯消費者、移動性和物聯網不斷變化的市場推動了 EDA 架構的重要性比以往任何時候都更高。因此,EDA 演變為整合 API 管理、物聯網和移動性也將推動下一代 SOA。EDA 提供了與未來應用程式整合的高度敏捷性和可擴充套件性,同時在事件發生時提供實時分析和監控,確保今天的解決方案也能滿足長期需求。

 

相關文章