选择是否使用消息或事件
假设你正在规划分布式音乐共享应用程序的体系结构。 同时想要确保应用程序尽可能可靠且可缩放，并且打算使用 Azure 技术来构建强大的通信基础结构。
必须先了解应用程序组件交换的各个通信，才能选择正确的 Azure 技术。 可以为每个通信选择不同的 Azure 技术。
关于通信，首先要了解的是它是发送消息还是发送事件。 了解这一点有助于选择要使用的相应 Azure 服务。
Azure 中的通信策略 (API)
什么是消息？
在分布式应用程序的术语中，消息具有以下特征：
- 消息包含由一个组件生成并由另一个组件使用的原始数据。
- 消息本身就包含该数据，而不仅仅是对该数据的引用。
- 发送组件期望目标组件以特定方式处理消息内容。 整个系统的完整性可能取决于执行特定作业的发送方和接收方。
例如，假设一位用户使用移动音乐共享应用上传新歌曲。 该移动应用必须将该歌曲发送到在 Azure 中运行的 Web API。 必须发送歌曲媒体文件本身，而不仅仅是指示已添加新歌曲的警报。 该移动应用预期 Web API 将新歌曲存储在数据库中，并使其可供其他用户使用。 这是一个消息示例。
什么是事件？
相比消息而言，事件并不是很重要，最常用于广播通信。 发送事件的组件称为“发布者”，接收方则称为“订阅者”。
对于事件，接收组件会决定他们感兴趣的通信，并订阅这些事件。 订阅由 Azure 事件网格或 Azure 事件中心等中介管理。 当发布服务器发送事件时，中介会将该事件路由到相关的订阅者。 此模式被称为“发布-订阅体系结构”。它并不是处理事件的唯一方法，但却是最常见的方法。
事件具有以下特征：
- 事件是一个轻量通知，表明发生了某些事情。
- 可以将事件发送到多个接收方或根本不发送到任何接收方。
- 事件通常旨在为每个发布者“扇出”或提供大量订阅者。
- 事件发布者对接收组件所采取的操作没有任何期望。
- 某些事件是离散单元，与其他事件无关。
- 某些事件是相关和有序系列的一部分。
例如，假设已完成音乐文件上传并且已将新歌曲添加到数据库中。 为了通知用户存在新文件，Web API 必须通知 Web 前端和移动应用用户存在新文件。 用户可以选择是否收听新歌，因此初始通知不包括音乐文件，而只通知用户该歌曲存在。 发送方并不期望事件接收方执行任何特别的操作来响应此事件。
这是一个离散事件示例。
如何选择消息或事件
单个应用程序可能会将事件用于某些目的，而将消息用于其他目的。 在选择之前，必须分析应用程序的系结构及其所有用例，以便确定其组件相互通信的所有不同目的。
事件更有可能用于广播，并且通常是临时性的。 这表示如果当前未订阅任何事件，则通信可能不会由任何接收方处理。 如果分布式应用程序要求保证通信得到处理，则更有可能使用消息。
对于每个通信，请考虑以下问题：发送组件是否期望目标组件以特定方式处理通信？
如果答案是肯定的，请选择使用消息。 如果答案是否定的，则可以使用事件。
了解组件通信所需的方式将有助于选择组件的通信方式。 首先来使用消息。