Claim-Check mönster

Dela upp ett stort meddelande i en anspråkskontroll och en nyttolast. Skicka anspråkskontrollen till meddelandeplattformen och lagra nyttolasten till en extern tjänst. Det här mönstret gör att stora meddelanden kan bearbetas, samtidigt som meddelandebussen och klienten inte överbelastas eller blir långsammare. Det här mönstret bidrar också till att minska kostnaderna eftersom lagring vanligtvis är billigare än resursenheter som används av meddelandeplattformen.

Det här mönstret kallas även för Reference-Based Messaging och beskrevs ursprungligen i boken Enterprise-integration Patterns, av Gregor Hohpe och Pattern Patternf.

Kontext och problem

En meddelandebaserad arkitektur måste någon gång kunna skicka, ta emot och manipulera stora meddelanden. Sådana meddelanden kan innehålla vad som helst, inklusive bilder (till exempel MRI-genomsökningar), ljudfiler (till exempel callcenter-anrop), textdokument eller valfri typ av binärdata av godtycklig storlek.

Det rekommenderas inte att skicka så stora meddelanden direkt till meddelandebussen eftersom de kräver mer resurser och bandbredd för att förbrukas. Stora meddelanden kan också göra hela lösningen långsammare eftersom meddelandeplattformar vanligtvis är finjusterade för att hantera stora mängder små meddelanden. Dessutom har de flesta meddelandeplattformar begränsningar för meddelandestorlek, så du kan behöva komma runt dessa gränser för stora meddelanden.

Lösning

Lagra hela meddelandenyttolasten i en extern tjänst, till exempel en databas. Hämta referensen till den lagrade nyttolasten och skicka bara den referensen till meddelandebussen. Referensen fungerar som en anspråkskontroll som används för att hämta en del av retningen, därav namnet på mönstret. Klienter som är intresserade av att bearbeta det specifika meddelandet kan använda den hämtade referensen för att hämta nyttolasten om det behövs.

Diagram över Claim-Check mönster

Problem och överväganden

Tänk på följande när du bestämmer hur du ska implementera mönstret:

  • Överväg att ta bort meddelandedata när du har förbrukat dem, om du inte behöver arkivera meddelandena. Även om bloblagring är relativt billigt kostar det en del pengar på lång sikt, särskilt om det finns mycket data. Borttagning av meddelandet kan göras synkront av programmet som tar emot och bearbetar meddelandet, eller asynkront av en separat dedikerad process. Den asynkrona metoden tar bort gamla data utan att påverka dataflödes- och meddelandebearbetningsprestanda för det mottagande programmet.

  • Lagring och hämtning av meddelandet medför viss ytterligare belastning och fördröjning. Du kanske bara vill implementera logik i sändningsprogrammet för att använda det här mönstret när meddelandestorleken överskrider meddelandebussens datagräns. Mönstret hoppas över för mindre meddelanden. Den här metoden skulle resultera i ett mönster för villkorlig anspråkskontroll.

När du ska använda det här mönstret

Det här mönstret bör användas när ett meddelande inte passar den meddelandegräns som stöds för den valda meddelandebusstekniken. Till exempel har Event Hubs för närvarande en gräns på 256 kB (Basic-nivån), medan Event Grid endast stöder meddelanden på 64 KB.

Mönstret kan också användas om nyttolasten endast ska användas av tjänster som har behörighet att se den. Genom att avlasta nyttolasten till en extern resurs kan striktare regler för autentisering och auktorisering införas för att säkerställa att säkerhet tillämpas när känsliga data lagras i nyttolasten.

Exempel

I Azure kan det här mönstret implementeras på flera sätt och med olika tekniker, men det finns två huvudkategorier. I båda fallen har mottagaren ansvaret att läsa anspråkskontrollen och använda den för att hämta nyttolasten.

  • Automatisk generering av anspråkskontroll. Den här metoden använder Azure Event Grid för att automatiskt generera anspråkskontrollen och skicka den till meddelandebussen.

  • Manuell generering av anspråkskontroll. I den här metoden ansvarar avsändaren för att hantera nyttolasten. Avsändaren lagrar nyttolasten med rätt tjänst, hämtar eller genererar anspråkskontrollen och skickar anspråkskontrollen till meddelandebussen.

Event Grid är en händelsedirigeringstjänst och försöker leverera händelser inom en konfigurerbar tidsperiod på upp till 24 timmar. Därefter ignoreras händelser antingen eller utan bokstav. Om du behöver arkivera händelsenyttolaster eller spela upp händelseströmmen igen kan du lägga till en Event Grid-prenumeration till Event Hubs eller Queue Storage, där meddelanden kan behållas under längre perioder och arkivering av meddelanden stöds. Information om hur du finjusterar Event Grid leverans av meddelanden och återförsök och konfiguration av dead letter finns i Principer för dead letter och retry.

Automatisk generering av anspråkskontroll med Blob Storage och Event Grid

Med den här metoden släpper avsändaren meddelandenyttolasten i en angiven Azure Blob Storage container. Event Grid automatiskt en tagg/referens och skickar den till en meddelandebuss som stöds, till exempel Azure Storage köer. Mottagaren kan avs omröstning i kön, hämta meddelandet och sedan använda lagrade referensdata för att ladda ned nyttolasten direkt från Blob Storage.

Samma Event Grid kan användas direkt av Azure Functions, utan att behöva gå igenom en meddelandebuss. Den här metoden drar full nytta av den serverlösa typen av både Event Grid och Functions.

Du hittar exempelkod för den här metoden här.

Event Grid med Event Hubs

Precis som i föregående exempel genererar Event Grid automatiskt ett meddelande när en nyttolast skrivs till en Azure Blob-container. Men i det här exemplet implementeras meddelandebussen med hjälp av Event Hubs. En klient kan registrera sig själv för att ta emot strömmen med meddelanden när de skrivs till händelsehubben. Händelsehubben kan också konfigureras för att arkivera meddelanden, vilket gör dem tillgängliga som en Avro-fil som kan efterfrågas med verktyg som Apache Spark, Apache Drill eller något av de tillgängliga Avro-biblioteken.

Du hittar exempelkod för den här metoden här.

Generering av anspråkskontroll med Service Bus

Den här lösningen drar nytta av ett Service Bus plugin-program, ServiceBus.AttachmentPlugin,som gör arbetsflödet för anspråkskontroll enkelt att implementera. Plugin-programmet konverterar meddelandetexten till en bifogad fil som lagras i Azure Blob Storage när meddelandet skickas.

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);

Meddelandet Service Bus som en meddelandekö som en klient kan prenumerera på. När användaren får meddelandet gör plugin-programmet det möjligt att direkt läsa meddelandedata från Blob Storage. Du kan sedan välja hur du vill bearbeta meddelandet ytterligare. En fördel med den här metoden är att den abstraherar arbetsflödet för anspråkskontroll från avsändaren och mottagaren.

Du hittar exempelkod för den här metoden här.

Manuell generering av anspråkskontroll med Kafka

I det här exemplet skriver en Kafka-klient nyttolasten till Azure Blob Storage. Sedan skickar den ett aviseringsmeddelande med hjälp av Kafka-aktiverad Event Hubs. Användaren får meddelandet och kan komma åt nyttolasten från Blob Storage. Det här exemplet visar hur ett annat meddelandeprotokoll kan användas för att implementera anspråkskontrollmönstret i Azure. Du kan till exempel behöva stödja befintliga Kafka-klienter.

Du hittar exempelkod för den här metoden här.

Nästa steg

  • Ett alternativt mönster för hantering av stora meddelanden är Dela och Aggregera.