Azure提供了多个服务，用于在整个解决方案中传递事件和消息。 每个服务针对不同的方案，从被动事件路由到高吞吐量流式处理到企业级事务消息传送。
本文比较以下服务：
选择候选服务
本部分可帮助你根据需要选择最可能的服务。
使用下表快速缩小适合方案的服务范围：
| 标准 | 事件网格 | 事件中心 | 服务总线 |
|---|---|---|---|
| 主要用途 | 反应式事件路由 | 大数据流式处理和引入 | 企业事务性消息传送 |
| 数据模型 | 事件（离散通知） | 事件流（时序序列） | 消息（高价值载荷） |
| 交付保证 | 至少一次 | 至少一次 | 至少一次（可选排序，恰好一次与会话一次） |
| 何时使用 | 响应状态更改、无服务器体系结构 | 遥测、分布式数据流式处理、实时分析 | 订单处理、财务交易、工作流 |
本节的结果可作为供进一步考虑的起点。 使用以下部分对服务执行详细评估。
Azure 消息传递服务中的事件与消息之比较
传递事件的服务与传递消息的服务Azure服务之间有着重要的区别。
事件：条件或状态更改的轻型通知。 发布者对事件的处理方式没有期望。 事件可以是离散的（报告可操作的状态更改）或时间顺序序列的一部分（报告可分析的条件）。 离散事件非常适合于需要缩放的无服务器解决方案。
消息：要在其他位置使用或存储的服务生成的原始数据。 消息包含触发消息管道的数据。 发布者和使用者之间存在协定。 例如，发布者发送包含原始数据的消息，并期望使用者从该数据创建一个文件，并在完成工作时发送响应。
可伸缩性和吞吐量
下表比较了Azure 事件网格、Azure 事件中心和Azure 服务总线如何处理可伸缩性和吞吐量。
| 标准 | 事件网格 | 事件中心 | 服务总线 |
|---|---|---|---|
| Throughput | 可动态扩展的无服务器 | 每秒数百万个事件 | 可靠的异步传送 |
| 延迟模型 | 近实时事件传递 | 低延迟流媒体 | 使用可选的长轮询中转站 |
| 缩放模型 | 自动 （无服务器） | 吞吐量单位/处理单位 | 消息传送单元 （高级） |
消息传送功能
下表比较了Azure 事件网格、Azure 事件中心和Azure 服务总线的消息传送功能。
| 标准 | 事件网格 | 事件中心 | 服务总线 |
|---|---|---|---|
| 协议 | MQTT、HTTP | AMQP、Kafka、HTTP | AMQP、HTTP |
| Pub/Sub | 是（发布-订阅） | 是（使用者组） | 是（主题和订阅） |
| 排序 | 无保证 | 每个分区 | FIFO （会话） |
| 交易 | No | No | 是的 |
| 重复检测 | No | No | 是的 |
| 死信 | 是的 | No | 是的 |
| 批处理 | 是的 | 是（事件批次） | 是（会话） |
| 捕获/重播 | No | 是（事件中心捕获功能） | No |
集成和部署
下表比较了Azure 事件网格、Azure 事件中心和Azure 服务总线的集成和部署选项。
| 标准 | 事件网格 | 事件中心 | 服务总线 |
|---|---|---|---|
| Azure服务集成 | 与Azure服务和第三方服务进行深度集成 | 流处理基础结构和分析服务 | 企业应用程序、混合云、本地连接 |
| 版本 | Azure 事件网格（PaaS），通过 Azure Arc 在 Kubernetes 上运行的事件网格 | 标准、高级、专用 | 基本、标准、高级 |
将事件网格、事件中心和服务总线一起使用
在某些情况下，可同时使用多种服务满足不同的角色。 例如，电子商务网站可以使用 服务总线 处理订单，使用 Event Hubs 捕获网站遥测数据，并使用 Event Grid 响应诸如商品已发货之类的事件。
在其他情况下，可将它们链接在一起以形成事件和数据管道。 使用事件网格可响应其他服务中的事件。 有关使用事件网格与事件中心将数据迁移到 Azure Synapse Analytics 的示例，请参阅将大数据流式传输到 Azure Synapse Analytics。 下图显示流式处理数据的工作流。
