譯者 | 崔皓

策劃 | 云昭

為什么“基于事件”和“事件驅(qū)動(dòng)”這兩個(gè)詞現(xiàn)在幾乎每個(gè)人都會(huì)掛在嘴邊？能否使用現(xiàn)有的REST API來(lái)構(gòu)建事件驅(qū)動(dòng)的架構(gòu)？本文將圍繞這兩個(gè)問(wèn)題展開(kāi)討論。

技術(shù)改變世界，技術(shù)人一直熱衷于讓生活更加便捷?？梢韵胂笕缦聢?chǎng)景，快遞公司1提供了包裹跟蹤服務(wù)，會(huì)通知你包裹在哪一天以及什么時(shí)間范圍內(nèi)到達(dá)（有可能出現(xiàn)達(dá)到時(shí)間由于運(yùn)輸延誤不正確的情況）；快遞公司2主動(dòng)通知你，當(dāng)前包裹離你還有多少站。你會(huì)給予哪家快遞公司好評(píng)？由此可見(jiàn)隨著業(yè)務(wù)的不斷發(fā)展，客戶(hù)對(duì)實(shí)時(shí)應(yīng)用和服務(wù)的需求也在不斷增加。如果你的業(yè)務(wù)應(yīng)用或服務(wù)是面向客戶(hù)的，就需要關(guān)注客戶(hù)期望獲得更直接、實(shí)時(shí)的體驗(yàn)。事件驅(qū)動(dòng)架構(gòu)就越來(lái)越具有戰(zhàn)略重要性了，因此事件驅(qū)動(dòng)架構(gòu)也受到各大公司的青睞。

實(shí)時(shí)應(yīng)用之美和基于事件架構(gòu)的重要性 

就個(gè)人而言，誰(shuí)都不喜歡被消息類(lèi)的通知一直狂轟濫炸。因此，大多數(shù)手機(jī)應(yīng)用程序都關(guān)閉了此功能。但在某些情況下，用戶(hù)又會(huì)需要實(shí)時(shí)或至少接近實(shí)時(shí)的更新?？爝f就是其中之一：用戶(hù)往往更喜歡在遞送人員按門(mén)鈴之前就阻止他，因?yàn)殚T(mén)鈴聲會(huì)讓家中的寵物狗歇斯底里的亂叫?；诖?，用戶(hù)希望有這樣一個(gè)應(yīng)用程序，它會(huì)在快遞離自己家還有一站的時(shí)候就通知我。（通過(guò)實(shí)時(shí)消息的方式通知我，而不是讓用戶(hù)每十分鐘就檢查一次消息狀態(tài)）或者想象有這么一個(gè)值機(jī)的應(yīng)用程序，它會(huì)在更改登機(jī)口時(shí)向您發(fā)送實(shí)時(shí)推送通知 - 如果這種更改發(fā)生在航班起飛前半小時(shí)，這個(gè)應(yīng)用就對(duì)你非常有用，特別是你正在遭遇交通擁堵，為了避免遲到而還不得不趕往登機(jī)口的情況下。消息推送服務(wù)與提供信息的載體無(wú)關(guān)，而關(guān)乎于如何主動(dòng)為客戶(hù)提供實(shí)時(shí)的、可用的服務(wù)。這也是如今被人津津樂(lè)道的客戶(hù)體驗(yàn)。雖說(shuō)客戶(hù)體驗(yàn)并不能改變商業(yè)的游戲規(guī)則，但其產(chǎn)生的服務(wù)差異成為了選擇航空公司的依據(jù)。多數(shù)情況下，應(yīng)用之間的交換是通過(guò)API（通常是REST）實(shí)現(xiàn)的。例如，一個(gè)應(yīng)用程序有一個(gè)更新——一個(gè)包裹已經(jīng)發(fā)貨，或者特定航班的登機(jī)口已經(jīng)改變——而另一個(gè)應(yīng)用程序接收到這個(gè)更新。問(wèn)題是RESTful應(yīng)用程序和服務(wù)本質(zhì)上是基于輪詢(xún)的。這意味著他們以特定的時(shí)間間隔獲取數(shù)據(jù)，甚至僅在被要求時(shí)才要求這樣做（通過(guò)刷新應(yīng)用程序獲取數(shù)據(jù)）。為了提升用戶(hù)體驗(yàn)，并主動(dòng)、實(shí)時(shí)地為用戶(hù)提供信息，我們需要一種與眾不同的機(jī)制，以便立即觸發(fā)業(yè)務(wù)應(yīng)用程序、服務(wù)和系統(tǒng)從而響應(yīng)特定事件。這就是基于事件架構(gòu)存在的意義。

構(gòu)建基于事件架構(gòu)所需的組件 

雖然沒(méi)有一種方法可以構(gòu)建事件驅(qū)動(dòng)的架構(gòu)，并同時(shí)實(shí)現(xiàn)多種變體、協(xié)議和方法。但本質(zhì)上，它由三個(gè)分離的組件組成——事件生產(chǎn)者、事件消費(fèi)者以及事件代理。解耦使得異步處理事件成為可能——這確保了事件生產(chǎn)者和事件消費(fèi)者獨(dú)立工作。

事件驅(qū)動(dòng)架構(gòu)模式

事件生產(chǎn)者

事件生產(chǎn)者本質(zhì)上是事件的發(fā)送者。在上圖的例子中，可以將貨物跟蹤系統(tǒng)或門(mén)店管理系統(tǒng)作為事件生產(chǎn)者。

事件消費(fèi)者?

從邏輯上講，事件消費(fèi)者是事件的接收者。它可以是手機(jī)上的應(yīng)用程序，也可以是公司IT生態(tài)系統(tǒng)中的其他業(yè)務(wù)應(yīng)用，用于檢查或偵聽(tīng)特定事件的發(fā)生，以便做出相應(yīng)的響應(yīng)——例如，通過(guò)手機(jī)上的推送通知觸發(fā)另一個(gè)應(yīng)用。通常，這是通過(guò)訂閱特定事件的事件消費(fèi)者來(lái)實(shí)現(xiàn)的。

事件代理

現(xiàn)在，事件代理是構(gòu)成了基于事件架構(gòu)的重要組成部分，并實(shí)現(xiàn)了事件生產(chǎn)者和事件消費(fèi)者的解耦。事件代理接受來(lái)自前者的事件，并長(zhǎng)期存儲(chǔ)它們，然后將事件發(fā)送給后者。根據(jù)事件消費(fèi)者的數(shù)量，事件代理還負(fù)責(zé)將事件路由到正確的消費(fèi)者。在這種情況下最常用的消息傳遞模式是pub/sub（發(fā)布/訂閱）。異步模式可確保不會(huì)丟失任何消息。即使一個(gè)或多個(gè)事件消費(fèi)者（即訂閱者）在給定時(shí)刻由于某種原因不可用，事件也會(huì)按照產(chǎn)生的順序排隊(duì)等待消費(fèi)。一旦事件消費(fèi)者重新上線(xiàn)，將會(huì)消費(fèi)排隊(duì)的消息并恢復(fù)其先前的活動(dòng)。

REST也能構(gòu)建基于事件的架構(gòu) 

大多數(shù)時(shí)候，當(dāng)搜索有關(guān)如何創(chuàng)建事件驅(qū)動(dòng)架構(gòu)的資訊時(shí)，會(huì)發(fā)現(xiàn)諸如 “Streaming API”和“event-driven API”的術(shù)語(yǔ)。正如您可能知道或猜想的那樣，這些都屬于支持事件驅(qū)動(dòng)通信的新型API。然而，現(xiàn)實(shí)情況是，大多數(shù)軟件應(yīng)用程序供應(yīng)商不提供這些類(lèi)型的API，要么是因?yàn)榇嬖谄渌P(guān)鍵業(yè)務(wù)優(yōu)先級(jí)，要么他們根本沒(méi)有所需的資源。這就是擴(kuò)展現(xiàn)有API以使其適合基于事件架構(gòu)有趣的地方。在談到增強(qiáng)已有的REST API時(shí)，可以根據(jù)API在事件驅(qū)動(dòng)模式中的角色采取如下幾種策略：這些API是事件生產(chǎn)者還是事件消費(fèi)者？當(dāng)REST API是事件生產(chǎn)者時(shí)，解決方法通常非常簡(jiǎn)單；我們只需要一個(gè)支持各種API（包括 REST）和協(xié)議的事件代理——換句話(huà)說(shuō)，它可以幫助將REST轉(zhuǎn)換為AMQP或MQTT等消息協(xié)議。當(dāng)REST API是事件消費(fèi)者時(shí)，解決方法可能會(huì)更復(fù)雜，需要找到機(jī)制來(lái)設(shè)置對(duì)現(xiàn)有REST API或事件代理的主題訂閱，并教他們?nèi)绾位谑录嗛啞＿@通?？梢酝ㄟ^(guò)由webhook、pub/sub-services和服務(wù)器發(fā)送事件組成的事件驅(qū)動(dòng)層來(lái)實(shí)現(xiàn)。

總結(jié)一下：如果公司實(shí)施的業(yè)務(wù)軟件應(yīng)用程序和系統(tǒng)僅提供REST API，您仍然可以圍繞它們構(gòu)建基于事件的架構(gòu)。雖然這樣做會(huì)讓系統(tǒng)顯得復(fù)雜，但有時(shí)需要利用一切可以利用的方法，特別是解決方案并不那么顯而易見(jiàn)的時(shí)候，顯然增加現(xiàn)有API是一種可靠的解決方法。附注：盡管流和事件驅(qū)動(dòng)的API受到如此多的關(guān)注，但REST API不會(huì)很快消失。因?yàn)?，通過(guò)流/事件驅(qū)動(dòng)的API和事件代理增加異步通信的案例沒(méi)有REST API的案例數(shù)量那么多。從這個(gè)角度而言，將會(huì)出現(xiàn)更多融合了REST和流/事件驅(qū)動(dòng)API的混合架構(gòu)。

應(yīng)用程序集成中的事件驅(qū)動(dòng)方法 

基于事件的架構(gòu)不僅可以通過(guò)應(yīng)用和服務(wù)提供出色的客戶(hù)體驗(yàn)。它應(yīng)用集成方面也非常表現(xiàn)出色——除了可以實(shí)時(shí)數(shù)據(jù)同步，還可以節(jié)省大量資源。德國(guó)一家最大的私營(yíng)啤酒廠希望建立強(qiáng)大的360度客戶(hù)視圖并簡(jiǎn)化其跨渠道的營(yíng)銷(xiāo)工作，旨在實(shí)現(xiàn)個(gè)性化消息傳遞并最終獲得出色的客戶(hù)服務(wù)和滿(mǎn)意度。在該項(xiàng)目的第一階段，他們的專(zhuān)注于應(yīng)用節(jié)點(diǎn)的鏈接，他們將Salesforce CRM以及Exponea的客戶(hù)數(shù)據(jù)和體驗(yàn)平臺(tái)之間的數(shù)據(jù)進(jìn)行互聯(lián)互通。為了確保各種記錄系統(tǒng)之間的無(wú)縫連接，該公司使用webhook和AMQP來(lái)觸發(fā)集成流，只要應(yīng)用和系統(tǒng)支持webhook或事件總線(xiàn)推送數(shù)據(jù)的能力就可以順利達(dá)成。并且在Pub/Sub的幫助下，將每個(gè)集成流程保持在盡可能小的范圍內(nèi)，從而實(shí)現(xiàn)了模塊化的流程架構(gòu)。此外，不僅在兩個(gè)系統(tǒng)之間同步數(shù)據(jù)，還要將同步數(shù)據(jù)的系統(tǒng)數(shù)量提升到3-5個(gè)， Pub/Sub允許將這些流分成小塊并在它們之間動(dòng)態(tài)傳播更新。

寫(xiě)在最后 

本文并不打算一步步地描述如何構(gòu)建基于事件的架構(gòu)，因?yàn)橛刑嗟挠美枰紤]，也有太多的支持技術(shù)需要提及，無(wú)法將其打包成一篇文章。同時(shí)也會(huì)有太多的變量需要考慮：例如IT 基礎(chǔ)設(shè)施、技術(shù)堆棧的個(gè)人偏好以及可用資源等。希望通過(guò)本篇文章圍繞“如何在現(xiàn)有的API環(huán)境之上創(chuàng)建基于事件驅(qū)動(dòng)的架構(gòu)”這個(gè)問(wèn)題的探討，給各位朋友帶來(lái)一些有意的思考。

原文鏈接：https://dzone.com/articles/creating-event-based-architecture-on-top-of-existi?fromrel=true

譯者介紹

崔皓，51CTO社區(qū)編輯，資深架構(gòu)師，擁有18年的軟件開(kāi)發(fā)和架構(gòu)經(jīng)驗(yàn)，10年分布式架構(gòu)經(jīng)驗(yàn)。曾任惠普技術(shù)專(zhuān)家。樂(lè)于分享，撰寫(xiě)了很多熱門(mén)技術(shù)文章，閱讀量超過(guò)60萬(wàn)?！斗植际郊軜?gòu)原理與實(shí)踐》作者。