声明-检查模式

声明检查模式允许工作负荷传输有效负载，而无需在消息传送系统中存储有效负载。 该模式将有效负载存储在外部数据存储区中，并使用“声明检查”来检索有效负载。 索赔检查是一个唯一的、模糊的令牌或密钥。 要检索有效负载，应用程序需要向外部数据存储区提交声明检查令牌。

上下文和问题

传统的消息传送系统经过了优化，可以管理大量的小消息，并且通常对可处理的消息大小有限制。 大消息不仅存在超出这些限制的风险，而且还会在消息传送系统存储它们时拖累整个系统的性能。

解决方案

使用“声明检查”模式，不要向消息传送系统发送大消息。 相反，将有效符合发送到外部数据存储区，并为该有效负载生成声明检查令牌。 消息传送系统会向接收应用程序发送包含声明索赔检查令牌的消息，以便这些应用程序从数据存储区检索有效负载。 消息传送系统永远不会看到或存储有效负载。

1. 有效负载
2. 将有效负载保存在数据存储区中。
3. 生成声明检查令牌并发送包含声明检查令牌的消息。
4. 接收消息并读取声明检查令牌。
5. 检索有效负载。
6. 处理有效负载。

“声明检查”模式的问题和注意事项

在实现“声明检查”模式时，请考虑以下建议：

• 删除已使用的消息。 如果不需要存档消息，可在接收应用程序使用该消息后删除消息和有效负载。 采用同步或异步删除策略：

  • 同步删除：使用的应用程序会在使用后立即删除消息和有效负载。 它将删除与消息处理工作流相关联，并会使用消息处理工作流的计算能力。

  • 异步删除：消息处理工作流之外的进程删除消息和有效负载。 它会让删除流程与消息处理工作流相互分离，并最大限度地减少对消息处理工作流计算的使用。

• 有条件地实现该模式。 在发送应用程序中引入逻辑，以便在消息大小超过消息传送系统限制时应用“声明检查”模式。 对于较小的消息，可绕过GIA模式，并将较小的消息发送到消息发送系统。 这种有条件的方法可以减少延迟，优化资源利用率，提高吞吐量。

何时使用“声明检查”模式

以下方案是“声明检查”模式的主要用例：

• 消息传送系统限制：当消息大小超过消息传送系统的限制时，请使用“声明检查”模式。 将有效负载卸载到外部存储区。 只向消息传送系统发送带有声明检查令牌的消息。

• 消息传送系统性能：当大消息对消息传送系统造成压力并导致系统性能下降时，请使用“声明检查”模式。

以下方案是“声明检查”模式的次要用例：

• 敏感数据保护：当有效负载中包含不希望被消息传送系统看到的敏感数据时，请使用“声明检查”模式。 将模式应用于有效负载中的全部或部分敏感信息。 确保敏感数据的安全，而无需直接通过消息传送系统进行传输。

• 复杂的路由方案：由于序列化、反序列化、加密和解密任务的原因，通过多个组件的消息可能会导致性能瓶颈。 使用“声明检查”模式防止中间组件直接处理消息。

采用“声明检查”模式的工作负荷设计

架构师应评估如何在其工作负荷的设计中使用“声明检查模式”，以解决 Azure Well-Architected Framework 支柱中涵盖的目标和原则。 例如：

与任何设计决策一样，请考虑对可能采用此模式引入的其他支柱的目标进行权衡。

“声明检查”模式示例

以下示例展示了 Azure 如何促进“声明检查”模式的实现：

• Azure 消息传送系统：示例涵盖四种不同的 Azure 消息传送系统方案：Azure 队列存储、Azure 事件中心（标准 API）、Azure 服务总线和 Azure 事件中心 (Kafka API)。

• 自动和手动声明检查令牌生成：这些示例还显示了生成声明检查令牌的两种方法。 在代码示例 1-3 中，当发送应用程序将有效负载传输到 Azure Blob 存储时，Azure 事件网格会自动生成令牌。 代码示例 4 显示了使用可执行命令行客户端手动生成令牌的过程。

选择适合需要的示例，并按照提供的链接在 GitHub 上查看代码：

后续步骤

• 企业集成模式站点上介绍了此模式。
• 有关另一个示例，请参阅博客文章 Dealing with large Service Bus messages using Claim-Check pattern（使用认领凭证模式处理大型服务总线消息）。
• 用于处理大消息的一种替代模式是拆分和聚合。
• NServiceBus 等库通过其“数据总线”功能为此模式提供开箱即用的支持。

相关资源

• 异步请求-答复模式
• 使用者竞争模式
• 顺序保护模式