EDA事件驅(qū)動(dòng)架構(gòu)具有什么特點(diǎn)和優(yōu)缺點(diǎn)？

隨著互聯(lián)網(wǎng)和移動(dòng)互聯(lián)網(wǎng)的快速發(fā)展，越來(lái)越多的應(yīng)用程序需要處理海量數(shù)據(jù)和大量的并發(fā)請(qǐng)求。傳統(tǒng)的軟件架構(gòu)已經(jīng)無(wú)法滿足這些需求，因此，一些新的架構(gòu)模式開(kāi)始受到關(guān)注。其中，事件驅(qū)動(dòng)架構(gòu)(Event-Driven Architecture，EDA)因其高效、可擴(kuò)展和靈活等優(yōu)點(diǎn)，逐漸成為熱門(mén)的選擇。本文將探討事件驅(qū)動(dòng)架構(gòu)在實(shí)際應(yīng)用中的優(yōu)勢(shì)和挑戰(zhàn)。

一、事件驅(qū)動(dòng)架構(gòu)的概述

事件驅(qū)動(dòng)架構(gòu)是一種基于事件和消息的軟件架構(gòu)模式，其核心思想是將應(yīng)用程序設(shè)計(jì)為響應(yīng)事件的系統(tǒng)。在這種架構(gòu)中，事件是系統(tǒng)中發(fā)生的某種事情，可以是用戶行為、設(shè)備狀態(tài)變化等。當(dāng)事件發(fā)生時(shí)，系統(tǒng)會(huì)產(chǎn)生相應(yīng)的消息，該消息會(huì)被傳遞給感興趣的組件進(jìn)行處理。組件可以是其他應(yīng)用程序、服務(wù)或者處理器等，它們通過(guò)訂閱消息的方式來(lái)接收事件。

事件驅(qū)動(dòng)架構(gòu)與傳統(tǒng)的請(qǐng)求響應(yīng)模式相比，最大的不同在于處理方式。傳統(tǒng)的請(qǐng)求響應(yīng)模式是基于事務(wù)的，即客戶端發(fā)起請(qǐng)求，服務(wù)端進(jìn)行處理并返回響應(yīng)。而事件驅(qū)動(dòng)架構(gòu)是基于消息的，即系統(tǒng)會(huì)在事件發(fā)生時(shí)異步地發(fā)送消息給感興趣的組件進(jìn)行處理。這種異步的處理方式可以使系統(tǒng)更加靈活、可擴(kuò)展和高效。

二、事件驅(qū)動(dòng)架構(gòu)的優(yōu)勢(shì)

1. 可擴(kuò)展性

事件驅(qū)動(dòng)架構(gòu)是一種高度可擴(kuò)展的架構(gòu)模式。由于事件是異步的，不同的事件可以由不同的組件進(jìn)行處理。因此，可以根據(jù)應(yīng)用程序的需求，動(dòng)態(tài)地添加或刪除組件，以實(shí)現(xiàn)系統(tǒng)的可擴(kuò)展性。

2. 高效性

事件驅(qū)動(dòng)架構(gòu)可以提高系統(tǒng)的處理效率。由于事件是異步的，組件可以在事件發(fā)生時(shí)立即進(jìn)行處理，而不需要等待請(qǐng)求的響應(yīng)。這種異步的處理方式可以提高系統(tǒng)的響應(yīng)速度和吞吐量。

當(dāng)類或組件之間內(nèi)聚性很高，它們的耦合度應(yīng)該很低，也就是說(shuō)當(dāng)組件需要相互協(xié)作調(diào)用時(shí)，比如我們假設(shè)一個(gè)組件“A”需要觸發(fā)組件“B”中的一些邏輯，自然的方式是直接讓組件A調(diào)用組件B中的一個(gè)方法。但前提是A必須知道B的存在，這樣它們之間就是耦合的，A必須依賴于B了，這會(huì)使得系統(tǒng)更難以改變和維護(hù)。因此，這里可以使用事件來(lái)防止這種直接調(diào)用的耦合。

此外，使用事件實(shí)現(xiàn)組件解耦也有其另外的，如果我們有一個(gè)只負(fù)責(zé)組件B的工作團(tuán)隊(duì)，那么他們則可能不需要與負(fù)責(zé)組件A的團(tuán)隊(duì)進(jìn)行交流，直接針對(duì)組件A中的邏輯改變?cè)诮M件B中做出相對(duì)反應(yīng)。兩個(gè)組件團(tuán)隊(duì)可以獨(dú)立發(fā)展(banq注：微服務(wù)特點(diǎn)之一)， 我們的應(yīng)用系統(tǒng)變得更靈活。

即使在同一個(gè)組件團(tuán)隊(duì)中，有時(shí)候我們不需要在同一請(qǐng)求/響應(yīng)中立即執(zhí)行一個(gè)動(dòng)作的結(jié)果，只要異步執(zhí)行這個(gè)動(dòng)作，比如發(fā)送電子郵件。在這種情況下，我們可以立即向用戶返回響應(yīng)，并以異步方式發(fā)送電子郵件，并避免讓用戶等待發(fā)送電子郵件。

不過(guò)，如果我們不加區(qū)別地使用它，也有危險(xiǎn)。我們會(huì)遇到邏輯流程的風(fēng)險(xiǎn)，這些邏輯流程在概念上是高度凝聚力的，但是通過(guò)采取脫鉤機(jī)制的事件連接在一起。換句話說(shuō)，應(yīng)該在一起的代碼將被分開(kāi)，并且難以跟蹤它的流程(類似于goto語(yǔ)句)，不易于理解：可能是意大利面一樣混在一起!

為了防止將我們的代碼庫(kù)變成一大堆意大利面條，我們應(yīng)該將事件的使用限制在明確的情況下。根據(jù)我的經(jīng)驗(yàn)，有三種使用事件的情況：

(1)去耦組件

(2)執(zhí)行異步任務(wù)

(3)跟蹤狀態(tài)變化(審核日志)

1.去耦組件(微服務(wù))

當(dāng)組件A執(zhí)行的邏輯需要觸發(fā)組件B的邏輯時(shí)，不要直接調(diào)用它，我們可以將觸發(fā)事件發(fā)送到事件分派器。組件B將偵聽(tīng)調(diào)度程序中的特定事件，并在事件發(fā)生時(shí)執(zhí)行操作。

這意味著A和B都將取決于調(diào)度器和事件，但他們之間將不會(huì)知道對(duì)方存在，它們將被解耦。

理想情況下，調(diào)度員和事件都不應(yīng)該在兩個(gè)組件之間存在：

(1)調(diào)度員應(yīng)該是完全獨(dú)立于我們應(yīng)用程序的庫(kù)，因此使用依賴管理系統(tǒng)安裝在通用位置。在PHP世界中，這是使用Composer等安裝在vendor文件夾中的東西。

(2) 事件是我們的應(yīng)用程序的一部分，應(yīng)該在兩個(gè)組件之間生存，組件之間通過(guò)事件進(jìn)行通訊(結(jié)構(gòu)上解耦，行為上耦合)。事件在組件之間共享，它是應(yīng)用程序的核心部分。事件在DDD中屬于共享內(nèi)核Shared Kernel的一部分。這樣，兩個(gè)組件都將依賴于共享內(nèi)核，但彼此不會(huì)意識(shí)到。然而在單體Monolithic應(yīng)用程序中，為方便起見(jiàn)，可以將其放在觸發(fā)事件的組件中。

DDD共享內(nèi)核

[。..]明確界定指定團(tuán)隊(duì)同意分享的領(lǐng)域模型的一些子集。保持這個(gè)內(nèi)核很小。[。..]這個(gè)明確共享的東西有特殊的地位，如果沒(méi)有與其他團(tuán)隊(duì)協(xié)商，不應(yīng)該改變。

Eric Evans 2014， 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)參考

2.執(zhí)行異步任務(wù)

有時(shí)候我們有一個(gè)我們想要執(zhí)行的邏輯，但它可能需要相當(dāng)長(zhǎng)的時(shí)間來(lái)執(zhí)行，我們不想讓用戶等待它完成。在這種情況下，希望將其作為異步工作運(yùn)行，并立即返回給用戶的消息，通知他請(qǐng)求將在以后異步執(zhí)行。

例如，在網(wǎng)上商店下訂單可以同步完成，但發(fā)送通知用戶的電子郵件可以進(jìn)行異步。

在這種情況下，我們可以做的是觸發(fā)一個(gè)將被排隊(duì)的事件，直到一個(gè)工作任務(wù)可以獲得這個(gè)事件并執(zhí)行它，只要系統(tǒng)有資源。

在這些情況下，相關(guān)聯(lián)的邏輯是否在相同的有界環(huán)境中并不重要，無(wú)論哪種方式，邏輯都是去耦的。

3.跟蹤狀態(tài)變化(審計(jì)日志)

以傳統(tǒng)的數(shù)據(jù)存儲(chǔ)方式，我們擁有一些數(shù)據(jù)的實(shí)體。當(dāng)這些實(shí)體中的數(shù)據(jù)發(fā)生變化時(shí)，我們只需更新數(shù)據(jù)庫(kù)表行以反映新值。

這里的問(wèn)題是，我們并不存儲(chǔ)這些值為什么改變且什么時(shí)候改變。

我們可以將這些改變的事件存儲(chǔ)在審計(jì)日志中。

更多關(guān)于這個(gè)進(jìn)一步的前景，在關(guān)于事件溯源的解釋。

事件模式

Martin Fowler確定了三種不同類型的事件模式：

(1)事件通知

(2)事件執(zhí)行狀態(tài)轉(zhuǎn)移

(3)事件溯源Event Sourcing

所有這些模式共享相同的關(guān)鍵概念：

(1)事件是代表發(fā)生了一些事情(發(fā)生在某事之后);

(2)事件被廣播到正在監(jiān)聽(tīng)的任何代碼(代碼可以對(duì)事件做出反應(yīng))。

一。 事件通知

假設(shè)我們有一個(gè)具有明確定義的組件作為應(yīng)用程序核心。理想情況下，這些組件是完全相互分離的，但是它們的一些功能需要在其他組件中執(zhí)行一些邏輯。

最典型的情況如前所述：當(dāng)組件A執(zhí)行的邏輯需要觸發(fā)組件B的邏輯時(shí)，A不是直接去調(diào)用B，而是觸發(fā)事件將且發(fā)送到事件調(diào)度程序。組件B將偵聽(tīng)調(diào)度程序中的特定事件，并在事件發(fā)生時(shí)執(zhí)行操作。

重要的是，這種模式的一個(gè)特征是事件攜帶最少的數(shù)據(jù)。它只為聽(tīng)眾提供足夠的數(shù)據(jù)，以便知道發(fā)生了什么并執(zhí)行其代碼，通常只是實(shí)體ID，也可能是事件創(chuàng)建的日期和時(shí)間。

優(yōu)點(diǎn)

(1)彈性更大：將事件排隊(duì)后，發(fā)送方組件可以繼續(xù)執(zhí)行其自己邏輯，即使由于錯(cuò)誤發(fā)生，因?yàn)樗鼈兣抨?duì)等候，它們可以在錯(cuò)誤被修復(fù)時(shí)被執(zhí)行。

(2)降低延遲，如果事件排隊(duì)，用戶不需要等待該邏輯執(zhí)行;

團(tuán)隊(duì)可以獨(dú)立發(fā)展組件，使他們的工作更輕松，更快，更容易出現(xiàn)問(wèn)題，更靈活;

缺點(diǎn)

(1)如果沒(méi)有使用標(biāo)準(zhǔn)，有可能變成一堆意大利面條代碼。

二。 事件執(zhí)行狀態(tài)轉(zhuǎn)移

讓我們?cè)俅慰纯辞懊胬樱粋€(gè)具有明確定義的組件作為應(yīng)用程序核心。如果A組件一些功能需要來(lái)自其他組件的數(shù)據(jù)。獲得該數(shù)據(jù)的最自然的方法是詢問(wèn)其他組件，但這意味著被查詢組件必須提供查詢方法以供查詢組件使用，一次兩次修改增加無(wú)所謂，如果頻繁要求被查詢組件提供新的查詢方法，說(shuō)明這兩個(gè)組件彼此耦合!

在組件之間共享數(shù)據(jù)的另一種方法是：擁有數(shù)據(jù)的組件觸發(fā)的更改事件時(shí)，該事件將攜帶全新更改后的數(shù)據(jù)。對(duì)該數(shù)據(jù)感興趣的組件將會(huì)監(jiān)聽(tīng)這些事件，從事件中獲得數(shù)據(jù)并存儲(chǔ)該數(shù)據(jù)的本地副本，然后進(jìn)一步對(duì)這些全新數(shù)據(jù)做出反應(yīng)。這樣，當(dāng)他們需要外部數(shù)據(jù)時(shí)，他們其實(shí)在本地已經(jīng)擁有它們，它們將不需要查詢其他組件，也不需要其他組件提供對(duì)應(yīng)的查詢方法。

單體架構(gòu)

如果使用最早的單體架構(gòu)部署，作為最傳統(tǒng)的應(yīng)用部署模式，是將整個(gè)應(yīng)用程序作為一個(gè)單一的、緊密耦合的單元進(jìn)行開(kāi)發(fā)和部署。

在這種情況下，MP4文件轉(zhuǎn)換為WMV格式的功能將作為應(yīng)用程序的一部分實(shí)現(xiàn)。整個(gè)應(yīng)用程序在一個(gè)部署單元中運(yùn)行，包括處理用戶界面、業(yè)務(wù)邏輯和數(shù)據(jù)訪問(wèn)等功能。

遇到問(wèn)題

使用這種模式，問(wèn)題非常明顯，雖然部署簡(jiǎn)單，但會(huì)導(dǎo)致代碼和功能之間的緊密耦合，遇到局部bug會(huì)影響整個(gè)應(yīng)用功能運(yùn)行，可伸縮性受限，整個(gè)應(yīng)用程序需要按照最高負(fù)載需求進(jìn)行伸縮，而不僅僅是轉(zhuǎn)換文件的功能。這可能導(dǎo)致資源浪費(fèi)和低效的資源利用，另外也會(huì)存在單點(diǎn)故障問(wèn)題，如果應(yīng)用程序的某個(gè)組件出現(xiàn)故障，整個(gè)應(yīng)用程序都會(huì)受到影響。

在單體架構(gòu)中，所有的功能模塊都被打包在一起，共享同一個(gè)數(shù)據(jù)庫(kù)和用戶界面。單體架構(gòu)在早期的軟件開(kāi)發(fā)中非常常見(jiàn)，因?yàn)樗?jiǎn)單、易于理解和實(shí)現(xiàn)，但受限于可擴(kuò)展、可維護(hù)性、高可用性等問(wèn)題，單體架構(gòu)逐漸被時(shí)代淘汰。

容器技術(shù)/微服務(wù)

為了解決單體架構(gòu)存在問(wèn)題，容器技術(shù)孕育而生，直至docker容器技術(shù)出現(xiàn)，行業(yè)改變了以往的架構(gòu)模式。

從過(guò)去以物理機(jī)和虛擬機(jī)為主體的開(kāi)發(fā)運(yùn)維環(huán)境，向以容器為核心的基礎(chǔ)設(shè)施的轉(zhuǎn)變過(guò)程，這并不是一次溫和的改革，而是涵蓋了對(duì)網(wǎng)絡(luò)、存儲(chǔ)、調(diào)度、操作系統(tǒng)、分布式原理等各個(gè)方面的容器化理解和改造。

容器技術(shù)發(fā)展徹底釋放了微服務(wù)天性，在單體架構(gòu)部署存在的問(wèn)題，在微服務(wù)架構(gòu)中，應(yīng)用程序被拆分為多個(gè)小型、獨(dú)立部署的服務(wù)，每個(gè)服務(wù)專注于一個(gè)特定的功能。對(duì)于MP4文件轉(zhuǎn)換為WMV格式的過(guò)程，可以將其作為一個(gè)單獨(dú)的轉(zhuǎn)換服務(wù)實(shí)現(xiàn)，甚至可以根據(jù)轉(zhuǎn)換過(guò)程進(jìn)一步拆分，實(shí)現(xiàn)更精細(xì)化管理，每個(gè)服務(wù)可以獨(dú)立部署和伸縮，提供更好的靈活性和可擴(kuò)展性，服務(wù)之間都是獨(dú)立的，可以獨(dú)立開(kāi)發(fā)、測(cè)試、擴(kuò)展和部署。

遇到問(wèn)題

隨之而來(lái)地系統(tǒng)復(fù)雜性增加，微服務(wù)架構(gòu)引入了分布式系統(tǒng)的復(fù)雜性，包括服務(wù)之間的通信、數(shù)據(jù)一致性和故障處理等方面。

部署和管理成本增加，管理多個(gè)服務(wù)的部署和運(yùn)維需要更多的工作和資源。

企業(yè)需求

對(duì)于企業(yè)，如果希望既要實(shí)現(xiàn)高效、可伸縮、高可用等功能，同時(shí)提高團(tuán)隊(duì)人員效率，開(kāi)發(fā)者可以專注于編寫(xiě)業(yè)務(wù)邏輯，而無(wú)需擔(dān)心服務(wù)器的配置、擴(kuò)展或管理。

還是之前“MP4文件轉(zhuǎn)換為WMV格式存儲(chǔ)到數(shù)據(jù)”例子中，如何實(shí)現(xiàn)開(kāi)發(fā)者可以專注于編寫(xiě)業(yè)務(wù)邏輯，而無(wú)需擔(dān)心服務(wù)器的配置、擴(kuò)展或管理問(wèn)題?

可以通過(guò)兩個(gè)步驟來(lái)了解：

1、Serverless服務(wù)

2、事件驅(qū)動(dòng)架構(gòu)(EDA)

Serverless在基礎(chǔ)設(shè)施端解決運(yùn)維困擾

在Serverless計(jì)算服務(wù)中，開(kāi)發(fā)人員只需關(guān)注應(yīng)用程序的業(yè)務(wù)邏輯，云服務(wù)提供商將負(fù)責(zé)管理和調(diào)配計(jì)算資源，平臺(tái)根據(jù)需求自動(dòng)擴(kuò)展計(jì)算資源，以適應(yīng)變化的工作負(fù)載，同時(shí)按使用付費(fèi)，根據(jù)實(shí)際使用的計(jì)算資源付費(fèi)，避免了長(zhǎng)期維護(hù)和不必要的成本。

EDA讓開(kāi)發(fā)者可以專注于編寫(xiě)業(yè)務(wù)邏輯使用事件驅(qū)動(dòng)架構(gòu)

使用EDA架構(gòu)來(lái)實(shí)現(xiàn)將MP4文件轉(zhuǎn)換為WMV格式的過(guò)程可以提供一種高度可擴(kuò)展和靈活的方式。