Claim Check-Muster (Anspruchsprüfung)

Speichern Sie eine große Nachrichtennutzlast in einem externen Datenspeicher, und senden Sie nur einen Verweis auf die gespeicherte Nutzlast über das Messagingsystem. Empfangende Anwendungen legen das Referenztoken, den sogenannten Claim Check, vor, um die große Payload abzurufen, wenn sie diese verarbeiten müssen. Mit diesem Ansatz können Workloads große Nutzlasten übertragen, ohne sie im Messagingsystem zu speichern.

Kontext und Problem

Herkömmliche Messagingsysteme sind für die Verwaltung einer hohen Anzahl kleiner Nachrichten optimiert und beschränken häufig die Nachrichtengröße, die sie verarbeiten können. Große Nachrichten riskieren nicht nur das Überschreiten der Größenbeschränkungen, sondern können auch die Systemleistung beeinträchtigen, wenn das Messagingsystem sie speichert.

Die folgenden Beschränkungen machen die Inline-Übertragung von Nutzdaten über das Nachrichtensystem unzureichend:

• Ablehnung der Größenbeschränkung. Nachrichtensysteme lehnen Nachrichten ab, die ein konfiguriertes Maximum überschreiten.

• Maklerressourcendruck. Das Speichern großer Nutzlasten im Broker verbraucht unverhältnismäßigen Arbeitsspeicher und Datenträger im Vergleich zu den Metadaten, die der Broker weiterleiten und übermitteln muss. Dieser Verbrauch konkurriert mit den benötigten Ressourcen für andere Nachrichten im System.

• Durchsatzbeeinträchtigung. Größere Nachrichten erhöhen die Serialisierung, Übertragung und Deserialisierungszeit pro Vorgang.

• Kosteneskalation. Einige Messaging-Systeme berechnen Gebühren nach Nachrichtengröße, Tarifstufe oder Kapazitätseinheit. Das Übertragen großer Nutzlasten inline kann Workloads in höhere Kostenstufen oder Kapazitätszuordnungen verschieben.

Solution

Das Anspruchsprüfungsmuster trennt den Nutzlastspeicher von der Nachrichtenübermittlung. Eine sendende Anwendung schreibt die vollständige Nutzlast in einen externen Datenspeicher und sendet einen Verweis auf diese Nutzlast über das Messagingsystem. Das Messaging-System zeigt die Nutzlast nie an oder speichert sie. Empfangende Anwendungen verwenden den Verweis, um die Nutzlast direkt aus dem Datenspeicher abzurufen. Der Verweis ist ein Bezeichner, den die empfangende Anwendung auflösen muss.

Das Muster folgt dieser Sequenz:

1. Die sendende Anwendung generiert die Nutzlast.
2. Die sendende Anwendung speichert die Nutzlast im externen Datenspeicher.
3. Nachdem die Speicherung erfolgreich war, generiert die sendende Anwendung einen Verweis auf die gespeicherte Nutzlast und veröffentlicht sie als Anspruchsprüfungsnachricht im Messagingsystem.
4. Eine empfangende Anwendung ruft die Nachricht ab und liest das Anspruchsprüfungstoken.
5. Die empfangende Anwendung verwendet das Token, um die Nutzlast aus dem Datenspeicher abzurufen.
6. Die empfangende Anwendung verarbeitet die Nutzlast.

Das Messaging-System verarbeitet nur die kleine Claim-Check-Nachricht, wodurch eine Zurückweisung aufgrund der Nachrichtengröße sowie der Bedarf vermieden werden, Ressourcen für die Übertragung und Speicherung großer Nachrichtennutzdaten einzusetzen. Der externe Datenspeicher wendet Zugriffssteuerungen und Lebenszyklusrichtlinien auf die Nutzlast an, die unabhängig vom Messagingsystem ist.

Probleme und Überlegungen

Beachten Sie die folgenden Punkte bei der Entscheidung, wie dieses Muster implementiert werden soll:

• Verantwortung für den Lebenszyklus der Nutzlast. Definieren Sie, welche Komponente die Nutzlastlöschung besitzt und wie die Komponente bestimmt, dass die Nutzlast nicht benötigt wird. Koordinieren sie den Nachrichtenablauf und die Nutzlastaufbewahrung, sodass eine gültige Anspruchsprüfung nicht auf gelöschte Daten verweist.

• Bedingte Anwendung. Entscheiden Sie, ob für alle Nachrichten Claim Checks verwendet werden sollen oder ob die Entscheidung für jede Nachricht einzeln getroffen werden soll. Wenn sie bedingt ist, stellen Sie sicher, dass das Schema definiert, ob die Nutzlast inline oder extern ist.

• Token- und Speichersicherheit. Betten Sie Sicherheits-Token nicht als Teil des Claim Check ein. Belassen Sie die Autorisierung als unabhängige Interaktion zwischen Produzenten- oder Verbrauchersystemen und dem Datenspeicher. Wenn Ihre Lösung erfordert, dass Benutzern ausdrücklich vorübergehender Zugriff gewährt wird, verwenden Sie stattdessen das Valet-Key-Muster.

• Konsistenz von Nutzlast und Token. Die Nutzlastschreib- und Tokenveröffentlichung erfolgt in separaten Systemen und nicht in einer atomischen Transaktion. Ein Fehler nach dem Schreiben der Nutzlast, aber vor der Veröffentlichung des Tokens, kann eine verwaiste Nutzlast zurücklassen. Ein Token, das veröffentlicht wird, bevor seine Nutzlast abgerufen werden kann, kann bedeuten, dass Verbraucher Verweise erhalten, die sie nicht auflösen können. Veröffentlichen Sie das Token erst, nachdem die Nutzlast erfolgreich geschrieben wurde. Da bei Wiederholungsversuchen derselbe Claim Check mehr als einmal zugestellt werden kann, verwenden Sie das Muster des idempotenten Consumers, um Duplikate sicher zu verarbeiten.

• Nutzlastintegrität. Wenn Verbraucher die Nutzlastintegrität überprüfen müssen, fügen Sie einen Inhaltshash oder eine digitale Signatur in die Nachricht ein. Definieren Sie ein Protokoll für Abweichungen, z. B. das Ablehnen der Nutzlast, den erneuten Abruf oder das Weiterleiten der Nachricht zur weiteren Untersuchung.

• Nutzlastverfügbarkeit und Haltbarkeit. Der externe Datenspeicher muss für den gesamten Zeitraum verfügbar und dauerhaft bleiben, in dem Anwendungen eine Nutzlast abrufen müssen. Wenn es bei dem Datenspeicher zu einem Ausfall oder Datenverlust kommt, können Nutzer, die über gültige Tokens verfügen, ihre Nutzdaten nicht abrufen und ihre Nachrichtenverarbeitung kommt zum Stillstand.

• Abruf-Hop-Latenz. Das Muster führt im Vergleich zur Inline-Übermittlung von Nachrichten zu zusätzlichen Netzwerkaufrufen. Empfangende Anwendungen müssen den externen Datenspeicher aufrufen, um die Nutzlast abzurufen, bevor die Verarbeitung beginnen kann.

• Vom Framework bereitgestellte Anspruchsprüfungsunterstützung. Verwenden Sie die Funktionen, die Ihr Nachrichtenbus-SDK bietet. Beispielsweise verfügt NServiceBus über ein DataBus-Feature , mit dem Nutzlastspeicher und Abruf automatisiert werden können.

Wann dieses Muster verwenden

Verwenden Sie dieses Muster in folgenden Fällen:

• Nachrichtennutzlasten überschreiten regelmäßig die maximale Nachrichtengröße , die das Messagingsystem unterstützt. Das Auslagern der Nutzlast in einen externen Datenspeicher und die Übertragung nur eines leichtgewichtigen Claim-Check-Tokens vermeiden Zurückweisungen aufgrund von Größenbeschränkungen.

• Große Nachrichten verbrauchen unverhältnismäßige Brokerressourcen. Große Nachrichten wirken sich auf die Leistung des Messagingsystems aus, indem sie die Serialisierung und Übertragungszeit erhöhen oder den Durchsatz für alle Produzenten und Verbraucher beeinträchtigen, die das Messagingsystem gemeinsam nutzen.

• Nutzlasten enthalten vertrauliche Informationen , die nicht für das Messagingsystem oder für zwischengeschaltete Komponenten wie Warteschlangenüberwachungstools sichtbar sein sollten. Wenden Sie das Muster auf die gesamte Nutzlast oder nur auf die vertraulichen Teile an. Speichern Sie die vertraulichen Inhalte in einem gesicherten Datenspeicher mit dedizierten Zugriffssteuerungen, um sie außerhalb des Nachrichtenpfads zu behalten.

• Nachrichten weisen ein komplexes Routing mit wiederholter Serialisierung auf. Nachrichten durchlaufen mehrere Routingkomponenten, die Serialisierung, Deserialisierung, Verschlüsselung oder Entschlüsselung durchführen. Übertragen Sie nur ein kleines Token über Vermittler, um die wiederholte Verarbeitung der vollständigen Nutzlast bei jedem Hop zu beseitigen und die kumulierte Latenz zu reduzieren.

Dieses Muster ist möglicherweise nicht geeignet, wenn:

• Die Latenzempfindlichkeit überwiegt die Bedenken hinsichtlich der Nutzlastgröße. Workloads, die die geringstmögliche End-to-End-Latenz zwischen Produzent und Konsument erfordern, könnten die zusätzlichen Netzwerksprünge für die Speicherung und den Abruf von Nutzdaten möglicherweise nicht tolerieren. Wenn Nachrichten inline übermittelt werden können, ohne größen- oder Leistungsbeschränkungen zu überschreiten, ist die direkte Zustellung einfacher und schneller.

• Sie können einen Transport oder eine Ebene auswählen, die die Nutzlastgröße unterstützt. Wenn Nutzlasten innerhalb des unterstützten Grenzwerts eines Transports bleiben und keinen inakzeptablen Durchsatz oder eine inakzeptable Latenz erzeugen, senden Sie sie inline, um die Abhängigkeit des externen Speichers zu vermeiden. Beispielsweise unterstützt Azure Service Bus Premium-Stufe Advanced Message Queuing Protocol (AMQP)-Nachrichten bis zu 100 MB. Halten Sie Nachrichten so klein wie möglich, da große Nachrichten den Durchsatz verringern und die Latenz erhöhen.

• Die Koordination über zwei Systeme hinweg ist nicht möglich. Das Muster erfordert eine Koordination über zwei unabhängige Systeme. Der Claim-Check-Wert muss so formuliert werden, dass das empfangende System ihn verstehen kann, und dessen Format muss möglicherweise im Laufe der Zeit angepasst werden.

Alternatives

Betrachten Sie diese Ansätze als Alternativen zu diesem Muster:

• Verringern Sie die Inlinenutzlastgröße. Die Komprimierung kann sich wiederholende Text- oder binäre Nutzlasten reduzieren, und ein kompakterer Serialisierer kann den Nachrichtenaufwand verringern. Wählen Sie diesen Ansatz aus, wenn die reduzierte Nutzlast bequem in den Transportgrenzwert passt, und jeder Hersteller und Verbraucher kann das gleiche Komprimierungs- und Serialisierungsformat verwenden.

• Teilen und aggregieren Sie die Nutzlast natürlich. Teilen Sie eine große Nutzlast in eine Abfolge kleinerer Nachrichten auf, wenn Verbraucher Blöcke unabhängig verarbeiten oder nach der Übermittlung erneut zusammenfügen können. Dieser Ansatz behält die Daten im Messagingsystem bei, fügt jedoch Sequenzierung, Korrelation, duplizierte Behandlung und erneute Zusammenführungsanforderungen hinzu. Weitere Informationen finden Sie unter Splitter- und Aggregator-Mustern aus Enterprise Integration Patterns.

Arbeitslastgestaltung

Bewerten Sie, wie Sie das Claim-Check-Muster beim Entwurf einer Workload verwenden, um die in den Azure Well-Architected Framework-Säulen beschriebenen Ziele und Prinzipien zu erfüllen. Die folgende Tabelle enthält Anleitungen dazu, wie dieses Muster die Ziele der Säulen unterstützt.

Wenn dieses Muster Kompromisse innerhalb einer Säule einführt, sollten Sie sie gegen die Ziele der anderen Säulen berücksichtigen.

Examples

Dieser Abschnitt enthält Links zu GitHub Beispielen für das Anspruchsprüfungs-Cloudmuster, in denen gezeigt wird, wie Azure Dienste das Anspruchsprüfungsmuster implementieren. In jedem Beispiel wird Azure Blob Storage als externer Datenspeicher verwendet und mit einem anderen Azure Messagingsystem gekoppelt. Beispiele 1 bis 3 verwenden die Blob-URL in einer Azure Event Grid-Benachrichtigung als Claim-Check. Beispiel 4 verwendet eine benutzerdefinierte Anspruchsprüfung, die die sendende Anwendung veröffentlicht.

In den Beispielen 1 bis 3:

1. Eine sendende Anwendung lädt eine große Nutzlast in Blob Storage hoch.
2. Der Upload löst über ein Event Grid-Systemthema ein Microsoft.Storage.BlobCreated-Ereignis aus.
3. Event Grid leitet die Benachrichtigung, die eine direkte Blob-URL enthält, die in den Beispielen als Claim Check verwendet wird, an das konfigurierte Messagingsystem weiter.
4. Eine empfangende Anwendung, die als Azure Functions Funktions-App oder Befehlszeilenclient implementiert wird, ruft die Benachrichtigung ab, extrahiert die BLOB-URL und lädt die Nutzlast direkt aus Blob Storage zur Verarbeitung herunter.

In einer Produktionsimplementierung filtern Sie das Ereignisabonnement nach Vorgängen, die auf einen vollständig bestätigten Blockblob hinweisen, und entwerfen die Empfängerkomponente so, dass verzögerte, doppelte und nicht in der richtigen Reihenfolge eintreffende Ereignisse verarbeitet werden können.

In Beispiel 4 wird ein anderer Ansatz verwendet. Anstatt eine Blob Storage-Benachrichtigung über das Ereignisraster weiterzuleiten, erstellt die sendende Anwendung die Anspruchsprüfung nach dem Hochladen der Nutzlast in Blob Storage. Die sendende Anwendung veröffentlicht dann die Anspruchsprüfung mithilfe des Apache Kafka-Protokolls an den Azure Event Hubs Kafka-Endpunkt. Dieser Ansatz eignet sich für Umgebungen, die bereits kafka-kompatible Produzenten verwenden oder benutzerdefinierte Tokenformate erfordern.

Die folgende Tabelle listet jedes Beispiel mit seinem Messaging-System, dem Claim-Check-Publisher, der empfangenden Anwendung und den Speicherabhängigkeiten auf. Wählen Sie jeden Link aus, um den Beispielcode auf GitHub anzuzeigen.

Nächste Schritte

• Lesen Sie die kanonische Beschreibung der Enterprise-Integrationsmuster der Anspruchsprüfung.
• Sehen Sie sich eine weitere Implementierung unter Umgang mit großen Service-Bus-Nachrichten mithilfe des Claim-Check-Musters an.
• Wählen Sie zwischen Azure Event Grid, Event Hubs und Service Bus.

Verwandte Ressourcen

• Asynchrones Anfrage-Antwort-Muster
• Pattern konkurrierender Konsumenten
• Muster für einen sequenziellen Konvoi
• Muster „Valetschlüssel“