譯者 | 崔皓

策劃 | 云昭

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

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

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

就個人而言，誰都不喜歡被消息類的通知一直狂轟濫炸。因此，大多數手機應用程序都關閉了此功能。但在某些情況下，用戶又會需要實時或至少接近實時的更新。快遞就是其中之一：用戶往往更喜歡在遞送人員按門鈴之前就阻止他，因為門鈴聲會讓家中的寵物狗歇斯底里的亂叫。基于此，用戶希望有這樣一個應用程序，它會在快遞離自己家還有一站的時候就通知我。（通過實時消息的方式通知我，而不是讓用戶每十分鐘就檢查一次消息狀態）或者想象有這么一個值機的應用程序，它會在更改登機口時向您發送實時推送通知 - 如果這種更改發生在航班起飛前半小時，這個應用就對你非常有用，特別是你正在遭遇交通擁堵，為了避免遲到而還不得不趕往登機口的情況下。

消息推送服務與提供信息的載體無關，而關乎于如何主動為客戶提供實時的、可用的服務。這也是如今被人津津樂道的客戶體驗。雖說客戶體驗并不能改變商業的游戲規則，但其產生的服務差異成為了選擇航空公司的依據。多數情況下，應用之間的交換是通過API（通常是REST）實現的。例如，一個應用程序有一個更新——一個包裹已經發貨，或者特定航班的登機口已經改變——而另一個應用程序接收到這個更新。問題是RESTful應用程序和服務本質上是基于輪詢的。這意味著他們以特定的時間間隔獲取數據，甚至僅在被要求時才要求這樣做（通過刷新應用程序獲取數據）。為了提升用戶體驗，并主動、實時地為用戶提供信息，我們需要一種與眾不同的機制，以便立即觸發業務應用程序、服務和系統從而響應特定事件。這就是基于事件架構存在的意義。

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

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

事件驅動架構模式

事件生產者

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

事件消費者

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

事件代理

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

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

大多數時候，當搜索有關如何創建事件驅動架構的資訊時，會發現諸如 “Streaming API”和“event-driven API”的術語。正如您可能知道或猜想的那樣，這些都屬于支持事件驅動通信的新型API。然而，現實情況是，大多數軟件應用程序供應商不提供這些類型的API，要么是因為存在其他關鍵業務優先級，要么他們根本沒有所需的資源。這就是擴展現有API以使其適合基于事件架構有趣的地方。在談到增強已有的REST API時，可以根據API在事件驅動模式中的角色采取如下幾種策略：這些API是事件生產者還是事件消費者？

當REST API是事件生產者時，解決方法通常非常簡單；我們只需要一個支持各種API（包括 REST）和協議的事件代理——換句話說，它可以幫助將REST轉換為AMQP或MQTT等消息協議。當REST API是事件消費者時，解決方法可能會更復雜，需要找到機制來設置對現有REST API或事件代理的主題訂閱，并教他們如何基于事件訂閱。這通常可以通過由webhook、pub/sub-services和服務器發送事件組成的事件驅動層來實現。

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

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

基于事件的架構不僅可以通過應用和服務提供出色的客戶體驗。它應用集成方面也非常表現出色——除了可以實時數據同步，還可以節省大量資源。德國一家最大的私營啤酒廠希望建立強大的360度客戶視圖并簡化其跨渠道的營銷工作，旨在實現個性化消息傳遞并最終獲得出色的客戶服務和滿意度。在該項目的第一階段，他們的專注于應用節點的鏈接，他們將Salesforce CRM以及Exponea的客戶數據和體驗平臺之間的數據進行互聯互通。

為了確保各種記錄系統之間的無縫連接，該公司使用webhook和AMQP來觸發集成流，只要應用和系統支持webhook或事件總線推送數據的能力就可以順利達成。并且在Pub/Sub的幫助下，將每個集成流程保持在盡可能小的范圍內，從而實現了模塊化的流程架構。此外，不僅在兩個系統之間同步數據，還要將同步數據的系統數量提升到3-5個， Pub/Sub允許將這些流分成小塊并在它們之間動態傳播更新。

寫在最后

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

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