事件驅動架構興起

應用程序編程接口（API）正在推動數字化轉型，並在幾乎所有企業的 IT 環境中佔據主導地位。推動這一流行趨勢的是終端用戶日益增長的需求，他們現在期望數字體驗具有交互性、響應性和即時性。組織正在轉向 API，以創建吸引人的高效體驗，並優化從運營到客戶服務的所有業務領域。事實上，Gartner 2021 年的技術趨勢之一是總體體驗，它定義爲結合多種體驗、客戶體驗和員工體驗來改變業務成果。

但開發人員如何構建滿足這些複雜需求的解決方案？他們正在使用事件驅動架構（EDA）和麪向服務的架構設計 API。使用 EDA，客戶端可以異步訂閱和接收事件，如果兩者都在線，則可以實時訂閱和接收事件，從而使客戶端無需請求更新或狀態更改。通過將架構複雜性的負擔從客戶轉移到生產商，企業可以創造現代用戶期望的流暢體驗。

什麼是事件驅動架構？

EDA 使用事件觸發解耦應用程序、微服務和連接設備之間的通信，並使信息能夠實時流動。爲了真正理解它的全部內容，回顧一下分佈式軟件系統架構的歷史以及它在過去幾十年中是如何發展的是非常有用的。

20 世紀 40 年代的第一批軟件程序使用子例程，根據一組指令執行任務。著名的是，ENIAC 團隊的程序員在第二次世界大戰期間開發了計算導彈軌跡的子程序。

然後，計算架構設計逐漸演變爲以能夠遠程執行多個子例程的編排器系統爲中心。從這個結構中出現了請求 - 響應範式：編排器節點向不同的計算機發送帶有請求的子例程，然後計算機處理請求並將響應返回給原始編排器。

1989 年 Tim Berners-Lee 發明萬維網後，HTTP 成爲部署分佈式系統的首選方法，URL 公開和訪問子例程，這自然導致了 API。隨着業務重點更加關注實時體驗，API 成爲當今企業創新的關鍵驅動力。

API 驅動的用戶體驗

API 通過模擬真實世界的操作來創建體驗。讓我們以一家在線服裝零售商爲例。開發人員可以定義一個 API 來執行下單過程的每個操作。例如，API 可以接受訂單、管理庫存、運行報告和更新交付狀態——所有這些都是實時的。該系統需要一個基於 web 或應用程序的界面，以模擬操作員請求操作或信息。因此，用戶不用打電話，而是通過與界面交互來觸發 API 下單或檢查交付狀態。

以零售商爲例，你可以進一步擴展該服務，以開發模擬整個訂單管理流程的 SaaS 應用程序。例如，你可以定義一組 REST API 來創建訂單並跟蹤從初始訂單到交付的工作流。API 還可以管理訂單履行過程中的操作和物流，並處理業務事務。

該系統生成虛擬對象，對處理訂單所涉及的真實對象進行建模，包括訂單本身、付款交易和送貨單。使用 REST API 對事務對象進行建模，API 設計變得更具邏輯性和細緻入微，因爲你可以直接使用對象的特定端點來查詢對象，而不是用所有查詢重載公共的單一端點。例如，你可以通過查詢訂單端點來查詢訂單的狀態，API 將返回訂單的當前狀態。

REST API 還依賴於通過 HTTP 的請求 - 響應模式，要求客戶端根據需要提交狀態更改或更新請求。當一切順利時，這個系統運行良好。但是，如果出現問題，例如支付失敗或交付延遲，系統將發生故障並影響客戶服務。這樣的事件就變成了業務關鍵的 “事件”。從客戶服務的角度來看，最好讓客戶儘快知道任何問題，而不是讓他們自己去解決。這就是爲什麼現代的、以人爲中心的 SaaS 應用程序必須比基於傳統 REST 方法的應用程序提供更高質量和更實時的交互。

事件驅動 API 的未來

在 REST 框架中，API 不知道對象的狀態。客戶端查詢 API 以瞭解狀態，API 的作用是用信息響應客戶端。

但是，使用事件驅動的 API，客戶可以訂閱 API，有效地指示它監控對象的狀態，並通過實時更新進行報告。因此，行爲從對可重複、獨立請求的無狀態處理轉變爲對模擬真實世界操作的虛擬對象的有狀態感知。

事件驅動的 API 是滿足現代最終用戶需求的一種很好的方法，這些用戶希望定製和即時訪問信息。在一次性定製環境中應用這些 API 很容易。然而，當你需要大規模提供這一級別的服務時，事情會變得更加複雜，而且並非每個企業都準備好處理這一級別的複雜性。爲了避免積累大量的技術債務，組織和開發人員應該將這種複雜性轉移給第三方，讓第三方能夠實時、大規模地同步數字體驗。

有了正確的實時基礎設施支持，組織可以在一系列用例中應用事件驅動的 API。它們在傳統架構下運行良好，並提供滿足現代數字交互需求所需的功能，例如：

更好的實時體驗：事件驅動的 API 吸收了以前分配給最終用戶的許多職責，創造了更多的交互體驗。

降低更改管理開銷：API 將使用者（使用 API 的應用程序）和生產者（服務器）解耦，因爲使用者只需要知道事件的數據格式，而不需要知道哪個服務器正在發送數據。同樣，生產者對使用者的身份不感興趣，從而降低了管理費用。

可伸縮性：API 生產者不需要管理競爭的使用者——事實上，訂閱者的數量與生產者無關。重要的是經紀人將信息傳遞給訂閱者，不管訂閱者是誰，也不管他們的數量有多大。

可擴展性和彈性：松耦合的組件易於就地擴展，迴歸風險低。開發人員還可以在不影響其他消費者的情況下添加功能。類似地，在設計中加入容錯也很容易，因爲可以劃分組件故障。

併發一致性：事件驅動的 API 通過事件和消息順序的不變性以及精確的一次交付，使得在分佈式系統中更容易實現併發性。

優化使用網絡資源：傳統的面向服務的方法往往依賴於基於推送的方法，這往往會消耗服務器的資源，例如連續輪詢。本質上，事件驅動的 API 可以更有效地利用網絡和計算資源。

技術成熟度：事件驅動方法已經存在了近 50 年，但現代在線服務交付系統需要很長時間才能趕上。我們生活在一個激動人心的時代，這兩種技術可以結合起來滿足當今的消費者需求。

EDA 是一種競爭優勢

自 20 世紀 70 年代構思以來，EDA 一直在耐心等待。隨着事件驅動 API 的出現，EDA 正在成爲解決現代業務問題和提供實時用戶體驗的中心舞臺。雖然 EDA 可能不是每個業務挑戰的答案，但當應用到正確的用例時，它可以改變公司的運營和客戶服務。越來越清楚的是，企業要想在現代市場中保持競爭力，就需要知道在何處以及如何使用 EDA。

原文鏈接：

https://thenewstack.io/the-rise-of-event-driven-architecture/

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/9gz8GjjdOZgCjPioxxNKfw