声明检查模式允许工作负荷传输有效负载，而无需在消息传送系统中存储有效负载。 该模式将有效负载存储在外部数据存储区中，并使用“声明检查”来检索有效负载。 索赔检查是一个唯一的、模糊的令牌或密钥。 要检索有效负载，应用程序需要向外部数据存储区提交声明检查令牌。
上下文和问题
传统的消息传送系统经过了优化，可以管理大量的小消息，并且通常对可处理的消息大小有限制。 大消息不仅存在超出这些限制的风险，而且还会在消息传送系统存储它们时拖累整个系统的性能。
解决方案
使用“声明检查”模式，不要向消息传送系统发送大消息。 相反，将有效符合发送到外部数据存储区，并为该有效负载生成声明检查令牌。 消息传送系统会向接收应用程序发送包含声明索赔检查令牌的消息，以便这些应用程序从数据存储区检索有效负载。 消息传送系统永远不会看到或存储有效负载。
- 有效负载
- 将有效负载保存在数据存储区中。
- 生成声明检查令牌并发送包含声明检查令牌的消息。
- 接收消息并读取声明检查令牌。
- 检索有效负载。
- 处理有效负载。
“声明检查”模式的问题和注意事项
在实现“声明检查”模式时，请考虑以下建议：
删除已使用的消息。 如果不需要存档消息，可在接收应用程序使用该消息后删除消息和有效负载。 采用同步或异步删除策略：
同步删除：使用的应用程序会在使用后立即删除消息和有效负载。 它将删除与消息处理工作流相关联，并会使用消息处理工作流的计算能力。
异步删除：消息处理工作流之外的进程删除消息和有效负载。 它会让删除流程与消息处理工作流相互分离，并最大限度地减少对消息处理工作流计算的使用。
有条件地实现该模式。 在发送应用程序中引入逻辑，以便在消息大小超过消息传送系统限制时应用“声明检查”模式。 对于较小的消息，可绕过GIA模式，并将较小的消息发送到消息发送系统。 这种有条件的方法可以减少延迟，优化资源利用率，提高吞吐量。
何时使用“声明检查”模式
以下方案是“声明检查”模式的主要用例：
消息传送系统限制：当消息大小超过消息传送系统的限制时，请使用“声明检查”模式。 将有效负载卸载到外部存储区。 只向消息传送系统发送带有声明检查令牌的消息。
消息传送系统性能：当大消息对消息传送系统造成压力并导致系统性能下降时，请使用“声明检查”模式。
以下方案是“声明检查”模式的次要用例：
敏感数据保护：当有效负载中包含不希望被消息传送系统看到的敏感数据时，请使用“声明检查”模式。 将模式应用于有效负载中的全部或部分敏感信息。 确保敏感数据的安全，而无需直接通过消息传送系统进行传输。
复杂的路由方案：由于序列化、反序列化、加密和解密任务的原因，通过多个组件的消息可能会导致性能瓶颈。 使用“声明检查”模式防止中间组件直接处理消息。
采用“声明检查”模式的工作负荷设计
架构师应评估如何在其工作负荷的设计中使用“声明检查模式”，以解决 Azure Well-Architected Framework 支柱中涵盖的目标和原则。 例如：
| 支柱 | 此模式如何支持支柱目标 |
|---|---|
| 可靠性设计决策有助于工作负荷不易出现故障，并确保其在发生故障后能够完全恢复。 | 消息传送系统不具备专用数据存储通常具备的可靠性和灾难恢复能力。 将数据与消息分离可以提高有效负载的可靠性。 这种分离有利于实现数据冗余，以便能够在灾难发生后恢复有效负载。 - RE:03 故障模式分析 - RE:09 灾难恢复 |
| 安全设计决策有助于确保工作负荷数据和系统的机密性、完整性以及可用性。 | “声明检查”模式可以从消息中提取敏感数据，并将其存储到安全的数据存储区中。 通过该设置可以实施更严格的访问控制，确保只有打算使用敏感数据的服务才能访问这些数据。 同时，它还会将这些数据隐藏起来，不让无关服务（比如用于队列监控的服务）看到。 - SE:03 数据分类 - SE:04 分段 |
| 成本优化的重点是维持和提高工作负载的投资回报率。 | 消息传送系统通常会对消息大小进行限制，而增加大小限制通常是一项高级功能。 减小消息正文的大小使你使用的消息传送解决方案更便宜。 - CO:07 组件成本 - CO:09 流成本 |
| 性能效率通过优化缩放、数据和代码执行来帮助工作负荷高效地满足需求。 | “声明检查”模式能更有效地管理大信息，从而提高发送和接收应用程序以及消息传送系统的效率。 它可以减小发送到消息传送系统的消息大小，确保接收应用程序只在需要时才访问大消息。 - PE:05 缩放和分区 - PE:12 持续性能优化 |
与任何设计决策一样，请考虑对可能采用此模式引入的其他支柱的目标进行权衡。
“声明检查”模式示例
以下示例展示了 Azure 如何促进“声明检查”模式的实现：
Azure 消息传送系统：示例涵盖四种不同的 Azure 消息传送系统方案：Azure 队列存储、Azure 事件中心（标准 API）、Azure 服务总线和 Azure 事件中心 (Kafka API)。
自动和手动声明检查令牌生成：这些示例还显示了生成声明检查令牌的两种方法。 在代码示例 1-3 中，当发送应用程序将有效负载传输到 Azure Blob 存储时，Azure 事件网格会自动生成令牌。 代码示例 4 显示了使用可执行命令行客户端手动生成令牌的过程。
选择适合需要的示例，并按照提供的链接在 GitHub 上查看代码：
| 代码示例 | 消息传送系统方案 | 令牌生成器 | 接收应用程序 | 数据存储 |
|---|---|---|---|---|
| 代码示例 1 | Azure 队列存储 | Azure 事件网格 | 函数 | Azure Blob 存储 |
| 代码示例 2 | Azure 事件中心（标准 API） | Azure 事件网格 | 可执行命令行客户端 | Azure Blob 存储 |
| 代码示例 3 | Azure 服务总线 | Azure 事件网格 | 函数 | Azure Blob 存储 |
| 代码示例 4 | Azure 事件中心 (Kafka API) | 可执行命令行客户端 | 函数 | Azure Blob 存储 |
后续步骤
- 企业集成模式站点上介绍了此模式。
- 有关另一个示例，请参阅博客文章 Dealing with large Service Bus messages using Claim-Check pattern（使用认领凭证模式处理大型服务总线消息）。
- 用于处理大消息的一种替代模式是拆分和聚合。
- NServiceBus 等库使用其 DataBus 功能提供此模式现装支持。