首頁>國內(nèi) > 正文

服務(wù)架構(gòu)：事件驅(qū)動架構(gòu)

2023-07-12 09:18:22來源：今日頭條

事件驅(qū)動架構(gòu)是由生產(chǎn)者和消費者組成，生產(chǎn)者負責生產(chǎn)事件，消費者監(jiān)聽并消費事件。

事件驅(qū)動架構(gòu)

(相關(guān)資料圖)

事件分發(fā)以近實時的方式進行，所以當事件產(chǎn)生時，消費者可以立即做出應(yīng)對。

生產(chǎn)者和消費者是解耦的，它不知道有哪些消費者在監(jiān)聽事件消費者之間也是解耦的，每個消費者都可以讀取所有事件。

還有一種模式，多個消費者是競爭的關(guān)系，它們從同一個隊列消費，不出現(xiàn)錯誤的情況下每個事件都只被處理一次。

另外，在某些系統(tǒng)中，事件導(dǎo)入的吞吐量要求也很高，比如IoT系統(tǒng)。

事件驅(qū)動架構(gòu)可以通過發(fā)布/訂閱模型或事件流模型來實現(xiàn)：

發(fā)布/訂閱模型：消息隊列負責追蹤訂閱者，事件被發(fā)布后，消息隊列負責發(fā)送給訂閱者。一旦事件被接收，就不能再重放，新增的訂閱者也看不到該事件。事件流模型：將事件寫入日志并持久存儲下來，在單個分區(qū)里事件嚴格有序。client端不需要訂閱這個事件流，而且能夠從任意一個位置開始讀取事件。當然，移動偏移量也要靠客戶端自己完成。這意味著client可以在任意時間點加入，也支持事件重放。

在事件的消費上，也可以有一些略微不同的方式：

簡單模式：事件產(chǎn)生后立刻觸發(fā)消費者下一步的動作。比如風控、治理等場景下的異常行為檢測。復(fù)雜模式：消費者處理一組數(shù)據(jù)，找到其中的規(guī)律，比如基于時間窗口做聚合求sum/count/avg。純流式：通過流式平臺比如Kafka作為數(shù)據(jù)中轉(zhuǎn)的工具，接收事件并喂給下游的processor。下游的processor通常做簡單的transform之后再寫入的kafka。

事件通常來源于外部系統(tǒng)，比如IoT中的物理設(shè)備、互聯(lián)網(wǎng)用戶的端上。我們在設(shè)計時，必須認真評估總體的數(shù)據(jù)量和吞吐量，以保證系統(tǒng)能支撐這個量級。

在上面的流程圖中，右側(cè)的三個格子表示三種類型的消費者，每種類型的消費者下面有多個實例。在實際場景中，出于容災(zāi)的目的，多個消費者實例的情況非常普遍。為了保證事件處理的吞吐量，多個實例也是有必要的。

在處理事件時，一個消費者實例可以創(chuàng)建多個線程。這也能提高處理的吞吐量，不過事件被處理的順序就亂了，業(yè)務(wù)上可能無法接受；另外多線程處理也很難保證exactly-once語義。

應(yīng)用場景多個子系統(tǒng)都需要處理這些事件需要實時處理，且延遲越小越好處理邏輯比較復(fù)雜的場景，比如要對事件繼續(xù)模式匹配或者基于時間窗口的聚合事件量級非常大，生產(chǎn)的速度也很快架構(gòu)優(yōu)勢生產(chǎn)者和消費者解耦沒有點對點的集成，增加新消費者幾乎沒有難度消費者可以即時處理到來的事件天生分布式、可擴展性非常高每個下游子系統(tǒng)都可以訪問全部事件，且互相獨立有哪些挑戰(zhàn)不丟事件：一些業(yè)務(wù)場景要求，事件必須發(fā)送成功，不能丟。比如金融、電商等涉及錢的場景；按順序消費：由于架構(gòu)的分布式特性，消費者本身就是多實例的，不支持全局有序消費；exactly-once消費：事件消費的每個環(huán)節(jié)都可能會失敗，失敗就會重試。重試的話，就需要額外的機制去保障exactly once補充說明

在設(shè)計系統(tǒng)時，我們通常需要考慮單條消息的大小，它對系統(tǒng)的性能和金錢成本影響都非常大。如果走兩個極端的話，可以是：

如果將所有需要的信息都放到單個事件里，處理起來會很方便，并且能夠避免額外的信息查詢。

如果將非常少的信息放到單個事件里，比如ID字段，那么會節(jié)省大量傳輸數(shù)據(jù)的時間和金錢成本，但其他信息需要訪問其他服務(wù)才能獲取到。

這其中的利益權(quán)衡，看自己的業(yè)務(wù)來定了。

關(guān)鍵詞：