宣告檢查模式可讓工作負載傳輸承載，而不需將承載儲存在傳訊系統中。 模式會將承載儲存在外部數據存放區中，並使用「宣告檢查」來擷取承載。 宣告檢查是唯一、模糊的令牌或金鑰。 若要擷取承載，應用程式必須將宣告檢查令牌呈現至外部數據存放區。
內容和問題
傳統傳訊系統已優化來管理大量小型訊息，而且通常會限制其可處理的訊息大小。 大型訊息不僅有超出這些限制的風險，而且在傳訊系統儲存這些限制時也會降低整個系統的效能。
解決方案
使用宣告檢查模式，且不會將大型訊息傳送至傳訊系統。 相反地，將承載傳送至外部數據存放區，併產生該承載的宣告檢查令牌。 傳訊系統會傳送具有宣告檢查令牌的訊息，以接收應用程式，讓這些應用程式可以從數據存放區擷取承載。 傳訊系統永遠不會看到或儲存承載。
- 酬載
- 在數據存放區中儲存承載。
- 產生宣告檢查令牌，並使用宣告檢查令牌傳送訊息。
- 接收訊息並讀取宣告檢查令牌。
- 擷取承載。
- 處理承載。
宣告檢查模式的問題和考慮
實作宣告檢查模式時，請考慮下列建議：
刪除已取用的訊息。 如果您不需要封存訊息，請在接收應用程式取用訊息之後刪除訊息和承載。 使用同步或異步刪除策略：
同步刪除：取用的應用程式會在取用之後立即刪除訊息和承載。 它會將刪除系結至訊息處理工作流程，並使用傳訊工作流程計算容量。
異步刪除：訊息處理工作流程以外的進程會刪除訊息和承載。 它會將刪除程式與訊息處理工作流程分離，並將傳訊工作流程計算的使用降到最低。
有條件地實作模式。 如果訊息大小超過傳訊系統的限制，請在傳送應用程式中納入套用宣告檢查模式的邏輯。 對於較小的訊息，請略過模式，並將較小的訊息傳送至訊息系統。 此條件式方法可減少延遲、優化資源使用率，以及改善輸送量。
使用宣告檢查模式的時機
下列案例是宣告檢查模式的主要使用案例：
訊息系統限制：當訊息大小超過傳訊系統的限制時，請使用宣告檢查模式。 將承載卸除至外部記憶體。 只將具有宣告檢查令牌的訊息傳送至傳訊系統。
傳訊系統效能：當大型訊息使傳訊系統緊張並降低系統效能時，請使用宣告檢查模式。
下列案例是宣告檢查模式的次要使用案例：
敏感數據保護：當承載包含不想要傳訊系統可見的敏感數據時，請使用宣告-檢查模式。 將模式套用至承載中所有或部分的敏感性資訊。 保護敏感數據，而不需透過傳訊系統直接傳輸。
複雜的路由案例：周遊多個元件的訊息可能會導致效能瓶頸，因為串行化、還原串行化、加密和解密工作。 使用宣告檢查模式來防止中繼元件進行直接訊息處理。
使用宣告檢查模式的工作負載設計
架構設計人員應該評估宣告檢查模式在工作負載的設計中如何使用，以解決 Azure 良好架構架構支柱中涵蓋的目標和原則。 例如：
| 要素 | 此模式如何支援支柱目標 |
|---|---|
| 可靠性設計決策可協助工作負載恢復故障，並確保其會在失敗后完全復原。 | 傳訊系統不會提供通常存在於專用數據存放區中的相同可靠性和災害復原。 將數據與訊息分開可提供承載更高的可靠性。 此區隔有助於數據備援，讓您在災害後復原承載。 - 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 Blob 儲存體 |
| 程式代碼範例 2 | Azure 事件中樞 （標準 API） | 事件格線 | 可執行的命令行用戶端 | Azure Blob 儲存體 |
| 程式代碼範例 3 | Azure 服務匯流排 | 事件格線 | 函式 | Azure Blob 儲存體 |
| 程式代碼範例 4 | Azure 事件中樞 （Kafka API） | 可執行的命令行用戶端 | 函式 | Azure Blob 儲存體 |
下一步
- 企業整合模式網站有 此模式的描述 。
- 如需另一個範例，請參閱使用宣告檢查模式處理大型 服務匯流排 訊息（部落格文章）。
- 處理大型訊息的替代模式是 分割 和 匯總。
- NServiceBus 之類的連結庫透過其 DataBus 功能，提供此模式現用的支援。