Mit dem Claim Check-Muster können Workloads Nutzlasten weiterleiten, ohne diese in einem Messaging-System zu speichern. Das Muster speichert die Nutzlast in einem externen Datenspeicher und verwendet eine „Anspruchsprüfung“ (Claim Check), um die Nutzlast abzurufen. Die Anspruchsprüfung (Claim Check) ist ein eindeutiges Token oder ein Schlüssel zur Verschleierung. Um die Nutzdaten abzurufen, müssen Anwendungen das Claim Check-Token im externen Datenspeicher vorlegen.
Kontext und Problem
Herkömmliche Messaging-Systeme sind für die Verwaltung einer hohen Anzahl kleiner Nachrichten optimiert und unterliegen häufig Einschränkungen in Bezug auf die Größe der Nachrichten, die sie verarbeiten können. Bei großen Nachrichten besteht nicht nur das Risiko, dass sie diese Grenzwerte überschreiten. Sie können auch die Leistung des gesamten Systems beeinträchtigen, wenn sie vom Messaging-System gespeichert werden.
Lösung
Verwenden Sie das Claim Check-Muster und senden Sie keine großen Nachrichten an das Messaging-System. Senden Sie die Nutzdaten stattdessen an einen externen Datenspeicher und generieren Sie für diese Nutzdaten ein Claim Check-Token. Das Messaging-System sendet an die empfangenden Anwendungen eine Nachricht mit dem Claim Check-Token, damit sie die Nutzlast aus dem Datenspeicher abrufen können. Das Messaging-System zeigt die Nutzlast nie an oder speichert sie.
- Payload
- Speichern Sie die Nutzlast im Datenspeicher.
- Generieren Sie ein Claim Check-Token und senden Sie eine Nachricht mit dem Claim Check-Token.
- Empfangen Sie die Nachricht und lesen Sie das Claim Check-Token.
- Rufen Sie die Nutzlast ab.
- Verarbeiten Sie die Nutzlast.
Probleme und Überlegungen im Zusammenhang mit dem Claim Check-Muster
Beachten Sie bei der Implementierung des Claim Check-Musters die folgenden Empfehlungen:
Löschen Sie die gelesenen Nachrichten. Wenn Sie die Nachricht nicht archivieren müssen, löschen Sie die Nachricht und die Nutzlast, nachdem sie von den empfangenden Anwendungen verwendet wurden. Verwenden Sie entweder eine synchrone oder eine asynchrone Löschmethode:
Synchrones Löschen: Die verarbeitende Anwendung löscht die Nachricht und die Nutzlast unmittelbar nach deren Nutzung. Sie verbindet den Löschvorgang mit dem Nachrichtenverarbeitungsworkflow und nutzt die Rechenkapazität des Messaging-Workflows.
Asynchrones Löschen: Ein Prozess außerhalb des Nachrichtenverarbeitungsworkflows löscht die Nachricht und die Nutzlast. Dabei wird der Löschvorgang vom Nachrichtenverarbeitungsworkflow getrennt und die Nutzung der Rechenkapazität des Messaging-Workflows minimiert.
Implementieren Sie das Muster bedingt. Integrieren Sie in die sendende Anwendung, die das Claim Check-Muster anwendet, Logik, wenn die Nachrichtengröße den Grenzwert des Messaging-Systems überschreitet. Umgehen Sie bei kleineren Nachrichten das Muster und senden Sie die kleinere Nachricht an das Messaging-System. Dieser bedingte Ansatz reduziert die Latenzzeit, optimiert die Ressourcenauslastung und verbessert den Durchsatz.
Wann sollten Sie das Claim Check-Muster verwenden?
Die folgenden Szenarien stellen die primären Anwendungsfälle für die Verwendung von Claim Check-Mustern dar:
Einschränkungen des Messaging-Systems: Verwenden Sie das Claim Check-Muster, wenn die Größe der Nachrichten die Grenzwerte des Messaging-Systems überschreitet. Lagern Sie die Nutzlast in externen Speicher aus. Senden Sie nur die Nachricht mit dem Claim Check-Token an das Messaging-System.
Leistung des Messaging-Systems: Verwenden Sie das Claim Check-Muster, wenn große Nachrichten das Messaging-System belasten und die Systemleistung beeinträchtigen.
Die folgenden Szenarien stellen die sekundären Anwendungsfälle für die Verwendung von Claim Check-Mustern dar:
Schutz vertraulicher Daten: Verwenden Sie das Claim Check-Muster, wenn Nutzlasten vertrauliche Daten enthalten, die für das Messaging-System nicht sichtbar sein sollen. Wenden Sie das Muster in der Nutzlast für alle vertraulichen Informationen oder für Teile davon an. Sichern Sie die vertraulichen Daten ab, ohne sie direkt über das Messaging-System zu übertragen.
Komplexe Routingszenarien: Nachrichten, die mehrere Komponenten durchlaufen, können aufgrund von Serialisierungs-, Deserialisierungs-, Verschlüsselungs- und Entschlüsselungsaufgaben Leistungsengpässe verursachen. Verwenden Sie das Claim Check-Muster, um die direkte Nachrichtenverarbeitung durch intermediäre Komponenten zu verhindern.
Workloadentwurf mit dem Claim Check-Muster
Ein Architekt sollte evaluieren, wie das Claim-Check-Muster im Design seiner Workloads verwendet werden kann, um die Ziele und Prinzipien zu erreichen, die in den Säulen des Azure Well-Architected Framework behandelt werden. Zum Beispiel:
| Säule | So unterstützt dieses Muster die Säulenziele |
|---|---|
| Entscheidungen in Bezug auf das Zuverlässigkeitsdesign tragen dazu bei, dass Ihre Workload gegenüber Fehlfunktionen widerstandsfähig wird, und dass sie nach einem Fehler vollständig wiederhergestellt wird. | Messaging-Systeme bieten nicht die gleiche Zuverlässigkeit und Notfallwiederherstellung, die häufig in dedizierten Datenspeichern vorhanden sind. Durch das Trennen der Nachrichtendaten kann für die Nutzlast eine höhere Zuverlässigkeit generiert werden. Diese Trennung erleichtert die Datenredundanz, die es Ihnen ermöglicht, Nutzlasten nach einem Notfall wiederherzustellen. - RE:03 Fehlermodusanalyse - RE:09 Notfallwiederherstellung |
| Entscheidungen in Bezug auf das Sicherheitsdesign tragen dazu bei, die Vertraulichkeit, Integrität und Verfügbarkeit von Workloaddaten und -systemen sicherzustellen. | Das Claim Check-Muster kann vertrauliche Daten aus Nachrichten extrahieren und diese in einem sicheren Datenspeicher speichern. Mit dieser Konfiguration können Sie strengere Zugriffskontrollen implementieren, durch die sichergestellt wird, dass nur die Dienste auf die Daten zugreifen können, die für die Verwendung vertraulicher Daten konzipiert sind. Gleichzeitig blendet sie diese Daten für nicht verwandte Dienste aus, wie z. B. Dienste, die für die Warteschlangenüberwachung verwendet werden. - SE:03 Datenklassifizierung - SE:04 Segmentierung |
| Die Kostenoptimierung konzentriert sich auf Erhaltung und Verbesserung der Rendite Ihrer Workload. | Messaging-Systeme legen häufig Beschränkungen für die Nachrichtengröße fest, und höhere Größenbeschränkungen sind oft eine Premium-Funktion. Wenn Sie die Größe von Nachrichtentexten verringern, können Sie möglicherweise eine günstigere Messaging-Lösung verwenden. - CO:07 Komponentenkosten - CO:09 Flowkosten |
| Die Leistungseffizienz hilft Ihrer Workload, Anforderungen effizient zu erfüllen, indem die Skalierung, die Datenübertragung und die Ausführung von Code optimiert werden. | Das Claim Check-Muster verbessert die Effizienz der Anwendungen zum Senden und Empfangen und des Messaging-Systems, indem große Nachrichten effektiver verwaltet werden. Dadurch wird die Größe der an das Messaging-System gesendeten Nachrichten reduziert und sichergestellt, dass empfangende Anwendungen nur bei Bedarf auf große Nachrichten zugreifen. - PE:05 Skalierung und Partitionierung - PE:12 Kontinuierliche Leistungsoptimierung |
Berücksichtigen Sie wie bei jeder Designentscheidung alle Kompromisse im Hinblick auf die Ziele der anderen Säulen, die mit diesem Muster eingeführt werden könnten.
Beispiele für Claim Check-Muster
In den folgenden Beispielen ist dargestellt, wie Azure die Implementierung von Claim Check-Mustern erleichtert:
Azure Messaging-Systeme: Die Beispiele umfassen vier verschiedene Azure-Messaging-Systemszenarien: Azure Queue Storage, Azure Event Hubs (Standard-API), Azure Service Bus und Azure Event Hubs (Kafka-API).
Automatische und manuelle Generierung von Claim Check-Token im Vergleich: In diesen Beispielen werden auch zwei Methoden zum Generieren von Claim Check-Token beschrieben. In den Codebeispielen 1–3 generiert Azure Event Grid automatisch das Token, wenn die sendende Anwendung die Nutzlast an Azure Blob Storage weiterleitet. Das Codebeispiel 4 zeigt den Prozess der manuellen Tokengenerierung mit einem ausführbaren Befehlszeilenclient.
Wählen Sie das Beispiel aus, das Ihren Anforderungen entspricht, und folgen Sie dem bereitgestellten Link, um den Code auf GitHub anzuzeigen:
| Beispielcode | Messaging-Systemszenarien | Tokengenerator | Empfangende Anwendung | Datenspeicher |
|---|---|---|---|---|
| Codebeispiel 1 | Azure Queue Storage | Azure Event Grid | Funktion | Azure Blob Storage |
| Codebeispiel 2 | Azure Event Hubs (Standard-API) | Azure Event Grid | Ausführbarer Befehlszeilenclient | Azure Blob Storage |
| Codebeispiel 3 | Azure Service Bus | Azure Event Grid | Funktion | Azure Blob Storage |
| Codebeispiel 4 | Azure Event Hubs (Kafka-API) | Ausführbarer Befehlszeilenclient | Funktion | Azure Blob Storage |
Nächste Schritte
- Die Website von Enterprise Integration Patterns enthält eine Beschreibung dieses Musters.
- Ein weiteres Beispiel finden Sie im Blogbeitrag Verarbeiten großer Service Bus-Nachrichten mithilfe von Claim Check-Mustern.
- Ein alternatives Muster zur Verarbeitung großer Nachrichten ist Teilen und Aggregieren.
- Bibliotheken wie NServiceBus bieten mit ihrer „Datenbus“-Funktionalität sofortigen Support für dieses Muster.