Claim Check-Muster

Event Grid
Blob Storage

Unterteilen Sie eine große Nachricht in Claim Check und Nutzdaten. Senden Sie den Claim Check an die Messagingplattform, und speichern Sie die Nutzdaten in einem externen Dienst. Dieses Muster ermöglicht die Verarbeitung großer Nachrichten und schützt gleichzeitig den Nachrichtenbus und den Client vor Überlastung oder Verlangsamung. Dieses Muster trägt auch zur Kostensenkung bei, da Speicher in der Regel günstiger ist als die von der Messagingplattform verwendeten Ressourceneinheiten.

Dieses Muster ist auch als verweisbasiertes Messaging bekannt und wurde ursprünglich im Buch Enterprise Integration Patterns von Gregor Hohpe and Bobby Woolf beschrieben.

Kontext und Problem

Eine auf Messaging basierende Architektur muss zu gegebener Zeit in der Lage sein, große Nachrichten zu senden, zu empfangen und zu bearbeiten. Solche Nachrichten können alles Mögliche enthalten, einschließlich Bilder (z. B. MRT-Scans), Audiodateien (z. B. Callcenter-Anrufe), Textdokumente oder jede Art von Binärdaten beliebiger Größe.

Das direkte Senden derart großer Nachrichten an den Nachrichtenbus wird nicht empfohlen, da für deren Nutzung mehr Ressourcen und Bandbreite benötigt werden. Große Nachrichten können auch die gesamte Lösung verlangsamen, da Messagingplattformen in der Regel auf die Verarbeitung großer Mengen kleiner Nachrichten ausgelegt sind. Außerdem gelten bei den meisten Messagingplattformen Beschränkungen für die Nachrichtengröße, die Sie möglicherweise für große Nachrichten umgehen müssen.

Lösung

Speichern Sie sämtliche Nachrichtennutzdaten in einem externen Dienst, z. B. einer Datenbank. Rufen Sie den Verweis auf die gespeicherten Nutzdaten ab, und senden Sie bloß diesen Verweis zum Nachrichtenbus. Der Verweis funktioniert genau so wie der Abholschein für ein Gepäckstück (engl. „claim check“), daher auch der Name des Musters. Clients, die an der Verarbeitung dieser spezifischen Nachricht interessiert sind, können den erhaltenen Verweis verwenden, um bei Bedarf die Nutzdaten abzurufen.

Diagramm des Claim Check-Musters.

Probleme und Überlegungen

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

  • Erwägen Sie das Löschen der Nachrichtendaten nach der Verwendung, wenn Sie die Nachrichten nicht archivieren müssen. Obwohl Blobspeicher relativ kostengünstig ist, verursacht er auf lange Sicht Kosten, vor allem bei vielen Daten. Das Löschen der Nachricht kann synchron durch die Anwendung, die die Nachricht empfängt und verarbeitet, oder asynchron in einem gesonderten dedizierten Prozess erfolgen. Beim asynchronen Ansatz werden alte Daten entfernt, ohne dass sich dies auf den Durchsatz und die Verarbeitungsleistung der empfangenden Anwendung auswirkt.

  • Das Speichern und Abrufen der Nachricht verursacht einen zusätzlichen Overhead (Verwaltungsdaten) und höhere Latenzen (Verzögerungszeit). Sie sollten in der sendenden Anwendung eine Logik implementieren, damit dieses Muster nur dann verwendet wird, wenn die Nachrichtengröße das Datenlimit des Nachrichtenbusses überschreitet. Bei kleineren Nachrichten würde das Muster dann übersprungen werden. Dieser Ansatz würde zu einem bedingungsabhängigen Claim Check-Muster führen.

Verwendung dieses Musters

Dieses Muster kann immer dann verwendet werden, wenn eine Nachricht nicht dem unterstützten Nachrichtenlimit der gewählten Nachrichtenbus-Technologie entspricht. Beispielsweise gilt für Service Bus derzeit ein Grenzwert von 100 MB (in der Dienstebene „Premium“), während Event Grid Nachrichten von bis zu 1 MB unterstützt.

Das Muster kann auch verwendet werden, wenn auf die Nutzdaten nur von Diensten zugegriffen werden soll, die zur Ansicht berechtigt sind. Durch das Auslagern der Nutzdaten an eine externe Ressource können strengere Authentifizierungs- und Autorisierungsregeln eingeführt werden, um sicherzustellen, dass Sicherheit gewährleistet ist, wenn sensible Daten in den Nutzdaten gespeichert sind.

Beispiele

In Azure kann dieses Muster auf verschiedene Weise und mit unterschiedlichen Technologien umgesetzt werden. Es gibt jedoch zwei Hauptkategorien. In beiden Fällen liegt es in der Verantwortung des Empfängers, den Claim Check zu lesen und damit die Nutzdaten abzurufen.

  • Automatische Claims Check-Erstellung. Bei diesem Ansatz wird mithilfe von Azure Event Grid automatisch der Claim Check erstellt und in den Nachrichtenbus gepusht.

  • Manuelle Claims Check-Erstellung. Bei diesem Ansatz ist der Absender für die Verwaltung der Nutzdaten zuständig. Der Absender speichert die Nutzdaten mithilfe des entsprechenden Diensts, erhält oder erstellt den Claim Check und sendet diesen an den Nachrichtenbus.

Event Grid ist ein Dienst für das Ereignisrouting und versucht, Ereignisse innerhalb einer konfigurierbaren Zeitspanne von bis zu 24 Stunden zu übermitteln. Danach werden die Ereignisse entweder verworfen oder als unzustellbar markiert. Wenn Sie die Ereignisnutzdaten archivieren oder den Ereignisstream wiedergeben müssen, können Sie ein Event Grid-Abonnement für die Dienste Event Hubs oder Queue Storage hinzufügen, in denen Nachrichten über einen längeren Zeitraum aufbewahrt werden können und die Archivierung von Nachrichten unterstützt wird. Informationen zur Optimierung der Zustellung und deren Wiederholung von Event Grid-Nachrichten und der Konfiguration für unzustellbare Nachrichten finden Sie unter Richtlinien für unzustellbare Nachrichten und Wiederholung.

Automatische Claim Check-Erstellung mithilfe von Blob Storage und Event Grid

Bei diesem Ansatz legt der Absender die Nutzdaten der Nachricht in einem dafür vorgesehenen Azure Blob Storage-Container ab. Event Grid generiert automatisch ein Tag bzw. einen Verweis und sendet dieses bzw. diesen an einen unterstützten Nachrichtenbus, wie z. B. Azure Storage Queues. Der Empfänger kann die Warteschlange abfragen, die Nachricht abrufen und dann die gespeicherten Verweisdaten verwenden, um die Nutzdaten direkt aus Blob Storage herunterzuladen.

Dieselbe Event Grid-Nachricht kann direkt von Azure Functions genutzt werden, ohne dass ein Nachrichtenbus durchlaufen werden muss. Dieser Ansatz nutzt voll aus, dass sowohl Azure Event Grid als auch Azure Functions serverlos sind.

Beispielcode für diesen Ansatz finden Sie hier.

Event Grid mit Event Hubs

Ähnlich wie im vorherigen Beispiel erzeugt Event Grid automatisch eine Nachricht, wenn Nutzdaten in einen Azure Blob-Container geschrieben werden. Doch in diesem Beispiel wird der Nachrichtenbus mithilfe von Event Hubs implementiert. Ein Client kann sich so registrieren, dass er den Stream der Nachrichten empfängt, während sie in den Event Hub geschrieben werden. Der Event Hub kann auch so konfiguriert werden, dass Nachrichten archiviert und als Avro-Datei bereitgestellt werden, die mit Tools wie Apache Spark, Apache Drill oder einer der verfügbaren Avro-Bibliotheken abgefragt werden kann.

Beispielcode für diesen Ansatz finden Sie hier.

Claim Check-Erstellung mithilfe von Service Bus

Diese Lösung nutzt ein Service Bus-Plug-In namens ServiceBus.AttachmentPlugin, das die Implementierung eines Claim Check-Workflows vereinfacht. Das Plug-In wandelt jeden Nachrichtentext in eine Anlage um, die beim Senden der Nachricht in Azure Blob Storage gespeichert wird.

using ServiceBus.AttachmentPlugin;
...

// Getting connection information
var serviceBusConnectionString = Environment.GetEnvironmentVariable("SERVICE_BUS_CONNECTION_STRING");
var queueName = Environment.GetEnvironmentVariable("QUEUE_NAME");
var storageConnectionString = Environment.GetEnvironmentVariable("STORAGE_CONNECTION_STRING");

// Creating config for sending message
var config = new AzureStorageAttachmentConfiguration(storageConnectionString);

// Creating and registering the sender using Service Bus Connection String and Queue Name
var sender = new MessageSender(serviceBusConnectionString, queueName);
sender.RegisterAzureStorageAttachmentPlugin(config);

// Create payload
var payload = new { data = "random data string for testing" };
var serialized = JsonConvert.SerializeObject(payload);
var payloadAsBytes = Encoding.UTF8.GetBytes(serialized);
var message = new Message(payloadAsBytes);

// Send the message
await sender.SendAsync(message);

Die Service Bus-Nachricht fungiert als Benachrichtigungswarteschlange, die ein Client abonnieren kann. Wenn der Consumer die Nachricht empfängt, ermöglicht das Plug-In das direkte Lesen der Nachrichtendaten aus Blob Storage. Daran anschließend können Sie auswählen, wie die Nachricht weiter verarbeitet werden soll. Ein Vorteil dieses Ansatzes besteht darin, dass er den Claim Check-Workflow von Absender und Empfänger abstrahiert.

Beispielcode für diesen Ansatz finden Sie hier.

Manuelle Claim Check-Erstellung mithilfe von Kafka

In diesem Beispiel schreibt ein Kafka-Client die Nutzdaten in Azure Blob Storage. Anschließend sendet er eine Benachrichtigung mithilfe Kafka-fähiger Event Hubs. Der Consumer empfängt die Nachricht und kann über Blob Storage auf die Nutzdaten zugreifen. Dieses Beispiel zeigt, wie das Claim Check-Muster mithilfe eines anderen Messagingprotokolls in Azure implementiert werden kann. Beispielsweise kann es erforderlich sein, bestehende Kafka-Clients zu unterstützen.

Beispielcode für diesen Ansatz finden Sie hier.

Nächste Schritte