你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
生成由多个内部和外部服务组成的分布式应用程序时，异步消息传送和事件驱动的通信至关重要。 设计多租户解决方案时，必须分析如何共享或分区属于不同租户的消息。
共享同一消息传送系统或事件流式处理服务可以显著降低运营成本和管理复杂性。 但是，对每个租户使用专用消息传送系统可提供更好的数据隔离，降低数据泄露的风险，消除 干扰邻居问题，并使你能够更轻松地将 Azure 成本收取回租户。
本文提供了解决方案架构师在决定如何在多租户解决方案中使用消息传递或事件基础结构时可以遵循的准则。
消息、数据点和离散事件
传递事件的服务与发送消息的系统之间有一个本质区别。 事件是条件或状态更改的轻量通知。 通常，事件描述了已发生的情况。 消息包含由要在其他位置使用或存储的服务生成的原始数据。 通常可将消息视为隐式指令或请求。
下表介绍了消息传送类型的主要类型，以及可能使用该实体类型的多租户解决方案示例。
| 实体类型 | 内容 | 例子 |
|---|---|---|
| 离散事件 | 持有有关发布应用程序执行的特定操作的信息。 |
|
| 系列事件 | 将信息性数据点作为连续流中的元素传输。 |
|
| 消息 | 通常携带接收服务执行工作流或处理链中的步骤所需的信息。 |
|
有关详细信息，请参阅 事件、数据点和消息 - 为数据选择正确的 Azure 消息传送服务
Azure 提供了多个消息传送服务，可用于支持消息传送要求，包括 Azure 事件中心、 Azure 事件网格和 Azure 服务总线。 若要了解如何根据需要选择正确的服务，请参阅 在 Azure 消息传送服务 - 事件网格、事件中心和服务总线之间进行选择。
还可以在虚拟机、容器或 AKS 等服务中部署和管理自己的消息传送服务。 执行此作时，需负责部署、管理和维护消息传送基础结构。
关键考虑因素和要求
为解决方案选择的部署和租户模型将对安全性、性能、数据隔离、管理以及向租户交叉收取资源费用的能力产生深远影响。 此分析包括为消息传送和事件基础结构选择的模型。 在本部分中，我们将回顾在多租户解决方案中规划消息传送系统时必须做出的一些关键决策。
缩放
租户数量、消息流的复杂性、eventstream的消息量、预期的流量特征和隔离级别应该在规划消息传输或事件基础架构时驱动决策。
第一步是进行详尽的容量规划，并在吞吐量方面为消息系统建立最大容量，以正确处理常规流量和高峰流量下的预期消息量。
当解决方案处理许多租户并决定为每个租户采用单独的消息传递系统时，需要一致的策略来自动执行每个基础结构的部署、监视、警报和缩放。
例如，可以使用基础结构即代码（IaC）工具（如 Terraform、Bicep 或 Azure 资源管理器（ARM）模板和 DevOps 系统（例如 Azure DevOps 或 GitHub Actions）在预配过程中为租户部署消息系统。 有关详细信息，请参阅多租户解决方案的部署和配置体系结构方法。
消息传送系统可以根据每时间单位的最大消息吞吐量来调整大小。 如果系统支持动态自动缩放，则可以根据流量状况和指标自动增加或减少其容量，以满足预期的服务级别协议。
性能可预测性和可靠性
对于有限数量的租户，使用单个消息传送系统可能是一种出色的解决方案，以满足吞吐量方面的功能要求，并降低总拥有成本。 多租户应用程序可能会跨多个客户共享相同的消息传送实体，例如队列和主题。 或者，可以为每个租户使用一组专用组件来增加租户隔离。 但是，跨多个租户共享相同的消息传递基础结构可能会让整个解决方案暴露在噪声邻居问题中。 一个租户的活动在性能和可作性方面可能会损害其他租户。
在这种情况下，应适当调整消息传送系统的大小，以在高峰时间维持预期的流量负载。 理想情况下，它应支持自动伸缩——在流量增加时动态扩展，在流量减少时动态收缩。 每个租户的专用消息传送系统还可以缓解 Noisy 邻居风险，但管理许多消息传送系统会增加解决方案复杂性。
多租户应用程序可以采用混合方法，其中核心服务在单个共享消息系统中使用相同的队列和主题集来实现内部异步通信。 相比之下，其他服务可以采用一组专用的消息传送实体，甚至为每个租户采用专用消息系统，以缓解干扰邻居问题并保证数据隔离。
管理和操作的复杂性
从一开始就计划好如何操作、监视和维护消息传送和事件基础结构，以及多租户方法如何影响操作和流程。 例如，请考虑以下可能性：
- 假设你在多个租户之间共享一个消息传送系统。 你的解决方案如何收集和报告每个租户的使用指标或限制每个租户可以发送或接收的消息数量？
- 如果租户需要迁移到不同类型的消息传送服务、不同的部署或其他区域，应如何迁移？
- 当消息传递系统利用 PaaS 服务时，应提出以下问题：
- 如何根据租户请求的功能和隔离级别（共享或专用）自定义每个租户的定价层？
- 如何创建特定于租户的托管标识和 Azure 角色分配，以便仅向应允许租户访问的消息传送实体分配适当的权限？ 例如，请参阅使用 Microsoft Entra ID 对托管标识进行身份验证，以访问 Azure 服务总线资源。
- 你可能计划在一组专用虚拟机或容器中托管应用程序使用的消息系统，为每个租户各提供一个。 如果是这样，你打算如何部署、升级、监视和横向扩展这些系统？
成本
通常，部署基础结构的租户密度越高，预配该基础结构的成本就越低。 但是，共享基础结构会增加出现近邻干扰问题等问题的可能性，因此请仔细权衡利弊。
要考虑的方法和模式
规划涉及消息传送的多租户解决方案时，请考虑可能需要的租户之间的隔离级别。 查看以下注意事项和观察：
- 加密密钥： 如果租户需要使用自己的密钥来加密和解密消息，请确认消息传送服务支持隔离密钥的范围。 例如，如果使用服务总线，可能需要为每个需要自己的密钥的租户创建单独的 Azure 服务总线高级命名空间，以便可以使用 客户管理的密钥。
- 业务连续性： 确定需要高级别可恢复性和业务连续性的任何租户，并考虑对这些租户使用区域冗余、异地冗余和异地灾难恢复功能。
- 工作进程处理： 对每个租户使用单独的队列资源或专用消息系统时，可以合理地采用单独的工作进程池，以便为每个租户提高数据隔离级别并降低处理多个消息实体的复杂性。 处理系统的每个实例都可以采用不同的凭据，例如连接字符串、服务主体或托管标识，以便访问专用消息传送系统。 这种方法提供更好的安全级别和租户之间的隔离，但它会增加标识管理的复杂性。
共享消息传送系统
可以考虑部署共享消息传送系统，例如单个 Azure 服务总线命名空间，并在所有租户之间共享。
此方法为基础结构提供最高密度的租户，因此降低了整体的总拥有成本。 它通常还会减少管理开销，因为只需管理和保护一个消息传送系统或资源。
但是，当你跨多个租户共享资源或整个基础结构时，请考虑以下注意事项：
- 始终牢记并考虑相关资源的约束、缩放能力、配额和限制。 例如，单个命名空间中的事件中心的最大数量或最大吞吐量限制，可能会成为一个关键障碍，特别是在您的体系结构扩展以支持更多租户的时候。
- 如以上部分所述，当你在多个租户之间共享资源时，近邻干扰问题可能会成为一个因素，尤其是在某些租户特别繁忙或它们生成的流量高于其他租户时。 在这种情况下，请考虑应用限制模式或速率限制模式来缓解这些影响。 例如，可以限制单个租户在单位时间内可以发送或接收的最大消息数。
- 你可能难以监视活动并测量单个租户 的资源消耗 量。 某些服务（例如 Azure 服务总线的某些层）对消息传送作收费。 因此，在多个租户之间共享命名空间时，应用程序应能够跟踪代表每个租户完成的消息传送操作数及其退款成本。 其他服务不提供相同级别的详细信息。
租户可能对安全性、区域内复原能力、灾难恢复或位置有不同的要求。 如果这些要求与消息传送系统配置不匹配，则可能无法通过单个资源满足它们。
分片模式
分片模式涉及部署多个消息传送系统（称为分片），其中包含一个或多个租户的消息传送实体，例如队列和主题。 与部署标记不同，分片并不意味着整体基础架构被完全复制。 你可以对消息传送系统进行分片，而不对解决方案中的其他基础结构进行复制或分片。
每个消息传送系统或分片在可靠性、SKU 和位置方面可以有不同的特征。 例如，可以根据租户的位置或其性能、可靠性、数据保护或业务连续性需求，将租户跨具有不同特征的多个消息传送系统分片。
使用分片模式时，需要使用 分片策略，以便将给定租户映射到包含其队列的消息传送系统。 查找策略根据租户名称或 ID 使用映射来区分目标消息传送系统。 多个租户可以共享同一分片，但单个租户使用的消息传送实体不会分布在多个分片中。 可以使用单个字典来实现映射，该字典将租户的名称映射到目标消息传送系统的名称或引用。 映射可以存储在可供多租户应用程序的所有实例访问的分布式缓存中，也可以存储在持久存储中，例如关系数据库中的表或存储帐户中的表。
分片模式可以扩展以支持大量租户。 此外，根据工作负载，你可能能够对分片实现较高的租户密度，因此成本可能会很有吸引力。 分片模式还可用于解决 Azure 订阅和服务配额、限制和约束问题。
为每个租户配备专用消息传送系统的多租户应用
另一种常见方法是为每个租户部署具有专用消息传送系统的单个多租户应用程序。 在此租户模型中，你有一些共享组件，例如计算资源，而其他服务则使用单租户专用部署方法进行预配和管理。 例如，可以生成单个应用程序层，然后为每个租户部署单独的消息传递系统，如下图所示。
如果确定系统上的大部分负载是由于可以单独为每个租户单独部署的特定组件，水平分区部署有助于缓解干扰邻居问题。 例如，可能需要为每个租户使用单独的消息传送或 eventstream 系统，因为单个实例不足以跟上多个租户生成的流量。 对每个租户使用专用消息系统时，如果单个租户导致大量消息或事件，这可能会影响共享组件，但不会影响其他租户的消息系统。
因为会为每个租户预配专用资源，所以此方法的成本可能高于共享托管模型。 在采用此租赁模型时，将专用系统资源成本分摊给租户更容易。 此方法允许你实现其他服务的高密度，例如计算资源，并降低这些组件的成本。
对于水平分区部署，需要采用自动化流程来部署和管理多租户应用程序的服务，尤其是单个租户使用的服务。
参与者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Paolo Salvatori | FastTrack for Azure 首席客户工程师
其他参与者：
- John Downs |Azure 模式和做法的主要软件工程师
- Clemens Vasters | 消息传送服务和标准首席架构师
- 阿森·弗拉基米尔斯基|首席工程师，FastTrack for Azure
后续步骤
有关消息传送设计模式的详细信息，请参阅以下资源：