建站
咨詢
售后
建站咨詢
新聞中心
事件驅(qū)動(dòng)架構(gòu)是由生產(chǎn)者和消費(fèi)者組成，生產(chǎn)者負(fù)責(zé)生產(chǎn)事件，消費(fèi)者監(jiān)聽并消費(fèi)事件。
創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供隆昌網(wǎng)站建設(shè)、隆昌做網(wǎng)站、隆昌網(wǎng)站設(shè)計(jì)、隆昌網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、隆昌企業(yè)網(wǎng)站模板建站服務(wù)，十年隆昌做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。
事件驅(qū)動(dòng)架構(gòu)
事件分發(fā)以近實(shí)時(shí)的方式進(jìn)行，所以當(dāng)事件產(chǎn)生時(shí)，消費(fèi)者可以立即做出應(yīng)對(duì)。
- 生產(chǎn)者和消費(fèi)者是解耦的，它不知道有哪些消費(fèi)者在監(jiān)聽事件
- 消費(fèi)者之間也是解耦的，每個(gè)消費(fèi)者都可以讀取所有事件。
還有一種模式，多個(gè)消費(fèi)者是競(jìng)爭(zhēng)的關(guān)系，它們從同一個(gè)隊(duì)列消費(fèi)，不出現(xiàn)錯(cuò)誤的情況下每個(gè)事件都只被處理一次。
另外，在某些系統(tǒng)中，事件導(dǎo)入的吞吐量要求也很高，比如IoT系統(tǒng)。
事件驅(qū)動(dòng)架構(gòu)可以通過發(fā)布/訂閱模型或事件流模型來實(shí)現(xiàn)：
- 發(fā)布/訂閱模型：消息隊(duì)列負(fù)責(zé)追蹤訂閱者，事件被發(fā)布后，消息隊(duì)列負(fù)責(zé)發(fā)送給訂閱者。一旦事件被接收，就不能再重放，新增的訂閱者也看不到該事件。
- 事件流模型：將事件寫入日志并持久存儲(chǔ)下來，在單個(gè)分區(qū)里事件嚴(yán)格有序。client端不需要訂閱這個(gè)事件流，而且能夠從任意一個(gè)位置開始讀取事件。當(dāng)然，移動(dòng)偏移量也要靠客戶端自己完成。這意味著client可以在任意時(shí)間點(diǎn)加入，也支持事件重放。
在事件的消費(fèi)上，也可以有一些略微不同的方式：
- 簡(jiǎn)單模式：事件產(chǎn)生后立刻觸發(fā)消費(fèi)者下一步的動(dòng)作。比如風(fēng)控、治理等場(chǎng)景下的異常行為檢測(cè)。
- 復(fù)雜模式：消費(fèi)者處理一組數(shù)據(jù)，找到其中的規(guī)律，比如基于時(shí)間窗口做聚合求sum/count/avg。
- 純流式：通過流式平臺(tái)比如Kafka作為數(shù)據(jù)中轉(zhuǎn)的工具，接收事件并喂給下游的processor。下游的processor通常做簡(jiǎn)單的transform之后再寫入的kafka。
事件通常來源于外部系統(tǒng)，比如IoT中的物理設(shè)備、互聯(lián)網(wǎng)用戶的端上。我們?cè)谠O(shè)計(jì)時(shí)，必須認(rèn)真評(píng)估總體的數(shù)據(jù)量和吞吐量，以保證系統(tǒng)能支撐這個(gè)量級(jí)。
在上面的流程圖中，右側(cè)的三個(gè)格子表示三種類型的消費(fèi)者，每種類型的消費(fèi)者下面有多個(gè)實(shí)例。在實(shí)際場(chǎng)景中，出于容災(zāi)的目的，多個(gè)消費(fèi)者實(shí)例的情況非常普遍。為了保證事件處理的吞吐量，多個(gè)實(shí)例也是有必要的。
在處理事件時(shí)，一個(gè)消費(fèi)者實(shí)例可以創(chuàng)建多個(gè)線程。這也能提高處理的吞吐量，不過事件被處理的順序就亂了，業(yè)務(wù)上可能無法接受；另外多線程處理也很難保證exactly-once語義。
應(yīng)用場(chǎng)景
- 多個(gè)子系統(tǒng)都需要處理這些事件
- 需要實(shí)時(shí)處理，且延遲越小越好
- 處理邏輯比較復(fù)雜的場(chǎng)景，比如要對(duì)事件繼續(xù)模式匹配或者基于時(shí)間窗口的聚合
- 事件量級(jí)非常大，生產(chǎn)的速度也很快
架構(gòu)優(yōu)勢(shì)
- 生產(chǎn)者和消費(fèi)者解耦
- 沒有點(diǎn)對(duì)點(diǎn)的集成，增加新消費(fèi)者幾乎沒有難度
- 消費(fèi)者可以即時(shí)處理到來的事件
- 天生分布式、可擴(kuò)展性非常高
- 每個(gè)下游子系統(tǒng)都可以訪問全部事件，且互相獨(dú)立
有哪些挑戰(zhàn)
- 不丟事件：一些業(yè)務(wù)場(chǎng)景要求，事件必須發(fā)送成功，不能丟。比如金融、電商等涉及錢的場(chǎng)景；
- 按順序消費(fèi)：由于架構(gòu)的分布式特性，消費(fèi)者本身就是多實(shí)例的，不支持全局有序消費(fèi)；
- exactly-once消費(fèi)：事件消費(fèi)的每個(gè)環(huán)節(jié)都可能會(huì)失敗，失敗就會(huì)重試。重試的話，就需要額外的機(jī)制去保障exactly once
補(bǔ)充說明
在設(shè)計(jì)系統(tǒng)時(shí)，我們通常需要考慮單條消息的大小，它對(duì)系統(tǒng)的性能和金錢成本影響都非常大。如果走兩個(gè)極端的話，可以是：
如果將所有需要的信息都放到單個(gè)事件里，處理起來會(huì)很方便，并且能夠避免額外的信息查詢。
如果將非常少的信息放到單個(gè)事件里，比如ID字段，那么會(huì)節(jié)省大量傳輸數(shù)據(jù)的時(shí)間和金錢成本，但其他信息需要訪問其他服務(wù)才能獲取到。
這其中的利益權(quán)衡，看自己的業(yè)務(wù)來定了。
本文名稱：服務(wù)架構(gòu)：事件驅(qū)動(dòng)架構(gòu)
瀏覽路徑：http://m.5511xx.com/article/dpcjphi.html
