EventBridge 簡介

近年來，隨著雲原生和 Serverless 概念的深入人心，事件驅動再一次成為了雲應用架構領域的熱門詞彙。在 2018 年，Gartner 評估報告將 Event-Driven Model 列為10大戰略技術趨勢之一，事件驅動架構（EDA）將成為未來微服務的主流。該報告同時做出了以下預言：

到 2022 年，事件通知的軟體模型將成為超過 60% 的新型數字化商業的解決方案；
到 2022 年，超過 50% 的商業組織將參與到事件驅動的數字化商業服務的生態系統當中；
同年 5 月，雲原生 CNCF 基金會託管了開源 CloudEvents 專案，該專案旨在用統一和規範的格式來描述事件，來加強不同的服務、平臺以及系統之間的互操作性，事件在雲原生大圖中的重要性不言而喻。

與此同時，在阿里雲上實踐事件驅動架構卻不是一件簡單的事情：

阿里雲的雲產品，從 IaaS 到 PaaS，每天都有數以億計的事件產生，但卻沒有一種簡單和統一的方式來觸達這些事件；

很多雲產品有自建的事件中心，但沒有采用統一的標準和規範來描述這些事件，使用者無法用同樣的方式來解釋這些事件；

雲上的的事件目前非常獨立，無法形成規模效應，很難挖掘出有用的業務價值，只有充分發揮資料的規模效應，建立起資料的血緣關係，我們才能更好的發掘出資料的價值；

目前事件應用的場景偏離線分析，因缺乏開箱即用的中心化事件處理能力，無法應用在線上業務的場景。

為了解決這些問題，阿里雲正式釋出了最新雲產品 EventBridge，一款無伺服器事件匯流排服務，其使命是作為雲事件的樞紐，以標準化的 CloudEvents 1.0 協議連線雲產品和雲應用，提供中心化的事件治理和驅動能力，幫助使用者輕鬆構建松耦合、分散式的事件驅動架構；另外，在阿里雲之外的雲市場上有海量垂直領域的 SaaS 服務，EventBridge 將以出色的跨產品、跨組織以及跨雲的整合與被整合能力，助力客戶打造一個完整的、事件驅動的、高效可控的上雲新介面。

EventBridge 核心能力

作為一款全新的雲產品，EventBridge 是完全面向雲原生設計和架構的，EventBridge 提供的核心能力分為以下幾類。

整合與被整合

整合能力和整合度是產品的關鍵點，EventBridge 將以低成本甚至零成本，低程式碼甚至0程式碼，跨組織和跨雲的方式去連線雲產品、雲應用以及SaaS應用。

整合雲產品

今天的阿里雲，有數百個成熟的雲產品，有數百萬應用的計算例項，它們每天會產生億級的雲事件，但這些事件目前處於失控的狀態，是一片尚未被挖掘的資料寶藏。EventBridge 將連線大部分阿里雲的雲產品，作為事件源或者事件目標，提高阿里雲事件的中心化治理能力，充分挖掘雲事件的業務價值；同時，透過一站式的雲產品連線服務，幫助使用者更好地上雲和用雲。

整合雲應用

使用者上雲的最終目的是充分撬動雲端計算帶來的技術紅利，所以上雲的過程不僅僅是 Rehost，還需要進行 Replatform 和 Refactor，EventBridge 提供豐富的整合能力，讓應用更好地連線和使用雲服務。目前使用者可以透過 EventBridge 官方的 HTTP 介面、多語言客戶端（Java、Golang、Python、C#、PHP）以及 CloudEvents 社群的開源客戶端輕鬆接入阿里雲的 EventBridge 生態。

整合第三方 SaaS

對於 SaaS，阿里雲堅持被整合的戰略，可以預計在阿里雲上會成長出一批又一批優秀的 SaaS 提供商，EventBridge 將為 SaaS 提供便捷的方式融入阿里雲生態體系，與阿里雲一方雲產品深度融合。

協調與驅動

Serverless 應用架構的最佳實踐便是事件驅動，無論是傳統的微服務還是函式計算，EventBridge 將極大地簡化事件驅動架構的研發成本，海量的函式以及微服務將以事件的形式被有序協調。

關於編排（Orchestration）和協調（Choreography），Gartner 報告中對比了兩種架構的區別，透過請求驅動來組合和編排微服務和函式的方式帶來了很多不必要的強耦合，而透過事件驅動的方式來協調微服務和函式，將是更徹底的解耦，提高程式的韌性，業務的開發也將變得更加敏捷和高效。

資料通道

EventBridge 另一個核心能力是為流式的資料承擔通道的責任，透過 CloudEvents 規範和 Schema 登錄檔（Coming Soon）來統一描述這些資料，並提供基礎的過濾和轉換的能力，在不同的資料倉儲之間、資料處理程式之間、資料分析和處理系統之間進行資料路由。

為此，EventBridge 即將上線 Connect 能力，透過大量的 Source 和 Sink Connector 將使用者的資料在雲上流動起來。

EventBridge 基本模型

EventBridge 產品包含幾個基本概念：事件、事件匯流排、事件源、事件規則以及事件目標。

如上圖所示，事件從事件源被投遞至事件匯流排，經過規則的過濾和轉換處理，最終被投遞給多種事件目標，完成事件的處理。

事件

事件，代表了事情的發生、條件和狀態的變化。在雲的時代，事件是無處不在的，雲的任何一個產品、一個應用、甚至一個資源都在時刻發生事件，它們稱為事件源。事件源來自不同的組織和環境，事件源對事件將被如何響應沒有任何預期，事件目標透過中心化的事件匯流排來訂閱事件，依賴事件具備的自描述能力，來低成本地理解和處理事件。

EventBridge 中的事件透過雲原生事件標準 CloudEvents 來描述，CloudEvents 是 EventBridge 生態系統中的一等公民。EventBridge 採取 CloudEvents 的主要原因為：

採取統一的雲原生事件標準，有助於統一表達來自不同事件源中的事件，提升事件驅動程式的互操作性。
標準化，使用者沒有廠商鎖定的擔憂，基於 CloudEvents 的事件驅動程式可以在不同雲之間隨意移植。
CloudEvents 具備非常簡單的結構，如下 JSON 文字為一個 CloudEvents 事件。

阿里雲 EventBridge 目前支援兩類事件：自定義事件和阿里雲服務事件。

阿里雲服務事件：具備預先定義好的 Schema，來自各個雲產品關於使用者資源狀態變更的事件，比如雲視訊會議事件，包括會議開始、結束、成員變更等會議事件。
自定義事件：使用者可以使用 CloudEvents 社群的開源 SDK、EventBridge 官方的多語言輕量級 SDK、EventBridge Connect、WebHook等（後兩種能力即將開放）方式投遞自定義事件至 EventBridge，豐富的事件源接入方式助力客戶快速打造事件驅動的 Serverless 應用程式。

事件匯流排

事件匯流排是一個抽象概念，是事件的載體，阿里雲 EventBridge 的事件匯流排具備使用者緯度的多租戶能力，每個匯流排有唯一的資源 ARN。事件傳送至事件匯流排，隨後被事件規則路由至事件目標。

如上圖所示，阿里雲的事件匯流排分為兩類：

預設事件匯流排：使用者開通 EventBridge 時自動建立 default 匯流排，所有接入的雲服務事件都將主動投遞至 default 上，對於使用者來說雲產品的事件是開箱即用的。
自定義事件匯流排：使用者自行建立，用來接受自定義的事件，是使用者研發事件驅動架構程式的必備資源。

規則

規則對事件匯流排中的事件進行過濾，過濾成功的事件經過一定的轉換路由到規則中指定的阿里雲目標服務或者HTTP閘道器。

EventBridge 中的規則有兩端，一端連線事件匯流排，一端連線事件目標，並且是一對多的關係，每個規則最多關聯 5 個事件目標。同時，規則中的過濾和轉換元件，為使用者提供了輕量級的事件過濾和轉換的能力。

規則中過濾能力由事件模式（Event Pattern）提供，當前支援的過濾模式包含：

指定值匹配
字首匹配
字尾匹配
除外匹配
數值匹配
陣列匹配
以及複雜的組合邏輯匹配

規則中的轉換用於將 CloudEvents 轉變事件目標接受的格式，EventBridge 提供了四種轉換器：

完整事件：不做轉換，直接投遞原生 CloudEvents。
部分事件：透過 JsonPath 語法從 CloudEvents 中提取部分內容投遞至事件目標。
常量：事件只起到觸發器的作用，投遞內容為常量。
模板轉換器：透過定義模板，靈活地渲染自定義的內容投遞至事件模板。

EventBridge 產品架構

EventBridge 作為一款全新的雲產品，全面採用了雲原生技術棧，如下圖所示，EventBridge 搭建在容器服務提供的 Kubernetes 叢集之上，設計了一整套基於 K8S 的 DevOps 研發體系，研發階段實踐 GitOps 提高交付和迭代效率，測試階段配備了大量的自動化測試，釋出階段有完善的灰度機制，運維階段依賴 K8S 的自愈能力大幅度降低運維成本，並透過 Prometheus ，SLS 等產品建立了雲原生的監控體系。

除此之外，EventBridge 依賴 RocketMQ 提供核心的事件儲存能力，RocketMQ 作為阿里自研的訊息中介軟體，經歷過多次雙11流量高峰的考驗和無數個阿里內部業務場景的驗證，為 EventBridge 提供了高 SLA 的，高效能的事件傳輸服務。

EventBridge 典型場景

在本章節，我們根據 EventBridge 當前以及具備的能力，列舉三個典型的案例。隨著 EventBridge 生態的豐富，未來可以挖掘更多的業務場景，我們後續也會出一系列的樣板間專案，方便使用者快速將事件驅動的方式契合大盤自己的業務場景中。

場景 1：360 度業務全景

隨著企業業務規模的擴大，業務的穩定性愈發重要，為了避免故障隨著場景的複雜化而頻繁發生，對應用建設 360 度全方位的可觀測和監控體系尤為重要。傳統的應用基於雲原生重構後，享受雲原生技術紅利的同時也為應用的穩定性治理帶來了更多的複雜性，最主要的就是變更難以控制：業務依賴了整套雲的基礎設施，IaaS 層物理資源、網路資源以及 PaaS 層雲服務，甚至依賴的上下游服務，時刻都在進行變更，使用者很難立馬感知到變更的發生以及相應的影響，而 95% 的故障都是由變更導致的。

為了解決這個問題，透過 EventBridge 打造 360 度業務全景圖，清晰地感知整個產品業務鏈路上，做了哪些變更，有哪些異常反應，這些異常反應是不是跟最近的變更有關聯，遇到特殊問題時，我們甚至可以透過自運維的方式，幫助產品更快的恢復，將影響面降低到最小。

而這些能力的擁有，離不開 EventBridge 整合多個雲產品事件的能力，也離不開 EventBridge 可以透過事件觸發多個雲產品響應的能力。事件作為一個資訊的重要載體，透過 EventBridge 優雅的協調各個雲產品進行有序工作。

場景 2：網頁截圖製作每日快報

場景 1 是一個比較複雜的案例，再來看一個可以快速上手的場景：使用 EventBridge 驅動函式計算幫我們進行網頁截圖，並透過郵箱傳送出去，製作每日快報。

首先，業務系統透過分析，計算出今日有價值的頭條新聞，並把新聞 URL 地址透過 Event，傳送給EventBridge；
EventBridge 接收到 Event 後，根據預配置的規則，開始觸發函式計算的網頁截圖程式進行工作；
函式計算接收到 Event 後，自動建立資源，並執行網頁截圖程式進行截圖，儲存到 OSS，同時通知 EventBridge 截圖完成，然後自動釋放資源；
EventBridge 接收到函式計算完成的 Event 後，根據預配置的規則，開始觸發郵箱服務，將網頁截圖以郵件的形式傳送給目標使用者；

從這個例子中，可以發現：Serverless 和 EventBridge，是雲原生時代一個非常強有力的組合。透過事件去驅動函式計算，讓業務按需排程資源，不僅可以預防突發流量帶來的穩定性風險，還可以最大程度的降低成本，按需付費。

場景 3：新零售智慧傢俱門店

EventBridge 未來可以觸達的場景有多大？讓我們看一個新零售智慧傢俱門店的場景：

倉庫的傢俱商品入庫事件、門店的顧客進店事件透過 EventBridge 實時流轉到線上分析系統，讓我們知道現在店內有哪些傢俱商品，進店顧客的傢俱偏好是什麼，並推送給商場門店的導購員或則廣告屏，幫助門店更好的下單轉化；
顧客線上電子支付後，訂單資訊傳送到 EventBridge，並觸發第三方物流公司進行送貨上門；
第三方物流公司，可以實時的將傢俱的位置資訊透過 EventBridge 推送給移動端APP，客戶可以透過 APP 很方便的實時瞭解到自己的傢俱到哪了，預估還需要多久送到家；
所有這些透過EventBridge流轉的線上業務事件資料，最終透過EventBridge流轉到離線分析系統，自動生成業務報表，供管理層做績效考核或則運營決策。

在這個場景中，EventBridge 起著關鍵的通道作用，無論是 IoT、線上業務、還是大資料場景，EventBridge 將事件資訊高效的流轉，推動業務目標達成。Event 既作為線上業務資料，又作為離線分析資料，這種方式，既降低了成本，同時也提高了效率。

EventBridge 未來規劃

作為雲上的事件樞紐，EventBridge 最核心的能力就是連線。所以，未來EventBridge會重點建設生態網路。無論是線上業務場景、IoT 場景、還是大資料場景，都能夠透過低程式碼甚至 0 程式碼的方式，整合到 EventBridge。如果你的應用部署在私有 IDC 機房，或則其他雲廠商環境，我們也都將提供安全可靠的整合方式。

當然，雲時代下這麼龐大的神經中樞系統，不是一日可以建成的，需要大家一起的努力。所以未來，EventBridge 同時會致力於開源社群建設，也希望志同道合的朋友一起加入進來，成為雲原生時代，Event-Driven Model 的第一批佈道師。

最IN的雲原生架構，阿里雲 Serverless 事件匯流排 EventBridge 重磅釋出