选择消息传送平台
有许多的通信平台可帮助提高分布式应用程序的可靠性，包括 Microsoft Azure 中的一些应用程序。 每个平台都是一种用于不同用途的工具。 必须针对应用程序中的每个要求选择正确的工具。 查看 Azure 服务总线中的选项。
建议的 Contoso Bicycles 订购和跟踪应用程序的分布式体系结构需要多个组件，包括网站、数据存储和后端服务。 你可以通过多种不同的方式将应用程序的组件绑定在一起，单个应用程序可以利用多种技术。
你需要确定新的 Contoso Bicycles 应用程序中要使用哪些技术。 第一步是评估多个部件之间存在通信的每个位置。 有些组件必须及时运行，这样才能使应用程序执行其工作。 尽管有些组件可能很重要，但却没有时效性。 最后，有一些其他的组件（例如移动应用通知）则更具可选性。
在消息和事件之间做出决定
消息和事件都属于数据报：从一个组件发送到另一个组件的数据包。 两者的差别在乍看之下有点细微，但这些差异可对你如何架构应用程序产生重大影响。
消息
在分布式应用程序的术语中，消息的鲜明特征是应用程序的总体完整性可能依赖于所收到的消息。 可将发送消息的机制视为一个向其他组件传递工作流指令的组件。 整个工作流可能是一个至关重要的业务流程，而消息就相当于将组件糅合在一起的研钵。
消息通常包含实际数据，而不只是包含对数据的引用（例如 ID 或 URL）。 与发送引用相比，将数据作为数据报的一部分发送会更可靠一些。 消息传递体系结构可保证消息传递，并且由于不需要执行额外的查找，因此消息会得到可靠的处理。 但是，发送应用程序需要确切地知道要包含哪些数据以避免发送过多的数据，这将导致接收组件执行不必要的工作。 在这种意义上，消息发送方和接收方通常由一个严格的数据协定耦合在一起。
在 Contoso Bicycles 的新体系结构中，下单时，公司可能会使用消息。 Web 前端或移动应用会将消息发送到后端处理组件。 在后端中，将执行诸如显示离客户最近的店铺路线以及收取信用卡费用等步骤。
事件
事件会触发发生了某事的通知。 事件比消息“更精简”，最常用于广播通信。
事件具有以下特征：
- 可以将事件发送到多个接收方或根本不发送到任何接收方。
- 事件通常旨在为每个发布者“扇出”或提供大量订阅者。
- 事件发布服务器对接收组件所采取的操作没有任何期望。
自行车零件连锁店可能会使用事件来通知用户状态的更改。 对于完全无服务器解决方案中，状态更改事件可以被依次发送到 Azure 事件网格、Azure Functions 和 Azure 通知中心。
事件与消息之间存在本质的差别，因为通信平台通常设计为只能处理其中之一。 服务总线可以处理消息。 如果要发送事件，可能会选择事件网格。
尽管 Azure 还提供了 Azure 事件中心，但事件中心往往用于处理特定类型、用于分析的高流量通信流。 例如，如果你在制造仓库中安装了联网传感器，则可以结合使用 Azure 流分析和事件中心来观察可能指示意外火灾或组件损耗的温度变化模式。
服务总线主题和队列
Azure 服务总线可通过两种不同的方式交换消息：队列和主题。
什么是队列？
服务总线队列是消息的简单临时存储位置。 发送方组件将消息添加到队列。 目标组件在队列的前面提取消息。 在一般情况下，每条消息仅由一个接收方接收。
队列将源组件和目标组件相分离，避免目标组件处理过高的需求。
在高峰期，消息的传入速度可能会超过目标组件进行处理的速度。 由于源组件不直接连接到目标，因此源不会受影响，并且队列将增大。 目标组件将从队列中删除消息，因为它们可以处理消息。 当需求下降时，目标组件可以跟上发送速度，因此队列会缩短。
队列响应高需求，而无需将资源添加到系统。 但是，对于需要快速处理的消息，可通过创建更多目标组件实例来让它们分担负载。 每条消息只由一个实例处理。 这是缩放整个应用程序的有效方法，只需将资源添加到真正需要它们的组件。
什么是主题？
服务总线主题和队列相似，但主题可以具有多个订阅。 这意味着多个目标组件可订阅一个特定主题，以便将每条消息发送到多个接收方。 订阅还可以筛选主题中的消息，以便只接收相关的消息。 与队列一样，订阅提供相同的解耦式通信，并且以相同的方式响应高需求。 若要将每条消息传送到多个目标组件，请使用主题。
注意
基本定价层中不支持主题。
服务总线队列和存储队列
两个 Azure 服务包含消息队列：服务总线和 Azure 存储。 一般而言，与服务总线队列相比，存储队列更易于使用，但复杂性和灵活性更低。
服务总线队列的主要优势包括：
- 支持每条消息 256 KB（标准层）或 100 MB（高级层）的更大消息大小，而 Azure 存储队列消息则为 64 KB。
- 既支持最多一次传递，也支持至少一次传递。 在消息丢失的可能性很小或处理两次消息的可能性很小之间选择。
- 保证“先进先出 (FIFO)”顺序。 处理消息的顺序和添加消息的顺序相同。 尽管 FIFO 是队列的正常操作，但如果组织设置了有序的或计划的消息，或者在系统崩溃等中断期间，默认 FIFO 模式将会更改。 有关详细信息，请参阅比较 Azure 存储队列和 Azure 服务总线队列。
- 可在一个事务中对多条消息进行分组。 如果无法传递事务中的一条消息，则不传递事务中所有消息。
- 支持基于角色的安全性。
- 不需要目标组件持续轮询队列。
存储队列的优势：
- 支持无限队列大小（服务总线队列限制为 80-GB）
- 维护所有消息的日志
如何选择通信技术
你已了解不同的概念以及 Azure 提供的实现。 接下来，请考虑你的每种通信的决策过程应该是怎样的。
注意事项
选择发送和接收消息的方法时，请考虑以下问题：
通信是否是一个事件？ 如果是，请考虑使用事件网格或事件中心。
是否应将单条消息发送给多个目标？ 如果是，请使用服务总线主题。 否则，请使用服务总线队列。
队列：服务总线与存储
如果决定需要队列，请进一步缩小选择范围。
在以下情况下，选择一个服务总线队列：
- 需要“最多一次”传递保证。
- 如果没有其他的设置抢占默认的 FIFO 顺序，则你需要 FIFO 保证。
- 需要将消息分组到事务中。
- 需要在不轮询队列的情况下接收消息。
- 需要提供对队列的基于角色的访问。
- 标准层中需要处理大于 64 KB 但小于 256 KB 的消息，高级层中需要处理 100 MB 的消息。
- 队列大小不会增长到超过 80 GB。
- 希望能够发布并使用成批消息。
在以下情况下，选择一个存储队列：
- 需要一个简单的队列，但没有额外的特定要求。
- 需要通过队列的所有消息的审核线索。
- 预期队列大小会超过 80GB。
- 希望跟踪队列内处理消息的过程。
尽管分布式应用程序的组件可以直接通信，但是你往往可通过使用如 Azure 事件中心或 Azure 事件网格等中间通信平台来提高这种通信的可靠性。
事件中心和事件网格用于处理事件，而事件仅通知收件人发生了某个事件，而不包含与该事件关联的原始数据。 Azure 事件中心用于处理高流量的分析型事件。
Azure 服务总线和存储队列适用于消息，可用于绑定任何应用程序工作流的核心部分。
如果你的要求比较简单，如果需要将每条消息只发送到一个目标，或如果想要尽可能快地编写代码，存储队列则可能是最佳选择。 否则，可以利用服务总线提供的更多选项和更高灵活性。
若要将消息发送到多个订阅者，请使用服务总线主题。