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

作者：趙帥虎 2023-07-12 08:30:52

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

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

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

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

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

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

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

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

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

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

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

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

應(yīng)用場景

不丟事件：一些業(yè)務(wù)場景要求，事件必須發(fā)送成功，不能丟。比如金融、電商等涉及錢的場景；
按順序消費(fèi)：由于架構(gòu)的分布式特性，消費(fèi)者本身就是多實(shí)例的，不支持全局有序消費(fèi)；
exactly-once消費(fèi)：事件消費(fèi)的每個環(huán)節(jié)都可能會失敗，失敗就會重試。重試的話，就需要額外的機(jī)制去保障exactly once

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

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

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

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

責(zé)任編輯：姜華來源：今日頭條