EventBridge 最佳實踐場景三:基於 EventBridge 設計零售業務中臺

01。 背景介紹

隨著資訊化的不斷髮展,當前不少零售企業都擁有不少內部系統來實現企業資訊化,例如 使用ERP、CRM 等業務系統來管理商品、使用者等資訊,使用 OA、財務等內部系統完成服務支援。然而,多項系統彼此閉環,難以統一管理,這些問題直接促進了中臺的出現。

中臺服務最大的價值也在於此,它提供了一個統一的平臺接收不同事件,實現企業內部資訊共享,並將事件轉發給對應的下游服務進行消費處理,從而把更多的系統連線在一起。

當中臺化成為越來越多傳統零售企業的變革方向,如何設計和開發中臺架構成了不少企業面臨的新問題。不同系統之間的資訊結構千差萬別,設計一套統一的規範完成事件接入與處理,往往是一個龐大的工作量。EventBridge 的出現,則為這個問題提供了一個完美的解決方案。

作為一款安全、穩定、高效的無伺服器事件管理平臺,EventBridge 事件匯流排可以接收來自應用程式、軟體即服務(SaaS)和騰訊雲服務的實時事件及相關資料流,透過整合訊息推送和 SCF 雲函式投遞目標,實現事件快速分發與實時消費,簡化事件驅動中臺架構的設計和研發成本。

02。 架構設計

如圖,以零售中臺為例,EventBridge 提供了統一的事件投遞規範,業務方產生的不同型別事件(如使用者下單、商品入庫、訂單更新等),透過 EB API 以相同規範進行投遞,由 EB 進行事件的過濾、提取後,根據配置的不同路由規則,將對應事件投遞給相應的處理目標,完成事件的自動化處理。在該場景下,EventBridge 完成了業務中臺的基礎能力,企業也可以基於 EB 提供的介面規範以及路由原則,將 EB 作為底層架構,完成更復雜的業務中臺搭建,從而簡化開發成本。

EventBridge 最佳實踐場景三:基於 EventBridge 設計零售業務中臺

03。 方案優勢

統一事件規範:為複雜多樣的業務系統提供統一標準的事件規範,保證事件一致性,方便後續處理。

簡化開發流程:利用 EB 自帶規則匹配與處理功能,以配置化的方式來進行不同來源事件的分發處理,降低開發門檻,提升構建效率。

海量資料實時處理:EB 作為為流式的資料承擔通道,可以在不同的資料倉庫之間、資料處理程式之間、資料分析和處理系統之間進行資料路由,實現海量業務事件的實時處理。

豐富拓展能力:經過 EB 處理的事件保證了格式規範的統一,後端可以直接推送給不同的業務系統進行消費和業務邏輯處理;目前已完成和雲函式 SCF 的整合,可基於函式透過任意一種程式語言開發資料處理邏輯,連線不同的系統與不同服務。

04。 基本步驟

如果想完成上述架構的搭建,具體的部署流程是怎樣的呢?接下來將為大家進行具體的步驟介紹,可以瞭解如何透過 EventBridge,快速完成一個基礎中臺架構的搭建:

步驟一:繫結事件源

EventBridge 目前支援三類事件源的投遞:

雲服務事件源:雲服務產品產生的事件,如監控告警事件、雲上操作審計事件等,該類事件預設投遞至雲服務事件集,由業務方主動投遞,使用者不可修改或關閉,可以在「事件匯流排控制檯」——「雲服務事件集」詳情頁面檢視目前支援的所有云服務事件。

SaaS 事件源:基於鵲橋 iPaaS 實現,目前鵲橋 iPaaS 企業應用平臺已完成與 Eventbridge 事件匯流排的對接,鵲橋 iPaaS 支援的 50+ SaaS 應用均可實現到 EB 的投遞,想了解更多可以掃碼(文末)入群交流。

自定義事件源:除了預設投遞的事件外,EB 還支援自定義業務事件投遞,您可以透過 Ckafka、TDMQ 等訊息佇列產品投遞,API 閘道器 URL 回撥,或者直接呼叫 API 介面等方式,自定義投遞由業務方產生的事件資訊。

對於零售中臺架構,業務平臺產生的事件為自定義事件,可透過呼叫介面或回撥的方式,以統一規範投遞給 EventBridge。

步驟二:配置路由規則

如何對收集到的不同業務來源事件進行分類處理,是中臺系統需要關注的另一個問題,EventBridge 的規則過濾與篩選能力可以有效解決。基於 EB 標準事件格式,開發者可以自定義不同的欄位匹配規則,來確定不同的事件需要被哪一個規則過濾,並進行簡單的事件分析轉換,實現海量資料分類高效處理。

EventBridge 最佳實踐場景三:基於 EventBridge 設計零售業務中臺

步驟三:繫結推送目標

完成規則的配置後,業務方可以根據實際場景需要,將不同事件推送給指定的下游平臺完成消費,實現相應業務邏輯,完成基本中臺架構的搭建。

識別下方 二維碼,進入「事件匯流排」交流群

EventBridge 最佳實踐場景三:基於 EventBridge 設計零售業務中臺