譯者 | 崔皓

策劃 | 云昭

為什么“基于事件”和“事件驅動”這兩個詞現(xiàn)在幾乎每個人都會掛在嘴邊？能否使用現(xiàn)有的REST API來構建事件驅動的架構？本文將圍繞這兩個問題展開討論。

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

實時應用之美和基于事件架構的重要性 

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

構建基于事件架構所需的組件 

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

事件驅動架構模式

事件生產者

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

事件消費者?

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

事件代理

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

REST也能構建基于事件的架構 

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

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

應用程序集成中的事件驅動方法 

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

寫在最后 

本文并不打算一步步地描述如何構建基于事件的架構，因為有太多的用例需要考慮，也有太多的支持技術需要提及，無法將其打包成一篇文章。同時也會有太多的變量需要考慮：例如IT 基礎設施、技術堆棧的個人偏好以及可用資源等。希望通過本篇文章圍繞“如何在現(xiàn)有的API環(huán)境之上創(chuàng)建基于事件驅動的架構”這個問題的探討，給各位朋友帶來一些有意的思考。

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

譯者介紹

崔皓，51CTO社區(qū)編輯，資深架構師，擁有18年的軟件開發(fā)和架構經驗，10年分布式架構經驗。曾任惠普技術專家。樂于分享，撰寫了很多熱門技術文章，閱讀量超過60萬?！斗植际郊軜嬙砼c實踐》作者。