Azure 提供多項服務，用於在解決方案中傳遞事件與訊息。 每種服務針對不同的情境，從反應式事件路由、高吞吐量串流到企業級交易訊息傳遞皆有涵蓋。
本文比較以下服務：
選擇可選服務
本節可協助您選擇最有可能滿足您需求的服務。
請參考下表快速縮小適合您服務範圍的範圍：
| 準則 | 事件方格 | 事件中樞 | 服務匯流排 |
|---|---|---|---|
| 主要用途 | 反應式事件路由 | 大數據串流與攝取 | 企業交易訊息 |
| 數據模型 | 事件（離散通知） | 事件串流（時間順序系列） | 訊息（高價值承載資料） |
| 交付保證 | 至少一次 | 至少一次 | 至少一次（可選擇訂購，且每次都會有一次） |
| 使用時機 | 回應狀態變更，無伺服器架構 | 遙測、分散式資料串流、即時分析 | 訂單處理、財務交易、工作流程 |
本節結果為思考的起點。 請使用以下章節進行詳細的服務評估。
Azure 訊息服務中的事件與訊息
Azure 服務提供事件與傳遞訊息服務之間有重要區別。
事件：輕量級的狀況或狀態變更通知。 出版商對活動的處理方式沒有期待。 事件可以是離散的（報告可執行的狀態變化）或時間順序序列的一部分（報告可分析的狀況）。 離散事件非常適合需要調整的無伺服器解決方案。
訊息：服務產生的原始資料，供其他地方消費或儲存。 訊息包含觸發訊息管線的資料。 出版商與消費者之間存在合約。 例如，發布者會發送包含原始資料的訊息，期望消費者從這些資料建立檔案，並在工作完成後回應。
可擴展性與吞吐量
以下表格比較了 Azure 事件方格、Azure 事件中樞 與 Azure 服務匯流排 如何處理可擴展性與吞吐量。
| 準則 | 事件方格 | 事件中樞 | 服務匯流排 |
|---|---|---|---|
| Throughput | 動態可擴展、無伺服器 | 每秒數百萬事件 | 可靠的非同步傳送 |
| 延遲模型 | 近即時事件傳遞 | 低延遲串流 | 透過中介機制，並可選擇使用長輪詢 |
| 縮放模型 | 自動（無伺服器） | 吞吐量單元 / 處理單元 | 訊息單位（進階） |
訊息功能
下表比較了 Azure 事件方格、Azure 事件中樞 和 Azure 服務匯流排 的訊息功能。
| 準則 | 事件方格 | 事件中樞 | 服務匯流排 |
|---|---|---|---|
| 通訊協定 | MQTT、HTTP | AMQP、Kafka、HTTP | AMQP、HTTP |
| 發布/訂閱 | 是的（發佈-訂閱） | 是的（消費者團體） | 是的（主題與訂閱） |
| 排序 | 沒有保證 | 每個分割區 | FIFO（工作階段） |
| 交易 | No | No | Yes |
| 重複資料偵測 | No | No | Yes |
| 死字母 | Yes | No | Yes |
| 批處理 | Yes | 是（事件批次） | 是的（場次） |
| 捕獲/重播 | No | 是（事件中樞擷取） | No |
整合與部署
以下表格比較了 Azure 事件方格、Azure 事件中樞 和 Azure 服務匯流排 的整合與部署選項。
| 準則 | 事件方格 | 事件中樞 | 服務匯流排 |
|---|---|---|---|
| Azure service integration | 深度整合 Azure 服務及第三方服務 | 串流處理基礎設施與分析服務 | 企業應用、混合雲、本地連接 |
| 版本 | Azure 事件方格（PaaS），透過 Azure Arc 在 Kubernetes 上執行的 Event Grid | 標準、高級、專用 | 基本、標準、進階 |
同時使用 Event Grid、Event Hubs 和 服務匯流排
在某些情況下，您可以同時使用這些服務以滿足不同角色。 例如，電子商務網站可以使用 服務匯流排 處理訂單，Event Hub 捕捉網站遙測，Event Grid 則回應事件，例如商品出貨。
在其他情況，也可將各種服務連結在一起以形成事件和資料管線。 可以使用 Event Grid 來回應其他服務中的事件。 如需搭配事件中樞使用事件方格將數據遷移至 Azure Synapse Analytics 的範例，請參閱將 巨量數據串流至 Azure Synapse Analytics。 下圖顯示串流資料的工作流程。
