前言
本篇文章主要介紹基於阿里雲 EventBridge 的消息集成能力，結合目前消息產品的需求熱點，從能力範圍到場景實戰，對 EventBridge 的消息集成解決方案進行了概要的介紹。
01 從消息現狀談起
消息隊列作爲應用解耦，流量削峯填谷的有效工具，早已被開發者廣泛應用於各類分佈式服務中。隨着業務的不斷髮展迭代，越來越多的服務面臨着穩定性和可維護方面的挑戰，對消息隊列的需求也不再侷限於普通的訂閱-消費，這裏列舉 3 個場景的能力需求：
消息路由能力
這裏主要的需求場景是數據同步和異地災備。對於大多數消息隊列用戶而言，消息隊列中的業務數據一般由一類服務來消費和處理，當用戶有多個應用，且需要一個全局視野來彙總分析這些不同應用的數據時，消息路由就成了一個避不開的能力需求。同樣，出於數據災備的考慮，雲上大用戶通常也有在不同 region 同步消息數據的需求。
但在雲上實現消息路由可能並不是一件容易的事情。衆所周知，雲上個 region 之間網絡是嚴格隔離的，用戶想要實現數據的跨 region 傳輸，要麼使用 CEN 等網絡打通方案，要麼使用公網進行數據傳輸。前者需要業務在設立之初就有完備的網絡規劃，同時 CEN 的費用成本也是一筆不小的開銷；後者則需要考慮公網帶寬成本，和將數據暴露在公網所面臨的安全問題。
消息加工能力
設想這樣一個場景，電商平臺上，用戶的訂單信息是由 RocketMQ 來負責承載的，下游的支付、庫存、營銷部門都需要消費訂單信息，由於歷史和技術棧原因，這幾個部門使用的消息產品類型各不相同，分別是 RocketMQ、RabbitMQ 和 Kafka，而且這幾個部門所需要的並不是全量的原始消息，而是部分自己感興趣的。同時，自身的接口也對數據 schema 做出了一定的要求，並不期望原始消息投遞過來。
此時，單純的消息路由似乎也不能滿足需求。如果這項任務交給一款產品來處理，那麼這款產品需要滿足 2 點能力，第一就是將消息路由至其他種類消息產品的能力，另外一點就是必須具備數據的過濾加工能力。
生態擴展能力
傳統消息用戶，其消息的生命週期僅在自身業務的發送與消費階段。但在萬物上雲的今天，如果可以利用種類繁多，功能強大的各類雲產品來豐富消息的上下游，則將極大地發掘消息數據的潛在價值。例如用戶可能需要將 SLS 的日誌數據導入到消息隊列，以實現離線的數據加工能力；又或者可能需要將消息隊列中的數據用於觸發函數計算，以實現整個應用的 Serverless 化。
但現狀是，用戶如果自身去實現各個生態產品的對接，則面臨着開發工作量大，後續維護繁瑣的問題。最理想的方式是有一款開箱即用的工具，能夠對接足夠多的生態，而且本身使用也儘量簡單。
那麼是否有一款雲產品可以解決以上問題，幫助消息用戶實現便捷、可靠的消息集成能力呢？這裏就需要介紹本期的主角：阿里雲事件總線 EventBridge。
02 事件總線與消息集成
事件總線 EventBridge 是阿里雲提供的一款無服務器事件總線服務，支持阿里雲服務、自定義應用、SaaS 應用以標準化、中心化的方式接入，並能夠以標準化的 CloudEvents 1.0 協議在這些應用之間路由事件。
EventBridge 的核心能力可以歸納爲 3 點：統一事件服務、數據管道與開放與集成。
- 統一事件服務
在 EventBridge 出現之前，各個雲產品的事件相互獨立，用戶無法在一個地方地方完成對全部雲產品事件的收集和處理。EventBridge 的出現打破了這一局面，其收納了雲上的絕大多數雲產品事件，並在用戶側提供統一、體系的展示交互，讓雲上用戶可以更加系統的梳理、處理雲產品事件。
- 數據管道
EventBridge 並不簡簡單單僅覆蓋雲上事件，也提供數據管道的能力，實現數據的聯通交互。例如用戶可以使用 EventBridge 創建消息路由任務，將消息隊列中的數據導入到其他消息隊列，也可以創建任務將 SLS 中的日誌數據導入到消息隊列中來。目前 EventBridge 在源端和目標端均有豐富的產品種類支持。
- 開放與集成
EventBridge 開放了多種語言的 SDK，方便不同技術棧的開發者可以快速方便的使用 EventBridge。同時 EventBridge 也兼容了雲上標準 Cloudevents 的 sdk，即用戶使用業界開源 sdk 也可以方便的將事件投遞至 EventBridge。在事件 schema 定義上，EventBridge 採用了目前雲上事件的事實標準 cloudevents 1.0，保證了使用其他事件服務的客戶可以無縫遷移到阿里雲 EventBridge，其在阿里雲 EventBridge 上的事件也可以快速接入到其他主流 EDA 引擎，避免了廠商鎖定的情況。
針對第一部分談及的消息用戶面臨的問題，EventBridge 在消息集成領域提供了完整的解決方案，具體包括消息流轉（也稱爲消息路由）能力解決方案，消息處理能力解決方案與生態支持能力解決方案。
消息流轉解決方案
目前 EventBridge 已經支持了雲上大部分消息產品的接入，如 RocketMQ、RabbitMQ、Kafka、MNS 和 MQTT。使用這些消息產品的用戶，可以在對應消息產品的控制檯，消息流入流出頁面，或者是 EventBridge 的控制檯來創建對應的路由任務。
針對部分雲上用戶的需求，EventBridge 還支持跨 region 和跨賬號的消息路由。
針對跨 region 場景，當用戶需要創建北京到上海的消息路由時，在消息隊列控制檯消息流入流出頁面，選擇好對應的源實例信息和目標實例信息，一鍵創建啓動即可。
當用戶有跨賬號消息路由的需求（例如一家公司不同部門各自擁有獨立賬號，需要對各部門進行數據彙總的場景）時，使用 EventBridge 的事件總線可以完成不同賬號間數據的同步。具體詳細創建任務步驟可以參考 EventBridge 的官方文檔。
當用戶自身的消息源不是雲上產品時，目前 EventBridge 也提供了多種便捷的方式幫助用戶快速對接。如果用戶是在雲上自建的消息服務，如自建 RocketMQ，EventBridge 已經支持用戶通過簡單的配置快速將消息數據接入進來。如果用戶服務是部署在自建機房，使用的消息產品並非雲上已支持的產品，這個時候用戶也可以使用 EventBridge 提供的 sdk 主動將事件投遞上來，進而寫入到雲上各類豐富的下游雲產品，此類場景適合遷移上雲客戶。
消息處理解決方案
EventBridge 目前提供了豐富的事件提取和加工能力，用戶可以配置多種多樣的過濾與加工規則來滿足其業務需要。
舉個例子，用戶的事件有一個字段是訂單類型，內容有在線訂單和線下訂單兩類。用戶期望過濾訂單類型爲在線訂單的數據，投遞到處理在線業務的函數計算服務。這裏就可以在過濾規則中，參考指定值匹配，設置過濾規則中對應字段的值爲在線訂單。
除了指定值匹配，EventBridge 還支持前綴匹配、後綴匹配、除外匹配、數值匹配、數組匹配、複雜組合匹配等邏輯，滿足客戶絕大部分場景訴求。
有時用戶並不期望原樣的事件內容傳遞至目標端，而是加工成一定格式後再進行投遞，對此 EventBridge 也提供了事件轉換能力。目前支持的轉換器類型包括完整事件、部分事件、常量、模板、和函數計算轉換器。這些轉換器分工各有差異，搭配使用可以幫助用戶從事件體中提取出部分有價值字段，並按照要求拼接成目標端需要的數據格式。
消息生態解決方案
針對消息生態閉環的問題，EventBridge 的介入可以有效地擴充其上下游生態豐富度。
在消息流入側，EventBridge 支持消息類產品如 MNS、Kafka，數據庫類產品如 DTS、雲上管控、報警事件以及自定義事件的接入，使用戶可以便捷地獲取各類事件數據。
在消息流出側，EventBridge 支持計算類產品如 FC、SAE，數據庫類產品 RDS、通知類產品如釘釘、微信，通用類 API 如 http target 以及第三方 Saas 應用的觸發。消息產品的用戶通過簡單的配置就可以將消息導入到下游服務以產生業務價值。
03 場景與實戰
下面，我們列舉幾個場景並看下在消息產品控制檯上創建對應任務的步驟。
消息路由場景
第一個場景就是跨可用區消息路由場景，用戶如果有災備或者數據彙總的需求時，可能會面臨此問題。
如圖所示，用戶的業務部署在杭州、北京、青島 3 個 region。每個 region 都獨立處理本 region 的業務數據。但爲了搭建一個全局範圍的數據大盤服務，需要用戶彙總各個 region 的消息產品數據。
在這裏，用戶可以使用 EventBridge 的消息集成能力，分別創建杭州到北京和青島到北京的消息路由任務，再使用一個獨立的消費組去消費這些消息，即可完成跨 region 的消息數據彙總。
但有一點需要注意，在異地容災場景下，用戶需要配置雙向路由時，一定要配置合適的過濾規則以避免數據成環。
現在我們看下創建此跨 region 消息路由任務的步驟。由於這些服務是由 EventBridge 來提供的，所以需要用戶提前開通 EventBridge 服務，並在概覽頁授予 EventBridge 訪問相關雲產品服務的權限
這裏以創建一個北京到上海的 RocketMQ 消息路由任務爲例，首先登陸 RocketMQ 控制檯。
- 在控制檯左側頁面，選擇消息流出，點擊創建任務。
- 在創建任務欄中，流出類型選擇消息隊列 RocketMQ。
- 隨後在彈出的任務配置下拉參數中，源端的地域選擇爲北京，RocketMQ 實例信息按照實際情況填寫。
4.在目標端，選擇流入的上海 RocketMQ 實例，填入相關信息。
5.消息過濾和消息轉換按照需要填寫，點擊確定。
6.等待 1-2 分鐘，就可以看到消息路由任務已經處於運行中狀態，這表明消息路由任務已經成功創建並運行。
離線加工場景
第二個場景是一個消息離線數據分析的場景。
用戶除了對 MQ 中的消息進行即時業務消費，也需要將其導入到 SLS 中，以用作數據分析和報警配置。同時用戶還對寫入到 SLS 的內容格式有一定要求。
這裏用戶可以在消息流入流出頁面創建一個任務，將數據經由 EventBridge 導入到 SLS。在配置任務的過程中，按照圖中示例的變量和模板配置，就可以將原始數據內容中的 name 和 state 字段提取出來，按照需求生成新的內容格式。
還是以 RocketMQ 舉例，在 RocketMQ 控制檯消息流出頁面，點擊創建任務。
- 在流出類型中選擇日誌服務 SLS。
- 在下方的任務參數配置中，在源端選擇對應的 RocketMQ 實例信息，在目標端選擇對應的 SLS project 和 logStore。
3.在日誌內容格式部分，按照圖中提示的變量和模板配置，將對應內容填入，點擊確定。
4.等待 1-2 分鐘，就可以看到消息寫入 SLS 的任務已經處於運行中狀態，這表明任務已經成功創建並運行。
以上就是阿里雲 EventBridge 的消息集成能力的介紹。後續 EventBridge 還會加大對消息領域能力的支持，幫助用戶低成本的實現消息數據價值。感興趣的朋友可以關注 EventBridge 官網與官方文檔，第一時間獲取最新產品消息。
作者：昶風
點擊立即免費試用雲產品 開啓雲上實踐之旅！
本文爲阿里雲原創內容，未經允許不得轉載。