針對以事件為導向的結構使用正確的工具和模式

以事件為導向的結構支援事件的有效生產與耗用,其會傳達系統或應用程式狀態變更。這些結構可啟用系統之間的彈性連線,並支援流程,以及跨系統運作的近乎即時更新。雖然事件驅動結構的優點很容易看見,但實作詳細資料並非總是如此明確。您在以事件為導向的結構模式中需要考量哪些功能?這些模式可解決哪些特定問題?解決方案適用的特殊考量事項為何,以及處理解決方案的最佳模式為何?

本指南呈現使用 Salesforce 技術時,用來建立最佳事件驅動結構的模式。其中也會討論 Salesforce 提供的撤銷工具,並提供用於選取使用個案的工具建議。如需有關涉及 Salesforce 的資料層級整合資訊,請參閱我們的「資料整合決策指南」。

• **針對不需要要求同步回應的流程,使用以事件為導向的結構。**本指南概述的模式是針對資料的一致性、可擴展性和重複使用所設計,這有助於隨著您組織的應用程式環境發展將技術債務降至最低。(如需詳細資訊,請參閱 Well-Architected - 輸送量。)

• **如果 MuleSoft 或其他 Enterprise Service Bus (ESB) 解決方案是您現有的基礎,請盡可能使用它。**這些解決方案是針對支援以事件為導向的結構模式而打造,並具有強大的功能,可讓您在整個企業中重複使用整合。

• **將 Pub/Sub API 用於任何未來的發佈/訂閱模式,而非使用其他 API (包括串流 API) 建立您自己的事件處理常式。**現在 Pub/Sub API 已廣泛可用,請將其用於任何新的發佈/訂閱模式。計畫在可行時使用其他平台 API (例如串流 API 或自訂 Apex 服務) 將現有事件通訊移轉至 Pub/Sub API。

• **平台事件和變更資料取得 (CDC) 是發佈其他系統需要取用的記錄和欄位變更的偏好機制。**我們不建議針對新實作使用 PushTopic 和一般事件。Salesforce 會繼續支援目前功能內的 PushTopic 和一般事件,但不會計畫進一步投資此技術。

	Salesforce Platform 是一個全方位、 AI 驅動的平台,可將員工、自主 AI 工作人員、公司資料和應用程式整合到一個可靠的系統中,以增強生產力與客戶體驗。透過連接 Customer 360 應用程式、Data Cloud 和 Slack 來進行端對端自動化,以便建立「真正的企業」。
	MuleSoft 是 Salesforce 領先的整合平台,可讓組織在內部部署和雲端環境之間連線應用程式、資料和裝置。MuleSoft 是一個平台,可讓 IT 平台在系統之間解除鎖定資料、開發可調整整合和自動化架構,並快速建立不同的連線體驗。

針對需要近乎即時通知的情境、分配大量或複雜訊息的處理負載,以及整合如 IoT 和行動裝置等系統,這些情況都建議使用事件驅動結構 (EDA)。然而,EDA 不應針對需要立即同步的人類回應的流程進行實作,因為其設計用於非同步執行。如果來源資料變更的頻率太少,以至於簡單的模式 (例如批次處理) 足夠,則其也不適用。

以下是一些常見的案例,通常適合以事件為導向的結構:

大多數的大型組織擁有複雜的 IT 環境,其系統組合具有不同的功能。您的組織有可能或可能擁有不支援以事件為導向之整合的舊版系統。您可能也會在事件驅動的整合沒有意義的情況下使用個案,即使系統會支援這些個案 (例如,SFTP 檔案從第三方傳輸)。如果您回溯了一步,並查看整個組織的 IT 環境,您可能會使用混合的模式來支援不同的案例,就像其他結構解決方案一樣。當您決定使用以事件為導向的整合方法,請將其視為工具箱中的另一個工具。它可且應用於正確的案例中,但並非要對每個系統強制執行的方法。開發全方位整合策略可協助您判斷本指南中所述模式何時可能或可能不適當。

許多案例都需要以事件為導向的結構,在某些案例中,即使以事件為導向的結構並非最適合,它們仍會運作。但在某些情況下,無法使用以事件為導向的結構。以下是一些決策點問題,可協助您識別這些情況:

各種以事件為導向的結構模式。某些是一般用途模式,可套用在沒有事件驅動以外任何特殊需求的使用個案中;例如,請參閱 Well-Architected - Interoperability。其他模式適用於此處討論的特定使用個案,例如涉及大量資料的整合,或需要更長訊息保留的情境。

下表比較此文件中所列模式的屬性。當您需要識別指定使用個案的潛在模式時,請將其作為快速參考。

Salesforce 提供多種工具來協助您解決以事件為導向的使用個案。此表格包含可用工具的概觀概觀。

當重要記錄在核心應用程式內變更狀態時 (例如,訂單的狀態從「正在處理」移至「已出貨」),多個其他系統可能需要近乎即時的通知來執行其各自的工作。當這些變更量很高且訊息很複雜時,會產生特定業務需求,使傳統點對點整合變得繁重且難以維護。為每個相依應用程式建立脆弱且自訂的連線會導致技術負債,並阻礙組織快速擴展。需要強大的整合方法來管理這些頻繁的資料同步化,而無須將來源系統直接連接至每個耗用系統。

下圖說明一般發佈/訂閱模式,其中多個發行者和訂閱者透過 Event Bus 共用資料。此基礎模式是可在本指南其餘部分找到的更具體模式基礎。此模式的一些重要特性包括:

• 發行者與訂閱者之間沒有直接連線。發行者只需將訊息傳送至 Event Bus,便可將訊息廣播至想要聆聽訊息的任何其他系統。

• 相同的系統可以是發行者與訂閱者。

• 系統可以發佈或訂閱多種類型的事件。

• 如同本指南中所有的模式,發佈/訂閱模式屬於一般整合模式種類,稱為遠端程序叫用 (RPI) 或簡單「觸發忘記」。

當組織需要將立即更新傳送至大量用戶端應用程式 (例如推送通知或 SMS 訊息) 至行動裝置時,為每個單一收件者建立唯一傳輸的傳統程序會迅速變成可擴充性瓶頸。在此案例中,核心業務需求是將單一資訊 (例如帳戶警示或重要服務變更通知) 快速且高效能地散佈至多個端點應用程式。滿足此需求的簡化方法涉及透過單一路由訊息,這會作為所有耗用系統事件資訊的中心點。此方法可減少管理多個個別訊息複本的需求,藉此改善效能。

透過「下拉式」模式,訊息會透過單一訊息列傳送至一或多個目的地 (亦即聆聽用戶或訂閱者)。訂閱者會從其自己的唯一複本取用同一則訊息,而不是從其中的同一則訊息。(請注意,雖然這可改善效能,但也會使驗證特定訂閱者是否收到訊息變得更難。)

某些事件案例的特點為訊息量大幅流入,可能會壓倒同步化和轉換程序的容量,或處理和轉換事件資料所需的複雜多步驟邏輯。

某些範例包括:

• **季節性量高峰:**線上零售商在其產品的選擇「季節性」時,可能會遇到數量高峰。當大量客戶同時進行購買時,產生的事件數量可能暫時超過同步化和轉換流程的容量。請參閱 Well-Architected - 資料處理以取得詳細資訊。

• **個案或索賠管理:**以服務為基礎的公司在中斷期間,可能會遇到個案或索賠數量的激增。

• **複雜資料轉換:**需要複雜邏輯來轉換訊息的組織通常會擔心事件的產生速度比其轉換的速度快。

此模式可解決訊息產生速度超過可轉換的挑戰。其可確保可安全地處理大量訊息和必要的資料操作,將串流訊息平台整合到專屬元件中,並將訊息處理邏輯分段。

「傳送的訊息」模式可透過將訊息處理邏輯分段至多個元件來運作:

• 一個元件會處理訊息路由,決定必要轉換和最終目的地。

• 個別的元件集會處理訊息轉換的不同層級 (例如,欄位對應、物件關係等)。

• 最後一個元件會撰寫最後修改後的訊息。

某些產生者會產生連續的事件串流。常見範例為媒體串流,其中涉及自然發生為離散事件的使用者互動。多個系統必須同時回應相同的使用者行為,而不會封鎖核心串流體驗。

請考量音樂串流平台的事件。這些可能包括:

• 追蹤已啟動/已暫停/已略過事件

• 聆聽包含時間戳記的工作階段事件

• 播放清單建立/修改事件

• 社交共用事件

• 下載以供離線聆聽

在「串流」模式中,訂閱者會存取每個事件串流,並以接收的確切順序處理事件。每個訊息串流的唯一複本會傳送給每個訂閱者,讓您能夠傳送訂閱者特定的內容,並識別哪些訂閱者會收到哪些串流。

為了讓串流有意義,其所有事件及其相關聯的訊息都必須以正確的順序顯示。如果您在來自不同系統的串流中來源資料,則必須納入其他訂購邏輯作為設計流程的一部分。

查詢使用個案很普遍。範例包括:

• **低品質的網際網路連線:**Field Service 組織或其他組織,其中具有行動裝置的小組需要在品質不佳或間斷網際網路存取權的區域中工作,會受益於將這些裝置上應用程式連線至其中的排隊,並在恢復連線時取回任何相關訊息。

• **訊息緩衝:**當訊息量有時超過訂閱者的處理容量,且延遲增加不會產生額外的問題時,可能會有用於緩衝來儲存過多訊息並避免資料遺失。

• **運輸管理:**需要監視車隊的物流組織可以使用此模式,以近乎即時檢視每部車輛正在使用的路線,並確保司機的效率盡可能高。

• **IoT 裝置:**製造商經常使用產生快速資料串流的系統,而這些串流可能會對其他系統造成下游影響。此模式可用來識別在發生跨多個系統的災難性失敗之前,需要人類介入的事件序列。

生產人員會在「排隊」模式中,傳送訊息給排隊,這些排隊會保留訊息,直到訂閱者將訊息提取為止。大多數訊息排列會遵循先進先出 (FIFO) 順序,並在取出訊息之後刪除每則訊息。每個訂閱者都有獨一無二且需要額外的設定步驟,但仍可保證傳送並識別哪些訂閱者接收了哪些訊息。

由於「排隊」模式的非同步性質,因此在將訊息新增至排隊與該訊息提取之間可能會有較長的延遲。達號需要記憶體或儲存空間來保留其訊息,因此其無法無限成長,這表示如果在達號中累積足夠的訊息,則無限離線的訂閱者可能會造成失敗。如果訂閱者處理時間過長,則訊息緩衝可能會產生相同的效果,進而導致大量訊息堆積在他們的排隊中。若要減少這些風險,請針對所有訊息排列執行完整的儲存空間需求分析,並視需要設計流程,在未在設定的時間內或當訊息達到預先決定的容量時清除並停用訊息。

即使您完全相信以事件為導向的結構適合您的組織,您仍可能會從已經擁有大量點對點整合的環境開始。為專案獲得資金來一次取代所有整合可能很困難,甚至可能無法直接將以事件為導向的結構與一些舊版系統搭配使用。在這些案例中,您可以先轉換最關鍵業務的應用程式,然後在其在未來專案中更新或取代時轉換其他系統,以逐步移轉至較寬鬆的架構。此方法可讓您輕鬆將新應用程式新增至 Event Bus,並讓整體 IT 環境在隨著系統持續新增的時間保持可調整和彈性。

身為結構設計師,我們知道每個結構都有權衡。以事件為導向的結構也不例外。雖然充滿寬鬆連接系統的環境可高度調整和彈性,但還需要考量一些權衡因素:

• **整體整合策略:**無論您決定要使用的工具和模式為何,請務必從建立策略開始,以瞭解資料如何在組織的各個系統之間共用。此策略應包含您組織的資料目標、資料可共用的方式和使用模式,以及資料來源、目標、結構和擁有權與存取需求。

• **舊版系統的支援:**您的組織可能有舊版系統,只是不支援以事件為導向的結構模式。雖然可能會建立因應措施 (例如,使用透過訂閱事件,然後透過不同的資料傳輸方式將輸出傳送至目標系統作為逐步解說的流程),但您可能想要在此個案中考慮其他整合方法。

• **訊息的結構變更:**一旦發行者與訂閱者之間定義並同意初始訊息結構,可能會難以變更,特別是當訂閱者為外部使用者時。有數種方法可以解決此問題。您可以使用版本化端點,但請確保為每個版本定義並傳達明確的生命週期,以便您的開發人員不必同時維護太多版本。如果 Heroku 上的 Apache Kafka 屬於您的橫向,您也可以考慮使用結構描述登錄或類似工具,但請確保橫向中的其他系統也支援 (並使用)。

• **缺少發行者與訂閱者之間的可視性:**在大多數以事件為導向的結構模式中,發行者不會知道其訂閱者的狀態。因此,如果發行者在所有訂閱者離線時傳送重要訊息,則訊息可能不會傳送。您可以使用重新執行功能來解決此問題,或針對所有重要訊息新增在個別伺服器上執行的冗餘訂閱者。

• **效能瓶頸:**隨著以事件為導向的結構擴展,如果發生過多發行者嘗試同時傳訊太多訂閱者,則 Event Bus 可能會成為訊息傳送的瓶頸。您可以透過增加分配至 Event Bus 的記憶體和處理資源,或使用多個 Event Bus 並列處理不同類型的訊息來解決此問題。

實作以事件為導向的結構之前,請考量您是否真的需要先使用一個架構。上一節描述適用於每個事件驅動結構模式的常見業務案例。您也可以在 Well-Architected - Interoperability 中深入瞭解。檢閱實作以事件為導向的結構時要考量的挑戰,以判斷您考量的模式是否最適合您特定的使用個案。

請注意,雖然本指南涵蓋的大多數案例涉及整合,但以事件為導向的結構也可以用來透過使用平台事件在單一 Salesforce 組織內傳送訊息,例如。設計使用平台事件作為內部傳訊系統的程序時,請務必記住任何適用的事件分配限制。

事件驅動結構的反模式通常來自使用事件作為 Salesforce 組織內內部通訊的因應措施。常見的反模式包括:

• **從與相同事件物件相關聯的 Apex 觸發發出事件:**這會導致無限觸發迴圈。

• **在 DML 交易完成前,從 Apex 發佈事件:**如果交易失敗並回復,任何具有「立即發佈」發佈行為的已發佈事件都不會包含在回復行為中。

• **在流程中發佈事件以協調後續的自動化:**在多個自動化之間協調邏輯的最佳方法是使用 子流程或 Flow Orchestrator。

• **建立執行階段相依性:**若未採取適當的步驟去除執行階段相依性,請勿發佈事件以協助封裝之間通訊。

• **不必要的大型裝載:**提出要求時,最好在裝載中傳送及接收盡可能少量的資料。使用者的每個動作都可能產生多個要求,因此有效處理這些要求十分重要。傳送超過必要的資料會造成傳輸速度變慢且處理時間增加。

• **未選擇性處理應用程式事件:**當有多個元件正在聆聽應用程式事件時,開發人員應確保事件處理常式只會在實際需要且實用時執行。例如,在 Lightning 主控台中,未聚焦的索引標籤中包含的元件仍可聆聽,即使它們不可見。開發人員可以使用各種技術,例如使用背景公用程式項目作為唯一接聽者,或呼叫 getEnclosingTabId() 來判斷元件的此例項是否包含在焦點索引標籤內,以確保每個事件僅在預期的時間處理。

• 使用「平台事件」不正確發佈行為:「平台事件」有兩種發佈行為—「立即發佈」和「認可後發佈」。將即時平台事件用於使用個案 (例如「記錄」) 相當有用,無論交易是否成功與認可,您都會在其中發佈記錄事件。不過,對於即時平台事件,請特別小心使用「立即發佈」。事件可以在相同交易內由訂閱者耗用,並導致列鎖定或其他競爭狀況。

實作以事件為導向的結構時,成功的關鍵之一是設定事件本身設計方式的標準。細節會根據您組織的使用個案而有所不同,但以下是一些一般原則:

• **決定事件裝載的最佳結構。**較小的訊息大小會減少處理時間,但以大量訊息轟炸訂閱者可能會造成效能瓶頸。您可能需要迭代裝載大小與結構,以找到正確的平衡。MuleSoft 和類似的 ESB 工具能夠在與您的事件相關聯的訊息中設計自訂裝載,這可協助您視覺化資料結構,以改善訂閱者端的效能。(如需詳細資訊,請參閱 Well-Architected - API Management。)

• **考量您的程序端對端。**確定您未建立任何「無限迴圈」案例,這在首展整合後可能難以追蹤。範例為兩個系統在更新記錄時發佈事件,同時聆聽彼此的事件,這兩個系統在處理時會觸發其他已發佈事件。

  您可以透過將邏輯新增至兩個系統來修正此類型的反模式,以確保由於耗用事件而進行的變更不會導致發佈新的事件。您也應確保記錄所有事件、其相關聯的觸發,以及可能受影響的下游系統。在設計工作階段期間,請使用此文件作為參考,以協助盡早抓住無盡的迴圈和類似情況。(如需詳細資訊,請參閱 Well-Architected - 流程設計。)

• **在系統之間使用常見命名慣例。**一致的命名慣例是所有軟體開發 (包括以事件為導向的結構) 的最佳作法。花時間記錄事件名稱、結構、相關聯物件和錯誤處理流程的一組標準,以確保系統之間的一致性。(如需詳細資訊,請參閱 Well-Architected - 設計標準。)