譯者 | 布加迪

審校 | 孫淑娟

數(shù)據(jù)在急劇增多。全球每天生成的數(shù)據(jù)量三年后將達到463 EB。相比之下，人類迄今生成的所有單詞量估計總共也就5 EB。

為了在當(dāng)今的數(shù)字經(jīng)濟下取得成功，許多企業(yè)在實施戰(zhàn)略以使用和分析所有這些數(shù)據(jù)，以便實時做出正確的業(yè)務(wù)決策。據(jù)估計，到2025年，每個聯(lián)網(wǎng)人員的平均每日數(shù)字交互次數(shù)將達到5000次。企業(yè)需要能夠滿足這種對實時數(shù)據(jù)、流程和用戶體驗日益增長的需求。

一種策略是使用事件驅(qū)動架構(gòu)。事件驅(qū)動架構(gòu)是一種軟件設(shè)計模式，它讓企業(yè)可以針對客戶交易等業(yè)務(wù)事件進行實時操作。事件驅(qū)動架構(gòu)不是什么新概念，自1970年代就以來一直存在了。直到最近，這項技術(shù)才真正為企業(yè)和消費者提供實時服務(wù)。

事件驅(qū)動架構(gòu)現(xiàn)在備受關(guān)注，能夠解決現(xiàn)代業(yè)務(wù)問題，提供出眾的消費者體驗。

一、事件驅(qū)動架構(gòu)的工作原理及好處

事件驅(qū)動架構(gòu)基于事件，向相關(guān)方發(fā)出業(yè)務(wù)系統(tǒng)發(fā)生狀態(tài)變化的信號。比如說，事件可以是在線購買、產(chǎn)品發(fā)貨或產(chǎn)品送到客戶家門口。事件在所有行業(yè)都在不斷發(fā)生。

事件驅(qū)動架構(gòu)中有生產(chǎn)者和消費者。生產(chǎn)者觸發(fā)事件，而事件通過事件頻道作為消息被發(fā)送給感興趣的消費者，事件在事件頻道中被異步處理。生產(chǎn)者和消費者不必等待對方即可開始下一個任務(wù)，因為生產(chǎn)者與接收者松散耦合或完全解耦。

由于分離了通信和業(yè)務(wù)邏輯，解耦還提高了可擴展性。如果訂閱者離線或消費減慢速度，發(fā)布者可以避免瓶頸并且不受影響。如果訂閱者難以跟上事件的步伐，事件流會記錄事件供將來檢索。發(fā)布者可以繼續(xù)發(fā)送通知而不受吞吐量限制，并且有很強的故障恢復(fù)能力。

發(fā)布/訂閱（pub/sub）是事件驅(qū)動架構(gòu)中的一種常見設(shè)計模式，它為發(fā)布者和訂閱者之間交換消息提供了一種框架。消息代理接收發(fā)布者的所有事件，并將發(fā)生的事件實時路由到訂閱者，即注冊接收事件的那些人。代理還記錄事件。消費者可隨時訪問事件流，它們可以讀取最新的消息，或處理自上次檢查事件流以來收到的一系列消息。

如果使用消息代理，發(fā)布者不知道訂閱者，即使感興趣的有關(guān)方數(shù)量增加，發(fā)布者也不會受到影響。發(fā)布到代理讓生產(chǎn)者有機會跨不同的設(shè)備和平臺向一系列消費者傳遞通知。

二、實施事件驅(qū)動架構(gòu)面臨的挑戰(zhàn)

將功能做入到應(yīng)用程序中以提供大規(guī)模實時體驗有風(fēng)險、很復(fù)雜、很費錢、很費時。組織最初可能會花費數(shù)月時間用現(xiàn)成的組件搭建定制的解決方案。隨著團隊需要應(yīng)對規(guī)模和可靠性要求帶來的復(fù)雜性，所需的時間很可能變成數(shù)年。

許多應(yīng)用程序依賴一系列相互依賴的消息。然而，如果這些消息丟失或無序，會影響用戶體驗，并且客戶數(shù)據(jù)在此過程中可能受損或丟失。提供具有數(shù)據(jù)完整性的實時數(shù)字體驗所需的技術(shù)很復(fù)雜，并且常常導(dǎo)致不可接受的取舍，比如公司為了數(shù)據(jù)完整性而犧牲大規(guī)模性能。

還有性能問題。設(shè)計、構(gòu)建和擴展實時功能時，延遲不佳或不可預(yù)測、高帶寬消費方面的問題會給應(yīng)用程序開發(fā)人員帶來不確定性。除了盡量降低延遲和帶寬要求外，組織還必須盡量避免這些措施方面的差異，為開發(fā)人員提供可預(yù)測性，確保交付的體驗具有競爭力。組織也很難設(shè)計、構(gòu)建和運營自己的全球分布式容錯實時基礎(chǔ)架構(gòu)。為了實現(xiàn)容錯，組織需要在多個數(shù)據(jù)中心擁有多個冗余部件，以便其他部件丟失時保持系統(tǒng)正常運行。

組織開始擴展時，要么獲得構(gòu)建基礎(chǔ)架構(gòu)的方式帶來的好處，要么承受帶來的后果。不到位的基礎(chǔ)架構(gòu)無法擴展，或無法提供滿足客戶實時要求所需的彈性。此外，對于大多數(shù)組織而言，為事件驅(qū)動架構(gòu)構(gòu)建自己的基礎(chǔ)架構(gòu)只會分散注意力，無法一心開發(fā)真正使其產(chǎn)品與眾不同的實時體驗。要做到可以依靠基礎(chǔ)架構(gòu)提供有競爭力的體驗這地步，就需要團隊招聘許多人，并且培養(yǎng)技能，這可能與業(yè)務(wù)核心幾乎沒多大相關(guān)性。

三、Ably發(fā)布/訂閱消息

為了克服這些挑戰(zhàn)，Ably邊緣消息傳遞平臺提供了相應(yīng)的API，從而使開發(fā)人員能夠構(gòu)建實時通信的應(yīng)用程序和基礎(chǔ)架構(gòu)，而組織無需管理規(guī)模、延遲、消息完整性或網(wǎng)絡(luò)中斷。

任意數(shù)量的訂閱設(shè)備將實時接收從設(shè)備發(fā)布到Ably的消息。為此，Ably將消息流量組織到命名頻道中。一旦連接到Ably，客戶端可以是發(fā)布者（向Ably推送消息）、訂閱者（等待消息從Ably推送）或兩者兼而有之。雖然Ably可能會傳遞數(shù)十億條消息，但訂閱者只會在它們訂閱的頻道上收到消息。

頻道提供了一種實現(xiàn)發(fā)布/訂閱模式的方法，允許發(fā)布者快速有效地將數(shù)據(jù)推送給訂閱者。新數(shù)據(jù)被推送給訂閱者，那樣它們不必輪詢服務(wù)器即可檢查新數(shù)據(jù)。

Ably的存在（presence）功能讓客戶端可以在頻道上宣布其存在。存在功能使開發(fā)人員能夠構(gòu)建聊天室、多人游戲或協(xié)作工具等協(xié)作應(yīng)用，因為Ably可自動跟蹤誰在任何設(shè)備上實時存在。頻道上存在的每個成員都有唯一的客戶端標(biāo)識符和可選的有效負載以描述成員的狀態(tài)，比如進入頻道、更新狀態(tài)或離開頻道。其他設(shè)備或服務(wù)實時訂閱這些存在事件。

Ably是一個全球分布式系統(tǒng)，頻道可以在多個區(qū)域獨立活躍，從而不會出現(xiàn)單一故障點或擁塞點。

下圖說明了Ably如何解決高效全球路由的挑戰(zhàn)：

圖1

紐約的發(fā)布者專用服務(wù)器使用基于延遲的路由被路由到最近的數(shù)據(jù)中心（US East）。發(fā)布到US East的消息A被路由到US East的客戶端，并且一次被路由到托管訂閱這些消息的客戶端的其他每個數(shù)據(jù)中心。所有其他區(qū)域的訂閱客戶端將從它們連接的數(shù)據(jù)中心接收消息。

倫敦的發(fā)布者和訂閱者客戶端使用基于延遲的路由被路由到最近的數(shù)據(jù)中心（EU West）。發(fā)布到EU West的消息B被路由到EU West的訂閱客戶端，并且一次被路由到托管訂閱這些消息的客戶端的其他每個數(shù)據(jù)中心。所有其他區(qū)域的訂閱客戶端從它們連接的數(shù)據(jù)中心接收消息B。

四、實時體驗的未來

數(shù)字體驗正在經(jīng)歷一場實時革命。消費者要求數(shù)字體驗是即時的。因此，組織必須實時同步數(shù)據(jù)。隨著更多的設(shè)備上線，企業(yè)調(diào)整以適應(yīng)更復(fù)雜的實時數(shù)據(jù)經(jīng)濟，它們需要更簡單、更可靠的基礎(chǔ)架構(gòu)，以滿足當(dāng)今和未來的實時數(shù)據(jù)同步需求，到時日常服務(wù)將依靠不斷變化的數(shù)據(jù)。

原文鏈接：https://www.infoworld.com/article/3669414/the-benefits-and-challenges-of-event-driven-architecture.html